I'd disagree with both of these. They may not be to your style but that doesn't make them rushed. Both features had long debates around their adoption.
> - Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
That is irrelevant to this project. You should read the rust kernel docs to see why.
> - Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
Also irrelevant. This may be a criticism of Rust but it in no way affects how rust may be adopted into linux.
> - Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
Linus is famous for doing fashionable things and forgoing technical decision making.
Has he changed his mind about those things? Or does he not realize they are there, and that kernel code will use them?
When I try to make a list one of the first things I find is "any programmer that would prefer the project to be in C++ over C is likely a programmer that I really would prefer to piss off, so that he doesn't come and screw up any project I'm involved with."
This is a recurring comment, but I would argue that it's not "rushed" but rather "incomplete" from supporting ecosystem (like a futures library being reactor-agnostic).
Async/Await is great for a couple of things, but not a silver bullet. So, apart from high-throughput network applications, (like web/app servers), you should stick to regular threads and channels. You can leverage Actor-based concurrency in your program that isn't async.
> - Rust is fashionable.
Because it's genuinely great ! I've been writing Rust code since 2018, and at that time "Golang" in titles would get all the hype. I get the urge to keep things as a secret underground in a true Hacker spirit. Relax : nobody is going to spoil Rust and Rust isn't going to become a new Javascript.
This is normal? not having unsafe code does not guarantee absence of bugs, but at least it isolates the problematic bits in the sections marked as unsafe.
If you need unsafe, you can always use unsafe.
Battle tested codebases like bind or openssh — and many others, independently of the language of implementation — had bugs in the past. It always helps to have extra assurances. Using safe/Unsafe is one more tool to have assurances.
I am not sure the assembler thing would handle UTF-8 as well as my incredibly low effort Rust solution tho.
What I want to say with this is: There are real, tangible advantages to the language when some noob who would shoot himself into the leg three times while writing the C/C++ equivalent manages to write safe code that performs well while not investing a lot of time.
There have been several carefully planned iterations of the Rust for Linux effort. Every iteration has addressed some feedback from senior kernel developers including Linus Torvalds. The Rust for Linux folks then worked with the Rust project to introduce these features slowly into Rust. An example of such a change is fallible memory allocation. These iteration cycles have been happening for years.
Check out the issues, especially the “wanted features and bugfixes” for each rust component (https://github.com/Rust-for-Linux/linux/issues?page=2&q=is%3...) for more details into all the work that’s happened here.
Throughout I have seen nothing but professionalism, courtesy and hard work from all parties involved here - the kernel devs, the Rust for Linux devs and the Rust project devs.
You do them all a disservice by implying that this decision was taken without “objective, technical decision making”.
> not linking with C code
I would need specific examples of C code being better than the Rust equivalent but people using the Rust equivalent anyway. I can give several counter examples. Such as libgit2, a C library with Rust bindings. It is widely used in the Rust ecosystem, including by the Rust project itself instead of the nascent gitoxide project. This shows pragmatism.
There are other examples of projects being rewritten in Rust but usually that’s ends up with the Rust version being very good. Such as when the maintainer of rsvg rewrote it in Rust. Look at the test suite results (https://github.com/RazrFalcon/resvg).
Or when someone wrote a text search tool (ripgrep) in pure Rust instead of using PCRE bindings. Look at the benchmarks (https://github.com/BurntSushi/ripgrep/blob/master/benchsuite...) - it’s faster than any competing tool on nearly all of them. If you’ve used search in VSCode, you were using ripgrep.
Or when someone wrote a pure Rust crypto library rustls when OpenSSL bindings exist. I believe the results of the security audit speak for themselves (https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). See the comments on code quality - “Cure53 was unable to uncover any application-breaking security flaws. After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality to be exceptional and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project”
These examples show that when good developers rewrite something in Rust, we all benefit from the results. If you have an example of a Rust rewrite giving worse results, and being adopted over the C bindings, that would be helpful. I can’t recall any such instance offhand.
> Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
Note, developing in Rust doesn’t suddenly make mediocre code great. I’m sure there’s mediocre code out there, just like there is in every single ecosystem. The question is, can you get stuff done while only sticking to high quality dependencies? I think you can.
> async-await and question mark.
There is a language strangeness budget each language gets to use. Use up too much of the budget and the language feels alien to newcomers.
Rust already introduces new strange things like lifetimes. New syntax like the question mark and post-fix await strain the budget further. I’ll admit, it’s hard for new people. But I also think this syntax pulls it’s weight. This is subjective and reasonable people can disagree.
That said, these syntax decisions are set in stone. I wouldn’t wait in the hope that they might change.
Just wanted to comment shortly on this:
> Could you give examples? From what I’ve seen Rust library authors take care to only pull in what’s necessary. I’d be interested to see these libraries that pull in “unrelated” dependencies.
I would hate to call out specific authors and crates. I would rather see a general awareness and discussion around the issue. Your comment is reassuring though.
Yeah I feel you. No need to call anyone out when they're just putting out their work for free for us to use.
That said, I think generally the code that I've seen is good quality. Everyone uses rustfmt, everyone tries to address clippy lints. I've seen PRs in popular libraries dropping optional libraries to get slimmer. Rust libraries aren't perfect, but they're pretty good.
For Scala devs this is the sane way :) (Or for anyone who likes RPN ^^) [Or for anyone who simply encountered a bit too many "(await (await x.y).z).w" expressions in other languages.]
However it represents something that I don't like, which is trading language surface complexity and readability for programmer convenience. It is not something that gives you more power, just something that makes code a bit easier to write. Also there was seemingly not that much push-back against the feature which makes me a bit uneasy. Not sure why that is to be honest.
I don't want to start a discussion about the question mark operator specifically. That's not important to me. What I like to gauge is the general culture around the language itself and the community around it. Half devil's advocate, half uncertainty driven.
I would say the question mark improves readability, compared to having to check/return error codes by hand after every function call.
To your more general point, the language is pretty much established and syntax features are added very rarely. I think one more feature, let guards, is coming down the pipe soon, but other than that I wouldn't be surprised if the surface syntax never changes again.
Which is one of my complaints about Go.
result, err = doSomething();
if err != nil {
...
}
result, err = doSomething2();
if err != nil {
...
}In this case it's a welcomed convenience. Have you used `thiserror` and `anyhow` crates ? They may alter your judgement on that point.
Who needs a for loop when you have while?
(Although, in Rust, `if` is also actually just sugar over `match`, so, uh...)
> it means something more specific and restricted than a general while
Sure, but that's still sugar. That's what sugar is.
Want to know something really crazy? In Rust, the `if` keyword is also just syntactic sugar over `match`. Still finding bits of grey matter on the walls from when I learned that one.
https://users.rust-lang.org/t/name-squatting-on-the-crates-i...
- parking_lot
- hashbrown
- ryu
- heck
The longer there's a shared namespace, the stranger the names get as the "good" names are already in use.
The contrary case gets confusing fast. "Oh Known Algorithm doesn't work" "Huh, I read a paper which proved it works" "No, I mean, Known Algorithm, not known algorithm". "What?" "The implementation by Popular Author. It's broken for the case we care about". "Can't they fix it?" "They say that although their implementation is called Known Algorithm it's just better that it not fix this because now Known Algorithm is different from the known algorithm". What?
Knowing there's a problem, or a different performance trade off, or a lack of maintenance for Haphazard (Jon Gjengset's Hazard Pointers implementation) is very different from having a problem with Hazard Pointers the idea.
The culture of exploding dependency trees is a recipe for disaster, especially when combined with the prevailing attitude of "use the latest version or bust".
Still, it makes dev a lot easier.
For example this comment https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic.
---
I want to provoke a little bit, but I'm genuinely curious about the following:
I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean:
- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?