Hopefully this provides good impetus for a better portability story with Rust. It’d be a shame if the kernel were impacted because of a Rust compiler’s port being tier 2 having effects.
I’m actually pretty surprised that there doesn’t seem to be a strong backlash against the idea. Perhaps it’s simply because of who the thread participants are? My impression, so far, has been that C programmers tend to be fairly anti-Rust, for one reason or another.
I’m not a fan of Rust at all but it’s a more logical language to add support to the kernel for than many. Indeed I can’t think of a better candidate from currently popular languages. It has the same “compile to efficient code without a massive runtime or any garbage collection” emphasis as C, more so than C++.
Arguably Zig has even more emphasis on “better C” rather than “better C++”, but it also has the same downsides (single main implementation tied to LLVM rather than being a standardized language with multiple independent implementations) while Rust has way more maturity and momentum.
Usually technologies that are same-but-better have difficulty getting adopted, because an incremental benefit doesn’t seem worth a big switching cost.
Rust dodges this by being significantly different at the same time. It’s not just C with a borrow checker, but brings new programming style and new idioms into the systems programming niche.
I assume it’s because despite whatever problems the language may have, it seems to be the only safe language that doesn’t require a whole supporting runtime
I have minimal experience in the realm of such low-level programming, but I am very interested in programming languages. As an outsider, I have heard many positive things about Rust, but perhaps my view of the subject is limited. Out of curiosity, what informed your impression that C programmers tend to be anti-Rust? As an outsider and programming language enthusiast, I am always very interested to know how people approach new programming languages.
I don’t know if C programmers are generally anti-rust (I’ve seen some people who do regular work in C and really enjoy Rust. I think Bryan Cantrill is one). But the people I’ve seen negative comments from tend to use C, C++ or Go for lower level programming and not see the point.
I have some experience with OS/low-level C, but not kernel-maintainer level, but I’ll guess anyway:
C is at it’s core rather simple. When using the language for real-world applications, you’ll encounter all the concepts pretty quickly. There are a few quirks in the syntax that one might not expect (eg. interleaving a switch-case and a loop is possible), but all in all, the core is clean. Rust, from my experience has more primitives, it changes a lot, quickly (afaik).
Another thing that comes to mind is the development environment/tooling. C’ development environment is basically everything and nothing, because a properly setup *nix operating system is basically already a development environment. The system is sort of defined and expanding in terms of itself, with make and such. Rust brings it’s own keychain, for reasons I don’t think are illegitimate, but makes it seem “alien”, not as “native” as C.
That’s just my take from someone who still hasn’t finished more than 20% of the Rust Book (though not just because of the points I just mentioned), so my possible misconceptions about the language are intentional.
One doesn’t maintain a language, one maintains software. C “the language” is simple. The memory model is transparent, the syntax is clean, but of course too much simplicity can lead to an overcompensation of site-local complexity in larger projects, to make up for concepts you are missing (both from a usability and safety perspective), which is probably what you are referring to – but that’s not the same as to say that C is complicated.
The problem is that “simplicity” isn’t worth anything when it creates complexity everywhere else.
You want thread safety? Good luck! You want optimized, reusable containers? Ugh, maybe an include header hack will do? You want memory safety? Better get fuzzing. You want dependencies, portability or cross-compilation? You’ll never stop getting bug reports about your build scripts.
Fair enough, but the people who value the simplicity of the language over the environment, as to probably those who prefer C over Rust, would disagree, which is fine.
So, and I mean this only slightly facetiously, is there any point in learning any language other than Rust at this point? I feel like all the momentum is with Rust and that languages like Go (which I prefer to Rust), the ML languages, and C++ are all dead in the water and basically just in maintaining-existing-codebases mode…
In other words, for the vast majority of non-web/non-desktop projects it would seem silly given the current zeitgeist to start them in any language other than Rust/JavaScript.
(I say this because the Linux kernel is notoriously conservative on language use, and with good reason…obviously other languages are gonna be around a long time but it seems like the only compiled typed language I hear about anymore is Rust.)
Haskell and Ocaml are still moving forward well. Haskell recently merged in Linear Types, which goes a long way to making the type system both richer and more intuitive.
C++ are all dead in the water
Take a look at C++20. It has some great features. Some undoubtedly inspired by Rust, but many others that have been working their way into the standard for over a decade. C++20 has lambdas, option types, awkward[1] sum types, designated initializers, and more.
In other words, for the vast majority of non-web/non-desktop projects it would seem silly given the current zeitgeist to start them in any language other than Rust/JavaScript.
At the end of the day, Rust is still a low-level language [2], which means the programmer is in charge of keeping track of when data is copied, when references to data are passed around, and when data goes out of scope. While the borrow checker certainly helps in this process, it’s still something that the programmer needs to be aware of while coding, and this has its own cognitive load. Often times, when programmers reach for a low-level language, it is specifically because they want to tackle some aspect of memory management (whether that’s custom allocation, data sharing, real-time performance, or other things) differently from the way a more standard managed runtime would. This can lead to situations where the borrow checker can actually make it more, rather than less, difficult (due to non-standard memory management techniques that the programmer consciously wants to undertake) to develop and reason about code.
Rust is also difficult to use in the following situations:
Interfacing with binary libraries
Using an alternate libc
Using a custom memory allocator
Developing for the Android NDK
Moreover, Rust is a complicated language. The surface area of the language is large and that makes understanding its nuances both difficult and, at times, time consuming. Other languages like Nim and Zig take alternate decisions that also enable low-level development with greater safety and lower cognitive load than C.
Then there’s the world of scientific computing. C++, C, and Fortran have long been the stalwarts of scientific computing, but now we have a new crop of dynamic languages like Python, Julia, and R, that are all great. Rust still lacks interfaces to many of the really big scientific-computing frameworks[3], whereas many frameworks (such as Stan or CLASP) are written in C++ and offer C++ libraries out of the box, along with Python, R, and sometimes Julia wrappers. One can certainly wrap the interface for these libraries themselves into Rust, but in C++ or Python, I can just grab the library and start developing.
I think it’s unfortunate that due to the vocal Rust fanbase on certain parts of the internet that some folks feel pressured to use Rust. Rust is a fantastic language (IMO), but there certainly are interesting, performant, and practical alternatives out there that can often be better for certain usecases.
[1]: I call them awkward because they aren’t as neatly baked into the language as they are in Rust, but C++ offers the well written any and variant types.
[2]: It’s funny because literature from a few decades ago largely considered C++ to be a “higher level language”, but here we are.
[3]: Others often call this machine learning, but the proliferation of scientific computing is not at all restricted to ML. Stan is a Bayesian inference library and CLASP is an Answer-Set Programming language/environment.
I think C++’s problem has never been its lack of features.
My approach has served me quite well: If I see new software being written in C or C++, I’m going to ask “why?” – and if there is no really really convincing reason – I stay away.
With my initial contributor of Android support for Rust hat on, I am curious about this. Yes, it always could be better, but what’s the specific problem? Rust for Android is production ready, in the literal sense of the word. It has been years since Firefox for Android (>100M installs) shipped millions of lines of Rust code in production. Cloudflare also shipped WARP for Android, whose WireGuard implementation is written in Rust.
It’s funny because literature from a few decades ago largely considered C++ to be a “higher level language”, but here we are.
“High” is a great term for describing languages this way, because it’s inherently context dependant; you can be high on a ladder or high on an aeroplane. That the heights are so different is not a problem; you wouldn’t use an aeroplane to clean your roof.
I think for down and dirty systems programming, probably not.
For distributed systems, Java is still in the mix at most companies. Rust isn’t really what I would call “web yet” (despite what the web site says) and Go is a much easier lift for that sort of backend work.
I think there is still a good number of options on the backend.
For the front end, I would only consider TypeScript at this point.
i’m personally perfectly happy using ocaml, and i think the language has a decent bit of momentum these days. it’s a really good statically compiled applications language; it’s not quite a systems language but then neither is go, both of them depend on a gc.
for a systems-level language i’m really hoping that D will catch on as cleaner than C++, more capable than go and easier to use than rust, but it doesn’t seem to be gaining popularity as fast as it should. rust is a perfectly fine language too and i keep meaning to do a serious project in it, but it definitely has a higher entry barrier than D does.
I don’t think it’s so black and white. Go has some serious momentum right now. It’s a very pragmatic and practically useful language. Rust is great but has many downsides, e.g. the compiler isn’t anywhere close to as fast and it is far more complex to learn and use.
Go has occupied the “devops tools” niche, but thankfully it didn’t really take off anywhere else.
the compiler isn’t anywhere close to as fast
It’s gotten really good at being incremental though. Even on my low-power laptop, cargo run after changing a couple source files is pretty quick. Faster than TypeScript for sure. Also I wonder how many Linux users are just losing lots of time to linking with some awfully slow linker like GNU BFD ld instead of LLD.
but thankfully it didn’t really take off anywhere else.
Not sure what you mean here. It’s the language of the cloud. Every major cloud provider has an official Go SDK and the Go team at Google is actively involved in supporting this. Many of the CNCF projects are written in Go.
e.g. see go-cloud or the support in gcloud functions.
For CLI tools as well, it’s become preferred over scripting languages like python and ruby. e.g. fzf is written in Go, the new GitHub CLI is in Go. While rust is used in newer CLIs as well, it’s usually only for performance critical CLIs like ripgrep.
It’s gotten really good at being incremental though.
Agreed. I still appreciate just how insanely quick Go is, especially when building on a new machine or pulling a dependency. I never have to really wait for things to compile.
That is exactly what I meant by ‘the “devops tools” niche’! Maybe I should’ve used the “cloud” buzzword instead of “devops”, but I like calling it “devops”.
e.g. fzf is written in Go
fzf is hardly a unique tool, I have a list of these things here :) Personally I use fzy, which is pretty popular and actively developed, is packaged everywhere, has a very good matching algorithm.. and is written in C, haha.
the new GitHub CLI is in Go
Yep, that kind of thing is what I’m not very happy about, but it’s still a pretty small amount of things still, and I can successfully avoid running any Go code on any of my personal machines.
Yep, that kind of thing is what I’m not very happy about, but it’s still a pretty small amount of things still, and I can successfully avoid running any Go code on any of my personal machines.
Why does it matter whether a binary you use on your machine is written in Go or not? If you’re building it from source, presumably your distribution’s build scripts should take care of orchestrating whatever Go code is necessary in order to compile the package; and if you’re just pulling an executable why does it matter what language was used to produce the binary?
I think GP’s answer is great and insightful, just adding my own take:
I try to avoid code by people who think LARPing programming-in-the-1960ies is a reasonable choice to build things in 2020, because I’d rather not find out which other “reasonable” choices they have made further down the line.
Also, the community’s anti-intellectualism is off-putting for me.
I’m the kind of person who cares about how the sausage is made :) If I can “boycott” things I just don’t like, I’ll do it. Here’s a great criticism of the language, but what made me hate it was the internals of the implementation:
the fully static binary thing, not even using libc syscall wrappers
first obvious practical problem: you can’t hook syscalls with LD_PRELOAD in go binaries! I don’t want any binaries where LD_PRELOAD does nothing.
they do raw syscalls even on FreeBSD, where libc is the public API and raw syscalls are not. They completely ignored FreeBSD developers’ messages about this and went ahead with the private API. Yeah sure, the syscalls are backwards compatible, it works fine (until someone disables COMPAT_FREEBSDn kernel options but whatever)..
but porting to a new platform is hell! Yeah, for the most popular ABI (Linux) there’s enough contributors to write custom syscall wrappers for all CPU architectures, but any {less-popular OS + less-popular CPU ISA} combo just won’t be supported for a long time. I’ve started porting Go to FreeBSD/aarch64, abandoned it in frustration, but others have picked it up and finished it. Cool, I guess. But we’ll have the same problem with FreeBSD/powerpc64, FreeBSD/riscv64 etc! (This is the most “practical” consideration here, yes.)
which brings me to how these syscall wrappers (and other things) have to be written.. Go uses a very custom toolchain with a very custom assembler which is completely alien to normal unix conventions. It’s not easy to write it. Oh, also, it is rather half-assed (this affects applications way more than it affects porting Go itself):
it doesn’t support SIMD instructions, and if you want to call something fast written in C or normal sane assembly, you’d have to take the overhead of cgo (because the Go calling convention is custom)
and to not take the overhead, people have written things like c2goasm. Just read that readme and let that sink in!!
it doesn’t even seem to support all addressing modes of amd64! When writing a binding to SIMD base64, I couldn’t use c2goasm because I couldn’t express mov al, byte ptr [rax + base64_table_enc] in Go assembly. (There were probably ways around it, like only passing the offset into the normal-assembly functions and letting them use that offset to look up in the table.. but I was already fed up with the awfulness and just used cgo.)
(I’d like to point out that I too care how the sausage is made and I loved your phrasing on that point.)
Obviously what follows is solely my opinion, but I feel like some of those criticisms are unjustified.
From your comment:
The static binary thing is a huge boon in some situations. We have a remarkably heterogenous mix of Linux versions in the field and yet the same Go binary “just works” on all of them. That’s an enormous burden off our backs.
That Go’s assembler is weird is I suppose problematic, but for the “average user” of Go that’s just an implementation detail that can be safely ignored.
From the linked rant:
Yes the file permissions APIs are weird because the models for Windows and *nix are so different. I feel like that’s a very specific issue that the rant generalizes to the whole language. In general, a large part of the rant focuses on how Go doesn’t do the right thing for Windows which may be true but it doesn’t seem to be quite that bad…I know a lot of people who have written large Go codebases that run on Windows and are very happy with it. In the rant it comes across, IMHO, as nitpicking.
Later on the rant goes on about how a Go project pulls in a bunch of dependencies and then transitively pulls in even more and so on…I feel like comparing that to Rust isn’t quite fair. I’m not super-familiar with Rust but several of the projects I’ve looked at pull in huge numbers of crates which pull in more crates and so on. It seems like it might even be worse in Rust because of the smaller standard library and, given the Actix controversy, it doesn’t seem like you can rely on third-party Rust crates being inherently safe.
Finally, though, and these are again my opinion:
Rust feels chaotic. There’s no formal specification of the language. The Rustonomicon says this:
Unfortunately, Rust hasn’t actually defined its aliasing model. 🙀
While we wait for the Rust devs to specify the semantics of their language, let’s use the next section to discuss what aliasing is in general, and why it matters.
That does not fill me with warm fuzzies.
Documentation seems lacking. There are a lot of TODOs everywhere.
There’s a new release every six weeks so I always feel like I’m playing catch-up. The “Editions” mechanism seems to help some here, but I went to try to build a Rust program (alacritty) and my Rust version was too old…and it wasn’t that old.
I don’t like the community. I know that this may come as a shock but I have gotten this “superiority complex” feeling from the Rust community. Any criticism of or concerns about the language seems to be met with “no, you’re wrong, Rust is the best! Your language sucks! Why would you use any tool other than Rust?” Sometimes it’s more polite but it’s still there. Any time someone talks about another language (Go, C++, whatever), someone has to come in and say “why don’t you rewrite it in Rust?” There have been times where I’ve seen on SO or Twitter people almost being made to feel foolish for daring to use some language other than Rust.
Again on the community, one of the core developers made a joke about C being designed by men and breaking constantly and COBOL being designed by women and just working. When a guy on Twitter said that was kinda sexist, she accused him of “mansplaining” and said he was telling her the joke was sexist rather than understanding its “obvious meaning” (which apparently wasn’t so obvious)…which I found kind of bothersome, especially since the community seemed to agree and anyone who took offense was called sexist (and trust me, I’m as leftist/feminist as they come but that doesn’t and shouldn’t mean that I hate men). This again felt like the “Rust community is superior” thing again: the Rust community was correct and those who disagreed with them were wrong, inherently so.
We have a remarkably heterogenous mix of Linux versions in the field and yet the same Go binary “just works” on all of them
Sure, do that on Linux where the syscalls are the public API. Zig does that too, but IIRC it has an option to use libc on Linux, so you could make LD_PRELOAD work and everything, say when you’re building distro packages or personal binaries that you don’t want running on ancient distros.
I just really don’t like that a) there’s no choice, only direct usage of syscalls and b) this is forced on platforms that don’t consider raw syscalls as public API.
(Also, something dynamically linked to glibc will work on all glibc distros of the last N years if you use the headers from an N years old version. With a language like Rust that has its own definitions of libc symbols instead of C headers, these definitions usually are as backwards-compatible as possible already.)
for the “average user” of Go that’s just an implementation detail that can be safely ignored
Yes. Well, I’ve seen what’s inside, so it’s my mission to tell everyone how cursed it is there. Feel free to ignore me!
After all, all of computing is cursed on the inside somewhere :D But these particular experiences are what made me scream at computers the most, so I’m sharing them. Some people do care about implementation details of a thing even when they don’t modify that thing specifically.
There’s a new release every six weeks so I always feel like I’m playing catch-up
Use nightly! :P
someone has to come in and say “why don’t you rewrite it in Rust?”
At least on /r/rust this kind of stuff usually downvoted into oblivion.
Twitter is a trash fire that brings the worst out in people. Heck, some people tweeting that might not have written a line of Rust ever, just shitposting memes they’ve heard somewhere.
trust me, I’m as leftist/feminist as they come but that doesn’t and shouldn’t mean that I hate men
Well that should mean hopefully having a (n extremely-online ironic millennial) sense of humor :) I wouldn’t start serious Discourse™ in defense of the joke, but I’m okay with the joke. “sexism against men” isn’t really meaningful because men are the more dominant group in current societies. (oops did I just start a Discourse?) Anyway tbh you don’t have to “hate” anyone to find this funny.
trust me, I’m as leftist/feminist as they come but that doesn’t and shouldn’t mean that I hate men
Well that should mean hopefully having a (n extremely-online ironic millennial) sense of humor :) I wouldn’t start serious Discourse™ in defense of the joke, but I’m okay with the joke. “sexism against men” isn’t really meaningful because men are the more dominant group in current societies. (oops did I just start a Discourse?) Anyway tbh you don’t have to “hate” anyone to find this funny.
No doubt. The joke itself was funny. What bothered me was that someone responded with a polite “hey, that seems uncool” and then that person was called “sexist” and a “mansplainer”. I’m all for off-color humor but if someone you’re ostensibly trying to welcome to the community says that it bothered them, the correct response is “sorry, it was a joke but I could see how it could be taken in that manner and I apologize”…not attacking them. That this behavior was from a Rust core team member made it even worse.
But that whole thing was really just a footnote. What pushes me away more is the constant slamming of other tools and languages, which really gets grating. I don’t hang out on Reddit (if I wanted to hear about how COVID-19 is a plot by Obama to make Trump look bad or how same-sex marriage is Satanism I’d just talk to my father-in-law) but the…zealous…behavior of Rustaceans pops up just about everywhere I frequent, including my beloved lobste.rs from time to time..
Long story short (too late!), I like Rust quite a bit, but there are some negatives that I wish would be addressed.
Hopefully this provides good impetus for a better portability story with Rust. It’d be a shame if the kernel were impacted because of a Rust compiler’s port being tier 2 having effects.
I’m actually pretty surprised that there doesn’t seem to be a strong backlash against the idea. Perhaps it’s simply because of who the thread participants are? My impression, so far, has been that C programmers tend to be fairly anti-Rust, for one reason or another.
I’m not a fan of Rust at all but it’s a more logical language to add support to the kernel for than many. Indeed I can’t think of a better candidate from currently popular languages. It has the same “compile to efficient code without a massive runtime or any garbage collection” emphasis as C, more so than C++.
Arguably Zig has even more emphasis on “better C” rather than “better C++”, but it also has the same downsides (single main implementation tied to LLVM rather than being a standardized language with multiple independent implementations) while Rust has way more maturity and momentum.
Usually technologies that are same-but-better have difficulty getting adopted, because an incremental benefit doesn’t seem worth a big switching cost.
Rust dodges this by being significantly different at the same time. It’s not just C with a borrow checker, but brings new programming style and new idioms into the systems programming niche.
I assume it’s because despite whatever problems the language may have, it seems to be the only safe language that doesn’t require a whole supporting runtime
There’s a great talk from Bryan Cantrill about the whys: https://youtu.be/HgtRAbE1nBM
I have minimal experience in the realm of such low-level programming, but I am very interested in programming languages. As an outsider, I have heard many positive things about Rust, but perhaps my view of the subject is limited. Out of curiosity, what informed your impression that C programmers tend to be anti-Rust? As an outsider and programming language enthusiast, I am always very interested to know how people approach new programming languages.
I don’t know if C programmers are generally anti-rust (I’ve seen some people who do regular work in C and really enjoy Rust. I think Bryan Cantrill is one). But the people I’ve seen negative comments from tend to use C, C++ or Go for lower level programming and not see the point.
FWIW: Bryan Cantrills new company (oxide) is a Rust shop.
I have some experience with OS/low-level C, but not kernel-maintainer level, but I’ll guess anyway:
C is at it’s core rather simple. When using the language for real-world applications, you’ll encounter all the concepts pretty quickly. There are a few quirks in the syntax that one might not expect (eg. interleaving a switch-case and a loop is possible), but all in all, the core is clean. Rust, from my experience has more primitives, it changes a lot, quickly (afaik).
Another thing that comes to mind is the development environment/tooling. C’ development environment is basically everything and nothing, because a properly setup *nix operating system is basically already a development environment. The system is sort of defined and expanding in terms of itself, with make and such. Rust brings it’s own keychain, for reasons I don’t think are illegitimate, but makes it seem “alien”, not as “native” as C.
That’s just my take from someone who still hasn’t finished more than 20% of the Rust Book (though not just because of the points I just mentioned), so my possible misconceptions about the language are intentional.
My impression is that C is only simple if maintaining and debugging the code is someone else’s problem.
One doesn’t maintain a language, one maintains software. C “the language” is simple. The memory model is transparent, the syntax is clean, but of course too much simplicity can lead to an overcompensation of site-local complexity in larger projects, to make up for concepts you are missing (both from a usability and safety perspective), which is probably what you are referring to – but that’s not the same as to say that C is complicated.
The problem is that “simplicity” isn’t worth anything when it creates complexity everywhere else.
You want thread safety? Good luck! You want optimized, reusable containers? Ugh, maybe an include header hack will do? You want memory safety? Better get fuzzing. You want dependencies, portability or cross-compilation? You’ll never stop getting bug reports about your build scripts.
Fair enough, but the people who value the simplicity of the language over the environment, as to probably those who prefer C over Rust, would disagree, which is fine.
https://cdecl.org
So, and I mean this only slightly facetiously, is there any point in learning any language other than Rust at this point? I feel like all the momentum is with Rust and that languages like Go (which I prefer to Rust), the ML languages, and C++ are all dead in the water and basically just in maintaining-existing-codebases mode…
In other words, for the vast majority of non-web/non-desktop projects it would seem silly given the current zeitgeist to start them in any language other than Rust/JavaScript.
(I say this because the Linux kernel is notoriously conservative on language use, and with good reason…obviously other languages are gonna be around a long time but it seems like the only compiled typed language I hear about anymore is Rust.)
Haskell and Ocaml are still moving forward well. Haskell recently merged in Linear Types, which goes a long way to making the type system both richer and more intuitive.
Take a look at C++20. It has some great features. Some undoubtedly inspired by Rust, but many others that have been working their way into the standard for over a decade. C++20 has lambdas, option types, awkward[1] sum types, designated initializers, and more.
At the end of the day, Rust is still a low-level language [2], which means the programmer is in charge of keeping track of when data is copied, when references to data are passed around, and when data goes out of scope. While the borrow checker certainly helps in this process, it’s still something that the programmer needs to be aware of while coding, and this has its own cognitive load. Often times, when programmers reach for a low-level language, it is specifically because they want to tackle some aspect of memory management (whether that’s custom allocation, data sharing, real-time performance, or other things) differently from the way a more standard managed runtime would. This can lead to situations where the borrow checker can actually make it more, rather than less, difficult (due to non-standard memory management techniques that the programmer consciously wants to undertake) to develop and reason about code.
Rust is also difficult to use in the following situations:
Moreover, Rust is a complicated language. The surface area of the language is large and that makes understanding its nuances both difficult and, at times, time consuming. Other languages like Nim and Zig take alternate decisions that also enable low-level development with greater safety and lower cognitive load than C.
Then there’s the world of scientific computing. C++, C, and Fortran have long been the stalwarts of scientific computing, but now we have a new crop of dynamic languages like Python, Julia, and R, that are all great. Rust still lacks interfaces to many of the really big scientific-computing frameworks[3], whereas many frameworks (such as Stan or CLASP) are written in C++ and offer C++ libraries out of the box, along with Python, R, and sometimes Julia wrappers. One can certainly wrap the interface for these libraries themselves into Rust, but in C++ or Python, I can just grab the library and start developing.
I think it’s unfortunate that due to the vocal Rust fanbase on certain parts of the internet that some folks feel pressured to use Rust. Rust is a fantastic language (IMO), but there certainly are interesting, performant, and practical alternatives out there that can often be better for certain usecases.
[1]: I call them awkward because they aren’t as neatly baked into the language as they are in Rust, but C++ offers the well written
anyandvarianttypes.[2]: It’s funny because literature from a few decades ago largely considered C++ to be a “higher level language”, but here we are.
[3]: Others often call this machine learning, but the proliferation of scientific computing is not at all restricted to ML. Stan is a Bayesian inference library and CLASP is an Answer-Set Programming language/environment.
I think C++’s problem has never been its lack of features.
My approach has served me quite well: If I see new software being written in C or C++, I’m going to ask “why?” – and if there is no really really convincing reason – I stay away.
With my initial contributor of Android support for Rust hat on, I am curious about this. Yes, it always could be better, but what’s the specific problem? Rust for Android is production ready, in the literal sense of the word. It has been years since Firefox for Android (>100M installs) shipped millions of lines of Rust code in production. Cloudflare also shipped WARP for Android, whose WireGuard implementation is written in Rust.
“High” is a great term for describing languages this way, because it’s inherently context dependant; you can be high on a ladder or high on an aeroplane. That the heights are so different is not a problem; you wouldn’t use an aeroplane to clean your roof.
I guess you mean GHC, not (standard) Haskell, insofar that even exists.
I think for down and dirty systems programming, probably not.
For distributed systems, Java is still in the mix at most companies. Rust isn’t really what I would call “web yet” (despite what the web site says) and Go is a much easier lift for that sort of backend work.
I think there is still a good number of options on the backend.
For the front end, I would only consider TypeScript at this point.
i’m personally perfectly happy using ocaml, and i think the language has a decent bit of momentum these days. it’s a really good statically compiled applications language; it’s not quite a systems language but then neither is go, both of them depend on a gc.
for a systems-level language i’m really hoping that D will catch on as cleaner than C++, more capable than go and easier to use than rust, but it doesn’t seem to be gaining popularity as fast as it should. rust is a perfectly fine language too and i keep meaning to do a serious project in it, but it definitely has a higher entry barrier than D does.
I don’t think it’s so black and white. Go has some serious momentum right now. It’s a very pragmatic and practically useful language. Rust is great but has many downsides, e.g. the compiler isn’t anywhere close to as fast and it is far more complex to learn and use.
Go has occupied the “devops tools” niche, but thankfully it didn’t really take off anywhere else.
It’s gotten really good at being incremental though. Even on my low-power laptop,
cargo runafter changing a couple source files is pretty quick. Faster than TypeScript for sure. Also I wonder how many Linux users are just losing lots of time to linking with some awfully slow linker like GNU BFD ld instead of LLD.Not sure what you mean here. It’s the language of the cloud. Every major cloud provider has an official Go SDK and the Go team at Google is actively involved in supporting this. Many of the CNCF projects are written in Go.
e.g. see go-cloud or the support in gcloud functions.
For CLI tools as well, it’s become preferred over scripting languages like python and ruby. e.g. fzf is written in Go, the new GitHub CLI is in Go. While rust is used in newer CLIs as well, it’s usually only for performance critical CLIs like ripgrep.
Agreed. I still appreciate just how insanely quick Go is, especially when building on a new machine or pulling a dependency. I never have to really wait for things to compile.
That is exactly what I meant by ‘the “devops tools” niche’! Maybe I should’ve used the “cloud” buzzword instead of “devops”, but I like calling it “devops”.
fzf is hardly a unique tool, I have a list of these things here :) Personally I use fzy, which is pretty popular and actively developed, is packaged everywhere, has a very good matching algorithm.. and is written in C, haha.
Yep, that kind of thing is what I’m not very happy about, but it’s still a pretty small amount of things still, and I can successfully avoid running any Go code on any of my personal machines.
Why does it matter whether a binary you use on your machine is written in Go or not? If you’re building it from source, presumably your distribution’s build scripts should take care of orchestrating whatever Go code is necessary in order to compile the package; and if you’re just pulling an executable why does it matter what language was used to produce the binary?
I think GP’s answer is great and insightful, just adding my own take:
I try to avoid code by people who think LARPing programming-in-the-1960ies is a reasonable choice to build things in 2020, because I’d rather not find out which other “reasonable” choices they have made further down the line.
Also, the community’s anti-intellectualism is off-putting for me.
I’m the kind of person who cares about how the sausage is made :) If I can “boycott” things I just don’t like, I’ll do it. Here’s a great criticism of the language, but what made me hate it was the internals of the implementation:
libcsyscall wrappersLD_PRELOADin go binaries! I don’t want any binaries whereLD_PRELOADdoes nothing.libcis the public API and raw syscalls are not. They completely ignored FreeBSD developers’ messages about this and went ahead with the private API. Yeah sure, the syscalls are backwards compatible, it works fine (until someone disablesCOMPAT_FREEBSDnkernel options but whatever)..mov al, byte ptr [rax + base64_table_enc]in Go assembly. (There were probably ways around it, like only passing the offset into the normal-assembly functions and letting them use that offset to look up in the table.. but I was already fed up with the awfulness and just used cgo.)(I’d like to point out that I too care how the sausage is made and I loved your phrasing on that point.)
Obviously what follows is solely my opinion, but I feel like some of those criticisms are unjustified.
From your comment:
The static binary thing is a huge boon in some situations. We have a remarkably heterogenous mix of Linux versions in the field and yet the same Go binary “just works” on all of them. That’s an enormous burden off our backs.
That Go’s assembler is weird is I suppose problematic, but for the “average user” of Go that’s just an implementation detail that can be safely ignored.
From the linked rant:
Yes the file permissions APIs are weird because the models for Windows and *nix are so different. I feel like that’s a very specific issue that the rant generalizes to the whole language. In general, a large part of the rant focuses on how Go doesn’t do the right thing for Windows which may be true but it doesn’t seem to be quite that bad…I know a lot of people who have written large Go codebases that run on Windows and are very happy with it. In the rant it comes across, IMHO, as nitpicking.
Later on the rant goes on about how a Go project pulls in a bunch of dependencies and then transitively pulls in even more and so on…I feel like comparing that to Rust isn’t quite fair. I’m not super-familiar with Rust but several of the projects I’ve looked at pull in huge numbers of crates which pull in more crates and so on. It seems like it might even be worse in Rust because of the smaller standard library and, given the Actix controversy, it doesn’t seem like you can rely on third-party Rust crates being inherently safe.
Finally, though, and these are again my opinion:
Rust feels chaotic. There’s no formal specification of the language. The Rustonomicon says this:
That does not fill me with warm fuzzies.
Documentation seems lacking. There are a lot of TODOs everywhere.
There’s a new release every six weeks so I always feel like I’m playing catch-up. The “Editions” mechanism seems to help some here, but I went to try to build a Rust program (alacritty) and my Rust version was too old…and it wasn’t that old.
I don’t like the community. I know that this may come as a shock but I have gotten this “superiority complex” feeling from the Rust community. Any criticism of or concerns about the language seems to be met with “no, you’re wrong, Rust is the best! Your language sucks! Why would you use any tool other than Rust?” Sometimes it’s more polite but it’s still there. Any time someone talks about another language (Go, C++, whatever), someone has to come in and say “why don’t you rewrite it in Rust?” There have been times where I’ve seen on SO or Twitter people almost being made to feel foolish for daring to use some language other than Rust.
Again on the community, one of the core developers made a joke about C being designed by men and breaking constantly and COBOL being designed by women and just working. When a guy on Twitter said that was kinda sexist, she accused him of “mansplaining” and said he was telling her the joke was sexist rather than understanding its “obvious meaning” (which apparently wasn’t so obvious)…which I found kind of bothersome, especially since the community seemed to agree and anyone who took offense was called sexist (and trust me, I’m as leftist/feminist as they come but that doesn’t and shouldn’t mean that I hate men). This again felt like the “Rust community is superior” thing again: the Rust community was correct and those who disagreed with them were wrong, inherently so.
Sure, do that on Linux where the syscalls are the public API. Zig does that too, but IIRC it has an option to use libc on Linux, so you could make LD_PRELOAD work and everything, say when you’re building distro packages or personal binaries that you don’t want running on ancient distros.
I just really don’t like that a) there’s no choice, only direct usage of syscalls and b) this is forced on platforms that don’t consider raw syscalls as public API.
(Also, something dynamically linked to glibc will work on all glibc distros of the last N years if you use the headers from an N years old version. With a language like Rust that has its own definitions of libc symbols instead of C headers, these definitions usually are as backwards-compatible as possible already.)
Yes. Well, I’ve seen what’s inside, so it’s my mission to tell everyone how cursed it is there. Feel free to ignore me!
After all, all of computing is cursed on the inside somewhere :D But these particular experiences are what made me scream at computers the most, so I’m sharing them. Some people do care about implementation details of a thing even when they don’t modify that thing specifically.
Use nightly! :P
At least on /r/rust this kind of stuff usually downvoted into oblivion.
Twitter is a trash fire that brings the worst out in people. Heck, some people tweeting that might not have written a line of Rust ever, just shitposting memes they’ve heard somewhere.
Well that should mean hopefully having a (n extremely-online ironic millennial) sense of humor :) I wouldn’t start serious Discourse™ in defense of the joke, but I’m okay with the joke. “sexism against men” isn’t really meaningful because men are the more dominant group in current societies. (oops did I just start a Discourse?) Anyway tbh you don’t have to “hate” anyone to find this funny.
No doubt. The joke itself was funny. What bothered me was that someone responded with a polite “hey, that seems uncool” and then that person was called “sexist” and a “mansplainer”. I’m all for off-color humor but if someone you’re ostensibly trying to welcome to the community says that it bothered them, the correct response is “sorry, it was a joke but I could see how it could be taken in that manner and I apologize”…not attacking them. That this behavior was from a Rust core team member made it even worse.
But that whole thing was really just a footnote. What pushes me away more is the constant slamming of other tools and languages, which really gets grating. I don’t hang out on Reddit (if I wanted to hear about how COVID-19 is a plot by Obama to make Trump look bad or how same-sex marriage is Satanism I’d just talk to my father-in-law) but the…zealous…behavior of Rustaceans pops up just about everywhere I frequent, including my beloved lobste.rs from time to time..
Long story short (too late!), I like Rust quite a bit, but there are some negatives that I wish would be addressed.