While the Rust zealots can get pretty irritating (I’m always disappointed when I want to talk about a project in another language and it seems inevitable that someone will eventually shift the conversation to how said project should be written in Rust), I can’t deny that Rust has seemingly all the momentum behind it from a systems language perspective.
I do like Rust, truly, but I prefer smaller languages and also I don’t have an opportunity to use it at work so anything I do with it would be in my spare time so finding motivation is hard (because for fun I want to work with smaller or more esoteric languages).
All that being said I should probably rewrite one or two of my things in Rust just to keep my Rust skills from completely atrophying. I have a feeling being proficient in Rust will be beneficial to my career in the medium to long term.
Sorry, you’ll probably be hearing about Rewriting In Rust a lot.
There are many languages better than C or C++, and Zig is one of them, but it’s hard to justify a rewrite of an important old piece of code only because there’s a newer and nicer language. That sounds frivolous and unwise. Rust has this lure of a memory-safety guarantee, and that can be used as a quite compelling justification.
Well, kind of. It’s memory safe unless you use unsafe. And that’s fine, except that the standard library uses unsafe and there are common idioms that let safe code at some distance from unsafe code accidentally violate memory safety. The last paper I saw doing this found around 300 memory safety vulnerabilities in cargo packages from a single shape. And that’s in an ecosystem that, while it generates a lot of press, still has fewer lines of code in it (counting all open source Rust that OpenHub could find) than Chromium.
That caveat is well-documented, but in practice it works well, because there’s less of the risky code, and it’s clearly marked and can be isolated.
I assume you’re referring to the Rudra paper. Please note there’s a difference between soundness hole and a vulnerability. Unsound interfaces create a loophole in the guarantee, but don’t immediately create a vulnerability. The types of holes that Rudra found were unhandled cases when custom operator overloads are implemented incorrectly or panic, which you would try hard to avoid in any case.
This is how I feel as well. Zig seems fun, but I haven’t found a clear reason to use it over Rust. I also happen to find Rust fun, though, so I won’t pretend i’m trying very hard to find an alternative.
I do like Rust, truly, but I prefer smaller languages and also I don’t have an opportunity to use it at work so anything I do with it would be in my spare time so finding motivation is hard (because for fun I want to work with smaller or more esoteric languages).
I think people should design programming languages that make similar (or better!) memory safety without garbage collection guarantees to Rust, that explore different parts of the design space. If people can pull that off while still having a language that is smaller than Rust, even better, although I think this will be difficult, and that most of the size of Rust really is essential complexity.
The problem with language design is that a language can come up with an entirely novel and wildly better solution to memory management than Rust and still fail to get market share because it flubs the tooling or the standard library design or some other aspect (I would honestly probably use C and C++ if they had something like Cargo that was ubiquitous). Rust is one of very few languages that does very well in most respects while also innovating on language features.
I would honestly probably use C and C++ if they had something like Cargo that was ubiquitous.
Something like Cargo cannot become ubiquitous for C/C++ because it lacks a lot of functionality, such as a proper build system, that many projects written in these languages need. The fact that some of the more complex projects (Linux, Firefox) that use Rust don’t use Cargo is an indication of this.
You could try to make a build toolchain for C/C++ that approximates Cargo’s usability while providing more depth, functionality-wise (we are trying to do this in build2). But it still unlikely to become ubiquitous because hoping to switch a build toolchain for something like the Linux kernel is most likely beyond realistic (though Linus’ reply to such a proposition would make for an entertaining read indeed).
Something like Cargo cannot become ubiquitous for C/C++ because it lacks a lot of functionality, such as a proper build system, that many projects written in these languages need.
I don’t need it to be literally ubiquitous, but the standard way to build libraries and binaries by default. The overwhelming majority of projects in the C/C++ space don’t actually need a fully fledged build system; although many do weird things in their build system just because they can. There are still many exceptions to that rule, and that is okay (I wouldn’t expect Linux to adopt a build system like Cargo in the same way that Kubernetes isn’t built with go build). I agree though that no build tool is likely to become the standard for C/C++.
I mean, the standard way to build libraries and binaries is ./configure then make. I don’t think build system is a problem, packaging system is. Package repository and way to declare dependencies and automatically and recursively downloading dependencies over the network.
Because configure and make aren’t aware of dependencies they will often fail to find the dependency files, especially if you have multiple versions of a dependency on your system (different projects with different dependency requirements). It’s a pretty frustrating experience.
The overwhelming majority of projects in the C/C++ space don’t actually need a fully fledged build system;
Not my experience at all. After being involved in packaging over 300 C/C++ projects (mostly libraries) for build2, I can tell you very few of them could be built as just “a bunch of source files”. Hell, in these ~300 packages there are probably 30 different source code layouts.
I think the argument is that so many project layouts don’t have to exist; these projects could have been adapted to a smaller common set of layouts. Every C project does things its own way, because it can. But if there was a hard rule the files need to be in src/*.c, they’d figure out how to make that work.
Sure, say 90% of them could (they wouldn’t like it, but they could). But the remaining 10%, the likes of the Linux kernel, GCC, Qt, etc., would be just too complex for something so simplistic. And source code layout is only one facet: another 10% need to compile this specific translation unit with slightly different option (for example, an extra macro define). And another 10% use config.h.in. And so on and so forth. The next thing you see is 90% of them need a real build system.
I don’t doubt that they can’t be built as just a bunch of source files, but that they could be. If you don’t have a standard tool like Cargo to guide people towards robust, simple solutions then they make their own bespoke build systems overly complex. That was my experience a decade ago as a C/C++ developer anyway.
I really like the idea of exploring different parts of the space. One that I think could be interesting is a dynamic, boxed language that leans heavily into parallelism. Basically, Erlang without the separate heaps. Why a dynamic language? Because you could focus really hard on just introducing the notation for lifetimes without having to think about memory layout, types, or generics. It would leave performance on the table, but maybe it would make parallelism trivial and very safe.
Overall, I like thinking of languages as having a series of different switches and I think we should try all the combinations.
This pretty much nailed my situation. I felt it was just me. Although, my Rust skills are not that great, mainly because I am not getting opportunity/time outside work to use it. Career wise I am seeing benefit of learning go for near/short term. ( I don’t use go for work so there is that too )
While the Rust zealots can get pretty irritating (I’m always disappointed when I want to talk about a project in another language and it seems inevitable that someone will eventually shift the conversation to how said project should be written in Rust), I can’t deny that Rust has seemingly all the momentum behind it from a systems language perspective.
I do like Rust, truly, but I prefer smaller languages and also I don’t have an opportunity to use it at work so anything I do with it would be in my spare time so finding motivation is hard (because for fun I want to work with smaller or more esoteric languages).
All that being said I should probably rewrite one or two of my things in Rust just to keep my Rust skills from completely atrophying. I have a feeling being proficient in Rust will be beneficial to my career in the medium to long term.
Sorry, you’ll probably be hearing about Rewriting In Rust a lot.
There are many languages better than C or C++, and Zig is one of them, but it’s hard to justify a rewrite of an important old piece of code only because there’s a newer and nicer language. That sounds frivolous and unwise. Rust has this lure of a memory-safety guarantee, and that can be used as a quite compelling justification.
Well, kind of. It’s memory safe unless you use unsafe. And that’s fine, except that the standard library uses unsafe and there are common idioms that let safe code at some distance from unsafe code accidentally violate memory safety. The last paper I saw doing this found around 300 memory safety vulnerabilities in cargo packages from a single shape. And that’s in an ecosystem that, while it generates a lot of press, still has fewer lines of code in it (counting all open source Rust that OpenHub could find) than Chromium.
That caveat is well-documented, but in practice it works well, because there’s less of the risky code, and it’s clearly marked and can be isolated.
I assume you’re referring to the Rudra paper. Please note there’s a difference between soundness hole and a vulnerability. Unsound interfaces create a loophole in the guarantee, but don’t immediately create a vulnerability. The types of holes that Rudra found were unhandled cases when custom operator overloads are implemented incorrectly or panic, which you would try hard to avoid in any case.
This is how I feel as well. Zig seems fun, but I haven’t found a clear reason to use it over Rust. I also happen to find Rust fun, though, so I won’t pretend i’m trying very hard to find an alternative.
I think people should design programming languages that make similar (or better!) memory safety without garbage collection guarantees to Rust, that explore different parts of the design space. If people can pull that off while still having a language that is smaller than Rust, even better, although I think this will be difficult, and that most of the size of Rust really is essential complexity.
The problem with language design is that a language can come up with an entirely novel and wildly better solution to memory management than Rust and still fail to get market share because it flubs the tooling or the standard library design or some other aspect (I would honestly probably use C and C++ if they had something like Cargo that was ubiquitous). Rust is one of very few languages that does very well in most respects while also innovating on language features.
Something like Cargo cannot become ubiquitous for C/C++ because it lacks a lot of functionality, such as a proper build system, that many projects written in these languages need. The fact that some of the more complex projects (Linux, Firefox) that use Rust don’t use Cargo is an indication of this.
You could try to make a build toolchain for C/C++ that approximates Cargo’s usability while providing more depth, functionality-wise (we are trying to do this in
build2). But it still unlikely to become ubiquitous because hoping to switch a build toolchain for something like the Linux kernel is most likely beyond realistic (though Linus’ reply to such a proposition would make for an entertaining read indeed).I don’t need it to be literally ubiquitous, but the standard way to build libraries and binaries by default. The overwhelming majority of projects in the C/C++ space don’t actually need a fully fledged build system; although many do weird things in their build system just because they can. There are still many exceptions to that rule, and that is okay (I wouldn’t expect Linux to adopt a build system like Cargo in the same way that Kubernetes isn’t built with
go build). I agree though that no build tool is likely to become the standard for C/C++.I mean, the standard way to build libraries and binaries is ./configure then make. I don’t think build system is a problem, packaging system is. Package repository and way to declare dependencies and automatically and recursively downloading dependencies over the network.
Because configure and make aren’t aware of dependencies they will often fail to find the dependency files, especially if you have multiple versions of a dependency on your system (different projects with different dependency requirements). It’s a pretty frustrating experience.
Not my experience at all. After being involved in packaging over 300 C/C++ projects (mostly libraries) for
build2, I can tell you very few of them could be built as just “a bunch of source files”. Hell, in these ~300 packages there are probably 30 different source code layouts.I think the argument is that so many project layouts don’t have to exist; these projects could have been adapted to a smaller common set of layouts. Every C project does things its own way, because it can. But if there was a hard rule the files need to be in
src/*.c, they’d figure out how to make that work.Sure, say 90% of them could (they wouldn’t like it, but they could). But the remaining 10%, the likes of the Linux kernel, GCC, Qt, etc., would be just too complex for something so simplistic. And source code layout is only one facet: another 10% need to compile this specific translation unit with slightly different option (for example, an extra macro define). And another 10% use
config.h.in. And so on and so forth. The next thing you see is 90% of them need a real build system.I don’t doubt that they can’t be built as just a bunch of source files, but that they could be. If you don’t have a standard tool like Cargo to guide people towards robust, simple solutions then they make their own bespoke build systems overly complex. That was my experience a decade ago as a C/C++ developer anyway.
I really like the idea of exploring different parts of the space. One that I think could be interesting is a dynamic, boxed language that leans heavily into parallelism. Basically, Erlang without the separate heaps. Why a dynamic language? Because you could focus really hard on just introducing the notation for lifetimes without having to think about memory layout, types, or generics. It would leave performance on the table, but maybe it would make parallelism trivial and very safe.
Overall, I like thinking of languages as having a series of different switches and I think we should try all the combinations.
I tried rust recently and rage quit at how hard it was to modify code using callbacks to bubble up an error.
Zig is much more friendly.
I do like Zig quite a bit.
This pretty much nailed my situation. I felt it was just me. Although, my Rust skills are not that great, mainly because I am not getting opportunity/time outside work to use it. Career wise I am seeing benefit of learning go for near/short term. ( I don’t use go for work so there is that too )
Do we know what they’re using it for?
Fonts, regions, and an unspecified syscall.
You can follow the first link to get to a presentation of David Weston on the subject.