Earlier quoted context omitted.
Where do you use Go?
Backend to my.zerotier.com and internal analytics code.
Do you think that was the right choice, or would you have written that in Rust if you were starting today?
Rust without the async (hard) part
131–136 of 136 posts
Re: Rust without the async (hard) part
#132Earlier quoted context omitted.
Backend to my.zerotier.com and internal analytics code.
Do you think that was the right choice, or would you have written that in Rust if you were starting today?
Go is great for backend stuff like that. If we rewrote it from scratch today we might consider Rust though just to have only one language in the house... but Go is really good for that case.
We are using Rust for the ZeroTier network hypervisor and core system service though because that's systems-level software that is performance-critical, needs to fit on small-ish devices, and needs deterministic performance among other things.
They're really different languages for different niches. Rust is C++ 2.0. Go is fast compiled Python with a cleaner design. (Python is the best niche comparison I've found for Go.)
Re: Rust without the async (hard) part
#133Earlier quoted context omitted.
Do you think that was the right choice, or would you have written that in Rust if you were starting today?
Go is great for backend stuff like that. If we rewrote it from scratch today we might consider Rust though just to have only one language in the house... but Go is really good for that case. We are using Rust for the ZeroTier network hypervisor and core system service though because that's systems-level software that is performance-critical, needs to fit on small-ish devices, and needs deterministic performance among…
Very interesting! Thanks for the answers! :)
Re: Rust without the async (hard) part
#134Earlier quoted context omitted.
> There is no sane way to make async optional in a library and reuse code. FWIW, there's an effort to do exactly that, but because it will require language level changes and it is just on the drawing board phase, it will likely be a while before it can be widely used. The "optionality" of `async` while sharing code also applies for `const` and mutability (why do we need `Deref` and `DerefMut`?). Finding a solution th…
> FWIW, there's an effort to do exactly that Could you link where?
Re: Rust without the async (hard) part
#135Earlier quoted context omitted.
Yes, async is hard. It adds lots of complexity, both to the code and in your mental model. That slows development. I'd rather have faster development most times. It's why I prefer to use Go over Rust whenever possible. That's why I'm really interested in what lunatic is doing here. It might narrow the gap a little.
Yes, async is hard. It adds lots of complexity, both to the code and in your mental model. That slows development. Nodejs devs seem to be doing fine? and I would say their development is faster than most devs working on other stacks. Nodejs is also a top 3 server stack and growing.
NodeJS doesn't have all these gotchas around async that rust does. It's still harder than sync code, but it's more manageable.
The lack of a proper type system, only partially solved by typescript is a big drawback though, that eats into productivity.
Re: Rust without the async (hard) part
#136Earlier quoted context omitted.
This "async virality" syndrome is the main reason why async is harmful imho. _Some_ async can be very useful in certain constrained circumstances, I believe. However forcing the async execution model on all code is a terrible idea.
Yes. I've been saying this for some time. I call it "async contamination". The async model assumes you spend most of your time waiting for your slow users to do something. (Why a web site, which is inherently stateless, should be doing that routinely is another issue.) I'm writing a metaverse client that has about 10-20 threads, many of them compute bound, running at different priorities. Works fine, but is totally d…
I've been calling it cancer, but I get down voted for that.