Mobile or browser clients talk to a Unison backend services over HTTP, similar to any other language. Nothing fancy there.[1]
> sending code over the network to be executed elsewhere feels like a security risk to me?
I left out many details in my explanation and was just describing the core code syncing capability the language gives you. You can take a look at [2] to see what the core language primitives are - you can serialize values and code, ask their dependencies, deserialize them, and load them dynamically.
To turn that into a more industrial strength distributed computing platform, there are more pieces to it. For instance, you don't want to accept computations from anyone on the internet, only people who are authenticated. And you want sandboxing that lets you restrict the set of operations that dynamically loaded computations can use.
Within an app backend / deployed service, it is very useful to be able to fork computations onto other nodes and have that just work. But you likely won't directly expose this capability to the outside world, you instead expose services with a more limited API and which can only be used in safe ways.
[1] Though we might support Unison compiling to the browser and there have already been efforts in that direction - https://share.unison-lang.org/@dfreeman/warp This would allow a Unison front end and back end to talk very seamlessly, without manual serialization or networking
Not a dumb question at all! Unison's type system uses Abilities (algebraic effects) for functional effect management. On a type level, that means we can prevent effects like "run arbitrary IO" on a distributed runtime. Things that run on shared infrastructure can be "sandboxed" and prevented with type safety.
The browser or mobile apps cannot execute arbitrary code on the server. Those would typically call regular Unison services in a standard API.
Unfortunately, there's massive drift between WebRTC implementations. The status quo is Google's, which is used by Chrome: https://webrtc.googlesource.com/src/
And everyone else has to play catch-up.
A big source of the drift is having a common library for SDP parsing, but also necessary features like BWE, different encodings, etc.
For example, aiortc, python's WebRTC implementation, isn't quite at the level most would want. It isn't necessarily easy to tell, without clear benchmarks, which implementation is at-par with Google's.
Why do you consider it the status quo? It isn’t used in servers, embedded devices or software like OBS. Yes it’s popular because of usage in Chromium/Mobile, but I don’t believe that qualifies it as status quo.
aiortc is good enough to empower lots of businesses/projects! If anything comes up that really is a show stopper it will get addressed.
I would second this. I have pretty extensive experience in a few python-like languages, and had written a few hundred lines of python over the years, but had never had a full-time job writing it. I had an upcoming job working on a python codebase. I found ExecuteProgram to be a pretty great as a way to bone up on intermediate python syntax, idioms, and standard library so I could minimize the first few weeks of "How do I do [common thing I know in 5 other languages] in python?"
How does Hetzner manage to be so much cheaper than AWS & GCP? Are the other cloud providers just making THAT much margin, or does Hetzner have a special angle?
> We try not to cross subsidize our products or services.
Could you then at least start offering object storage on top of your regular storage offerings in the cloud? You have repeatedly stated you won't do this, but I don't understand why. I think people using your services would pay a premium for an AWS compatible storage API.
If/when we are able to provide object storage in the future, we will announce it on our social media channels, our customer forum, and our customer newsletter. We are also always very grateful to anyone who posts our good news here on HN. --Katie
IIRC, they produce their own hardware (including using consumer-grade components, if I'm not mistaken) and optimize every bit for efficiency. Managed services also come with an extra fee. From my experience, they're also more selective about clients.
They're also based in Germany, so they don't have to pay the hyper-inflated SV salaries and probably don't overhire, but I'm only speculating here.
One thing that I like about working at Hetzner is that it is privately owned, so we don't have a bunch of investors expecting an ever-increasing return on their investments. We can re-invest profits in the company itself, in our infrastructure, and in our crew. --Katie
Consumer-grade is too expensive. Best price/performance with high utilization is Epyc 9654 based system. We build at roughly $7k/box for 96 cores, 768 GB RAM, 8 TiB of NVMe. You can't buy that yourself, though. You have to go through an integrator. We built our own because near 100% utilization on HFT sims and training.
AWS, Azure and GCP have much higher margins than Hetzner. So while I use these services when working for my employers because they pay me to do so, when I spend my own money on my startup I use Hetzner exclusively.
I have an impression that EC2 instances are priced so high to discourage their use and instead steer customers to managed services: S3, CludFront, Lamda, RDS, SQS, Fargate e. t. c.
a big problem in the space is that products that look very similar will be clustered in the same section. large models are very good at generalizing, so they may be more attuned to "this is a Christmas thing", but they won't know that it should be classified as the same UPC as the thing that was in that spot yesterday without you specifically telling it to. how would it know it's not a misplaced product or a random piece of trash? (you won't believe the things you find on store shelves once you start looking) you can definitely speed up your annotation time with something like SAM[1], but it will never know without training or context that it's the same product but Christmas (ie it resolves to the same UPC).
I have a dumb, and likely annoying, question: why isn't Rust the clear choice? I think it has to do with Zig's "interop with C" but this is very abstract for me. Is there a code example that shows something that's super easy in Zig but a PITA in Rust?
I've heard that Rust's types and compiler can be frustrating to deal with as well. Is Zig a more "joyful" programming language?
It's for sure the question that a lot of people have. Initially we had more details about that in the blog post, but we didn't want it to become a "Zig vs Rust" blog post, so we kept it to a minimum.
I will expand just a little bit more here:
First, I think the fact that Rust can be a trusted language for Postgres is a huge advantage, and I am excited about it! I hope we will have the chance to use it and contribute to pgrx as well.
Postgres is not only written in C, but it has developed its own particular style of C code. For example: arena memory allocator (memory contexts), exceptions via setjmp/longjmp (ereport), single-threaded communicating via shared memory, SPI for accessing the data via SQL, etc. Some of these mechanisms kind of conflict with the way Rust likes to do things.
Because of the above, pgrx has to do harder work to expose functionality. It's possible, just a lot of work. In Zig, we can use pretty much anything directly or with small wrappers.
If you need to call into C a lot, you need to use unsafe, and that negates some of the memory safety advantages of Rust. Also, Rust unsafe code is harder to write.
I haven't worked with pgzx, but it's possible that memory management is easier. Zig uses memory arenas, and so does Postgres. If one can map directly to the other, it would be a huge win.
With Rust/pgrx (which I have used, extensively) memory integration is more difficult. There's pg memory, and there's Rust memory, and they're not the same, and you have to play games to pass data between them. Lifetime issues crop up. Rust might be able to solve the problem in the future with custom allocators, but it's just not there yet.
> I haven't worked with pgzx, but it's possible that memory management is easier. Zig uses memory arenas, and so does Postgres. If one can map directly to the other, it would be a huge win.
Yes. This was indeed a great motivator for using Zig. It was quite easy to integrate Zig with the Postgres memory management. This way we can use the Zig standard library or other Zig libraries without a second thought. Another advantage is that in Postgres memory context cleanup and error handling are somewhat well integrated with each other. This gives us some peace of mind as almost any Postgres function you might want to use in your extension is likely to raise an exception.
I've heard that when working with complex data structures with Rust you often need to write unsafe code, which is a lot more painful to work with in Rust. Once in you are in unsafe land anyway, some people say Zig is more convenient.
I think so. However it looks to me Plannetscale tried to also become better database for developers... for databases big and small and utililize developer focused product lead growth.
I’m also curious how this looks with browser or mobile clients. Surely they’re not sending code to the server?