At this point I see it as turn-off when a project like this uses Rust. Slow, massive tooling and such a huge barrier to entry, when we have Go, Zig or just C (this ends up being largely backed by libc/ucrt anyway?).
It’s still early in its development, but the Luau team is building a first-party standalone runtime called Lute (https://github.com/luau-lang/lute) that’s in C++ because the language’s implementation is also in C++. That might be more your speed?
Looks good. Better chance of success. Agree with the OP you are responding to, Rust might be great for those looking to write things from scratch, no baggage to deal with, not so great if you have to use it when written by someone else (even if that 'someone' is you from one year ago).
Dont disagree that compile times are slower compared to alternatives in this space, although I'm not sure I'd quite describe that as some sort of barrier to entry from contributing
Rust compile times are *really* fast compared to running Zig or Go through a static checker and then a compiler, to arrive at similar confidence in the behavior of the code as a single run through rustc.
It sounds like maybe you're used to skipping part of the development process required for stable well-tested software. Maybe that works for UIs? Wouldn't want my runtime authors feeling that way.
People who aren't developers generally install pre-built binaries. I know that's how almost every Linux distribution I've used for going on 30 years has worked.
Developers, on the other hand, seem to need some help running static checkers regularly. Most don't seem to have well exercised CI toolchains doing it for them. Or aren't aware that they should be doing so - like yourself.
Rust makes use of the tight integration between language, compiler, and checker to allow the language to be easier and more thoroughly checked than possible with checkers built for other languages. Many steps performed for compilation are reused. Which is what makes it so fast.
If you think "why can't I skip this?" you have missed the point and are exactly the target developer these checks are for.
I've written a lot of software. Never had a complaint about compile times in any language. The reality of developing with Rust is that after the first build, only changed files are rebuilt, which makes it just as fast to compile as any other language.
If compile times are what concerns you about a language, that tells me you're not very far along in your career. You have a lot more problems to discover which are very much more serious. If you ever encounter the problems Rust solves, you'll grow to appreciate it's solutions.
The smallest unit of compilation in Rust is the crate, not individual files unfortunately. That's why you'll see larger projects like Wezterm or uv use workspaces to try to tame compile times.
You're right that the crate, not the file, is the smallest unit of compilation.
My largest rust project is still fairly small at around 8k lines across two dozen files. Still, it builds and links in 30 seconds on my workstation which is several years old and not particularly fancy.
I could see this beginning to become an issue around 100k lines of code, but I'd think most people would be looking to split into multiple crates before that just for readability.
I can assume that Lune (and many of the Rust-based Luau runtimes that followed it) were written in Rust mainly because of the existence of mlua <https://github.com/mlua-rs/mlua> and the bindings it provides for Luau. Binding Luau in Zig or C isn't as plug-and-play but is still relatively easy, binding Luau in Go is a nightmare. I'm working on better Luau support for Go, and some support/binding libraries for other languages are also in development, which is awesome to see and will hopefully bring more language diversity to the Luau ecosystem.
Where is the barrier and what does it look like? Other systems languages have similar complexity, even though it may not be obvious when they don't enforce all their rules
Zig is just as much mental overhead. C and C++ are too, but most of us have amortized that cost already. Go is already a legacy language that probably shouldn't be used in production in most cases.
Go is already a legacy language that probably shouldn't be used in production in most cases.
This is objectively not true. “Go feels legacy to me and I wouldn’t use it in production in most cases” is reasonable, if you feel that way, but “legacy language” has a definition, and Go isn’t a legacy language.
Eager to hear any reply as to how you arrived at this take on Go. It feels like bait, but i like your projects and I’m willing to give you the benefit of the doubt.
From the beginning, the Go team always emphasized that it was basically just meant to replace Java and C++ for servers inside Google. One of the official Go doc pages starts off with a basically apologetic tone, saying something like "Go began back in 2007 when things were very different than they are now. C++ and Java were much worse, and that's basically what we were competing with." I can't find that page but being an official page, and having this kind of tone, already matches up with the tone the Go community always kind of had, of like, "it's not the perfect language and we acknowledge and own that fact, but at least it's better than the alternatives."
On top of this, in its excessive caution about adding features while balancing incidental and essential complexity, it just hasn't evolved and kept up to meet the kinds of demands modern languages do like Zig, Rust, C3, Carbon and Odin, and while these languages were innovating, Go was still catching up to 10-20 years ago at any given moment. It was already kind of a weird middle ground, not quite as high level as Ruby, not quite as low level as C++, and this slow catch up game plus lack of keeping up was, for me at least, just the nail in the coffin. But all of this together makes me personally think that it's just not a great fit for most scenarios, but also that it seemed to have started off on the wrong foot with itself and the wider programming community.
So definitely more of a vibe take than rigorous case, but stated well enough. I’m over here working in production in Java 9 (we got off of 8 this month!) so there is an aspect of living in different worlds as well.
Is it really fair to compare golang to languages that haven’t hit 1.0? Would you sincerely use zig or carbon in production before Go?
I just feel like “it’s better than the alternatives” is still true, and will be for a while. I would love if software wasn't best written in slightly older languages, but even c++ had growing pains for years.
If you compared it technically and semantically to stuff like swift or kotlin, i think the case would be stronger, but it’s hard to take production concerns seriously when comparing it to zig. (I make a monthly donation to zig, but i wouldn’t use it at work)
Yeah to be fair by "production" I meant I personally wouldn't use it for a long-term (5-10 year) project. I'm sure it's fine in an enterprise scenario, or a client who really wants you to use it and is willing to pay to make it worth it.
Honestly every language has warts, there are no perfect languages. I just personally don't like Go, mostly for the reasons stated above as well as in a recent article I can't find anymore but read a few weeks ago, mostly complaining about its well known ergonomics issues.
But yeah it's fine to use in prod for the same reason Java 6 and IE 6 were for a long time: nothing really matters but money when you're doing work work.
Comments
At this point I see it as turn-off when a project like this uses Rust. Slow, massive tooling and such a huge barrier to entry, when we have Go, Zig or just C (this ends up being largely backed by libc/ucrt anyway?).
It’s still early in its development, but the Luau team is building a first-party standalone runtime called Lute (https://github.com/luau-lang/lute) that’s in C++ because the language’s implementation is also in C++. That might be more your speed?
Looks good. Better chance of success. Agree with the OP you are responding to, Rust might be great for those looking to write things from scratch, no baggage to deal with, not so great if you have to use it when written by someone else (even if that 'someone' is you from one year ago).
whats the actual barrier? installing rust? looking at the instructions this doesnt seem much harder than installing zig or go?
It isn’t, arguably easier than installing Go (no GOPATH). Rust compile times are really slow compared to Zig or Go though.
(Edit: As this seems to trigger some people: I code in Rust. I’m just stating the facts.)
Just FYI: GOPATH isn't a thing anymore.
Dont disagree that compile times are slower compared to alternatives in this space, although I'm not sure I'd quite describe that as some sort of barrier to entry from contributing
Rust compile times are *really* fast compared to running Zig or Go through a static checker and then a compiler, to arrive at similar confidence in the behavior of the code as a single run through rustc.
It sounds like maybe you're used to skipping part of the development process required for stable well-tested software. Maybe that works for UIs? Wouldn't want my runtime authors feeling that way.
Why run a static checker in every single machine you compile a project on if a developer already ran it elsewhere?
You can install pre built binaries if you are not concerned about developing new features.
People who aren't developers generally install pre-built binaries. I know that's how almost every Linux distribution I've used for going on 30 years has worked.
Developers, on the other hand, seem to need some help running static checkers regularly. Most don't seem to have well exercised CI toolchains doing it for them. Or aren't aware that they should be doing so - like yourself.
Rust makes use of the tight integration between language, compiler, and checker to allow the language to be easier and more thoroughly checked than possible with checkers built for other languages. Many steps performed for compilation are reused. Which is what makes it so fast.
If you think "why can't I skip this?" you have missed the point and are exactly the target developer these checks are for.
I've written a lot of software. Never had a complaint about compile times in any language. The reality of developing with Rust is that after the first build, only changed files are rebuilt, which makes it just as fast to compile as any other language.
If compile times are what concerns you about a language, that tells me you're not very far along in your career. You have a lot more problems to discover which are very much more serious. If you ever encounter the problems Rust solves, you'll grow to appreciate it's solutions.
The smallest unit of compilation in Rust is the crate, not individual files unfortunately. That's why you'll see larger projects like Wezterm or uv use workspaces to try to tame compile times.
You're right that the crate, not the file, is the smallest unit of compilation.
My largest rust project is still fairly small at around 8k lines across two dozen files. Still, it builds and links in 30 seconds on my workstation which is several years old and not particularly fancy.
I could see this beginning to become an issue around 100k lines of code, but I'd think most people would be looking to split into multiple crates before that just for readability.
I can assume that Lune (and many of the Rust-based Luau runtimes that followed it) were written in Rust mainly because of the existence of mlua <https://github.com/mlua-rs/mlua> and the bindings it provides for Luau. Binding Luau in Zig or C isn't as plug-and-play but is still relatively easy, binding Luau in Go is a nightmare. I'm working on better Luau support for Go, and some support/binding libraries for other languages are also in development, which is awesome to see and will hopefully bring more language diversity to the Luau ecosystem.
Where is the barrier and what does it look like? Other systems languages have similar complexity, even though it may not be obvious when they don't enforce all their rules
Zig is just as much mental overhead. C and C++ are too, but most of us have amortized that cost already. Go is already a legacy language that probably shouldn't be used in production in most cases.
This is objectively not true. “Go feels legacy to me and I wouldn’t use it in production in most cases” is reasonable, if you feel that way, but “legacy language” has a definition, and Go isn’t a legacy language.
Eager to hear any reply as to how you arrived at this take on Go. It feels like bait, but i like your projects and I’m willing to give you the benefit of the doubt.
From the beginning, the Go team always emphasized that it was basically just meant to replace Java and C++ for servers inside Google. One of the official Go doc pages starts off with a basically apologetic tone, saying something like "Go began back in 2007 when things were very different than they are now. C++ and Java were much worse, and that's basically what we were competing with." I can't find that page but being an official page, and having this kind of tone, already matches up with the tone the Go community always kind of had, of like, "it's not the perfect language and we acknowledge and own that fact, but at least it's better than the alternatives."
On top of this, in its excessive caution about adding features while balancing incidental and essential complexity, it just hasn't evolved and kept up to meet the kinds of demands modern languages do like Zig, Rust, C3, Carbon and Odin, and while these languages were innovating, Go was still catching up to 10-20 years ago at any given moment. It was already kind of a weird middle ground, not quite as high level as Ruby, not quite as low level as C++, and this slow catch up game plus lack of keeping up was, for me at least, just the nail in the coffin. But all of this together makes me personally think that it's just not a great fit for most scenarios, but also that it seemed to have started off on the wrong foot with itself and the wider programming community.
That's my take at least.
Found it:
https://go.dev/doc/faq#What_is_the_purpose_of_the_project
So definitely more of a vibe take than rigorous case, but stated well enough. I’m over here working in production in Java 9 (we got off of 8 this month!) so there is an aspect of living in different worlds as well.
Is it really fair to compare golang to languages that haven’t hit 1.0? Would you sincerely use zig or carbon in production before Go?
I just feel like “it’s better than the alternatives” is still true, and will be for a while. I would love if software wasn't best written in slightly older languages, but even c++ had growing pains for years.
If you compared it technically and semantically to stuff like swift or kotlin, i think the case would be stronger, but it’s hard to take production concerns seriously when comparing it to zig. (I make a monthly donation to zig, but i wouldn’t use it at work)
Yeah to be fair by "production" I meant I personally wouldn't use it for a long-term (5-10 year) project. I'm sure it's fine in an enterprise scenario, or a client who really wants you to use it and is willing to pay to make it worth it.
Honestly every language has warts, there are no perfect languages. I just personally don't like Go, mostly for the reasons stated above as well as in a recent article I can't find anymore but read a few weeks ago, mostly complaining about its well known ergonomics issues.
But yeah it's fine to use in prod for the same reason Java 6 and IE 6 were for a long time: nothing really matters but money when you're doing work work.
What reasons would you have for classifying Go as a legacy language and why would you not use it in production?