> But there it went, the book talked about being Rustaceans (I really hated the term), in love with diversity,
This is pure projection. Heres the part that talks about “Rustaceans”:
> If that’s all correct and Rust still isn’t working, there are a number of places you can get help. Find out how to get in touch with other Rustaceans (a silly nickname we call ourselves) on the community page.
The word “diversity” does not appear in the Rust book.
> in all honesty, I don’t really care enough about Rust to actually check this in detail,
This is really all you need to know about this post.
The package he refers to exploits an obscure compiler bug, for giggles. There’s never been an observed instance of this bug impacting anyone in the wild.
There are good criticisms of Rust and the Rust Project, but this isn’t one of them.
> and started writing more code. The code did not compile. I was shocked. It’s quite an amazing feat, that, to have a recommended learning material that can make your very first program not compile.
Yah I had similar problems and `cargo` didn't just work for me. I've had a tough time getting rust going.
I just don't see the appeal. Memory safe sure, but I rather draw on the wealth of C/C++ knowledge if I am going to be writing code where Rust is a good fit.
> The problem was, of course, the fact that I didn’t copy-paste right the setup sequence
Sounds like the author did not specify the correct version of a dependency. It should not be surprising to find an incompatible API if using a (presumably) different major version number of a dependency, right?
I would say that failing to compile seems like a best-case scenario here. Serious question -- what would have been a better result in this situation?
Yes, the situation that happened here is that the rand package would have made a breaking change.
I haven’t heard of that being the case. The book’s code is tested in CI. I’m not saying it’s impossible, but I am saying it’s surprising. It’s certainly a bad experience, though, while the author is wrong about many things, he’s right about that.
I wonder if it could be a new manifestation of the long living problem of older resources appearing linked from random blogs or surfaced in web searches. I haven't seen that problem in a while, but could be one explanation for that.
Possibly, yeah. I haven't heard of that in a very long time either, but even then, if they were following the same code as on that resource, in theory it should have worked?
The current version of the book uses
[dependencies]
rand = "0.8.5"
1.31.0 (the oldest I could find with the same URL, I don't remember when exactly the book shipped so maybe it's slightly off but whatever) uses
[dependencies]
rand = "0.3.14"
So yeah that's a lot of differences. But if they used the same code as the book, then it should have worked. So it's possible that:
1. they got an old resource but then used a newer version of rand, maybe by using `cargo add` instead?
2. rand had a breaking change somewhere along the way there, and they got unlucky
> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.
Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.
Ahhh nice catch. Yeah, I think that might help, but also, on some level, if people choose to not follow instructions, additional instructions don’t tend to help. Doesn’t mean it’s not worth trying in some circumstances, of course…
I kind of have grown to like Rust, not for the language itself (I mean, I've got Common Lisp, so using another language is like chopping down a tree by biting off chunks with my teeth instead of using a chainsaw), but because various tools made with it, like Ripgrep, are very pleasant to use.
It's a shame, though, that people who want to 'rewrite it in Rust' always talk about rewriting things written in C or C++, when I really want them to rewrite stuff written in languages like Python or Ruby. Imagine if emerge was rewritten from Python to Rust, you could probably install Gentoo in 5 minutes, rather than the weekend it takes now. I wouldn't be surprised if rewriting all Python code in your average GNU/Linux system to Rust would make your computer run between 10^6 and 10^9 times faster.
Interesting -- I usually wish people would RiiR because of running into segfaults that I presume would be impossible in (safe) rust, or because installing the (mostly) static binaries is often much easier than wrangling (non-wheel) Python dependencies.
I have found disappointing performance gains rewriting my small Python projects in Rust as most time is spent in IO and many / most CPU-intensive tasks in Python are done in C or C extensions that release the GIL and seem just as fast as Rust would be.
No doubt the improved responsiveness / startup time for rust CLI apps is much appreciated, and it is trivial to intentionally write a very poorly performing CPU-intensive task in Python.
I dislike Rust, too. Not really for technical reasons, but just because I find it a very unpleasant language to program in. That's not a dealbreaker -- I regularly use several languages that I dislike using. But this fact:
> There was not a space for discussion with the Rustaceans - despite the inclusion discourse on the book on Rust, the community around the language felt awkwardly aggressive and exclusivistic.
ended up actually being a dealbreaker for me. The community around Rust is even more unpleasant than the language itself. It's hard to interact with a subculture that is constantly shitting on everyone else. In the end, it's why I've decided not to continue to pursue programming in Rust at all.
Agreed. The community can be very welcoming, which I sincerely appreciate, but seems like it could be prone to issues similar to the recent Hyprland dev's situation. The loudly broadcasted politically-relevant values mostly align with my own, but to me feel uncomfortably out of place at times.
I love a good rant, it's like watching a well-choreographed fight scene where you get multiple short cycles of tense setup and visceral payoff, building to a final climax that resolves the specific fight decisively whether or not it made any larger difference.
When a rant has almost exclusively ineffective, ignorant, and frankly bad-faith arguments, it's like one of those joke fights where a tiny character is limply slapping a tank that doesn't sell any impact. Those "fight" scenes don't last more than a few seconds because nothing interesting can come from that dynamic and everyone's time is better spent on something else.
This rant was far too long to get away with how thin its material is. I encourage people who want to criticize Rust to at least learn more about it so they can actually target relatable weaknesses for a meaningful payoff.
So is the problem with strings that Rust internally uses null-terminated (and if so, is there some way to make that safe), or that the OS inevitably uses null-terminated so you have to handle that at the edges? Because the latter is... kind of inevitable, unless you want to completely throw everything out and start over.
Rust’s native strings are not null terminated, though there are alternative string types (CString, CStr) that are. If you want to call a function that requires a zero terminated string, you’ll have to convert if you don’t have one already.
And yep, the latter is true. Just how it is. It’s unfortunate, but it’s also inevitable.
Different flavors for different use-cases. There was even $-terminated ones prevalent on DOS which got it from CP/M which got it from DEC OS/8.
Pascal-style strings (length + data or length + pointer to data) have the nice properties of O(1) size inquiry, simpler bounds checking, and easier to represent strings that contain embedded NULs. A downside is though you have to pick an unsigned integer width of power of 2, usually 0 to 3. Another upside is (length + pointer to data) immutable substrings (with longer lifetimes that the parent string) are very cheap because they just point to wherever in the start and specify how much of the parent string with the length. There was a language IIRC that implemented a more complicated Pascal-style strings perhaps for COW or reference counting of the underlying allocation.
This was a really weird complaint. I'm actually curious what language the author considered superior in this regard. Almost every language has agreed that string slicing is important enough that it's worth the slight impedance mismatch with legacy APIs.
Given the system APIs (heck, ABIs) will remain, the options are to {expose|hide} this detail {safely|unsafely}. Out of these, Rust seems to have made a fair choice: most APIs hide it safely, but you also get everything you need to engage with this detail when you must, safely if possible and well-contained otherwise.
Even C++ eventually got std::string_view, it just got it with temporal unsafety and no type-level way to prevent you from using a non-terminated string slice to call an API expecting termination.
This was a problem even when it was Google's internal StringPiece and you were expected to take the subtle hint that StringPiece::data() didn't imply termination the same way that string::c_str() did. The many bugs that followed proved this was not a sufficient hint, reminding us yet again why comments are no substitute for type systems, and thus why Rust's extra guard rails around this problem are justified for the majority of cases.
The author here. The point there is not a critique of Rust. I'll offer a bit of context - I started my „from scratch” utility library with a std::string-like type that operates on reference counted buffers. In the end, any operations I try to do I have to put the sliced string in a zero-terminated string because that's how one interacts with the operating system and with other libraries as well. Which is a bit dumb, unfortunately.
A lot of C (and C++) memory-related issues are caused by this assumption that by just passing a `char *` one sends a string out into the world. A point that I made on other occasions in other contexts is that in the end POSIX makes us do this, and perhaps it's time to rewrite from the bottoms up.
That aside, the issue of safety of Rust doesn't change: just because one has the `unsafe` keyword doesn't mean that someone will not use it badly. Maybe the reader of this will not use unsafe unwisely, they will eventually call unsafe-by-design APIs. At their layer they will write safe code, but below them there's a rusty bucket, if one can pardon my pun.
Blaming tools is rather dumb to me. That good software has been made with languages other than Rust proves that the issue is not the tool but rather the person using the tool. Additionally, claiming that a language’s compiler automatically solves an issue is actually just shifting trust from one’s self to someone else who is magically better because reasons.
Well, just because you can use a tool doesn't mean you should. It's not always about skill but rather whether the tool is appropriate. It may be possible to clean your floor with a toothbrush but that doesn't mean it is a worthwhile tool for doing so. If you're trying to kill a fly, perhaps the best tool for the job is not a baseball bat.
Yes. It's a toolbox. And perhaps some people think different ways aligned with some tools over others. People come to tech from different backgrounds that are sometimes nontechnical, while some are highly academic and focused such as CS. Also, there are classes of tasks that some tools are better at than others.
> The code did not compile. I was shocked. It’s quite an amazing feat, that, to have a recommended learning material that can make your very first program not compile. I will not dig through my archives but I discussed this at length back then, because it was really funny. The problem was, of course, the fact that I didn’t copy-paste right the setup sequence, and instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.
Yeah I have been trying soo hard to get into rust (My current stacks are very heavily Go based so performance for services is not a big concern for me and neither is the programming model - for doing long-running orchestration kinda work Go's CSP style is a god send). Main reason for wanting to get into Rust was doing more systems level stuff - ie CUDA, Parsers, DSLs etc. And frankly even though I thought i was great at learning new languages Rust has demanded a more distraction-free learning curve. Yep memsafety is great and all but if I cannot onboard piecemeal and I have to incur a reset each time I have to come back to it (say after a weak) that is a huge deal breaker.
> But there it went, the book talked about being Rustaceans (I really hated the term), in love with diversity,
This is pure projection. Heres the part that talks about “Rustaceans”:
> If that’s all correct and Rust still isn’t working, there are a number of places you can get help. Find out how to get in touch with other Rustaceans (a silly nickname we call ourselves) on the community page.
The word “diversity” does not appear in the Rust book.
> in all honesty, I don’t really care enough about Rust to actually check this in detail,
This is really all you need to know about this post.
The package he refers to exploits an obscure compiler bug, for giggles. There’s never been an observed instance of this bug impacting anyone in the wild.
There are good criticisms of Rust and the Rust Project, but this isn’t one of them.
> and started writing more code. The code did not compile. I was shocked. It’s quite an amazing feat, that, to have a recommended learning material that can make your very first program not compile.
Yah I had similar problems and `cargo` didn't just work for me. I've had a tough time getting rust going.
I just don't see the appeal. Memory safe sure, but I rather draw on the wealth of C/C++ knowledge if I am going to be writing code where Rust is a good fit.
> The problem was, of course, the fact that I didn’t copy-paste right the setup sequence
Sounds like the author did not specify the correct version of a dependency. It should not be surprising to find an incompatible API if using a (presumably) different major version number of a dependency, right?
I would say that failing to compile seems like a best-case scenario here. Serious question -- what would have been a better result in this situation?
Yes, the situation that happened here is that the rand package would have made a breaking change.
I haven’t heard of that being the case. The book’s code is tested in CI. I’m not saying it’s impossible, but I am saying it’s surprising. It’s certainly a bad experience, though, while the author is wrong about many things, he’s right about that.
I wonder if it could be a new manifestation of the long living problem of older resources appearing linked from random blogs or surfaced in web searches. I haven't seen that problem in a while, but could be one explanation for that.
Possibly, yeah. I haven't heard of that in a very long time either, but even then, if they were following the same code as on that resource, in theory it should have worked?
The current version of the book uses
[dependencies] rand = "0.8.5"
1.31.0 (the oldest I could find with the same URL, I don't remember when exactly the book shipped so maybe it's slightly off but whatever) uses
[dependencies]
rand = "0.3.14"
So yeah that's a lot of differences. But if they used the same code as the book, then it should have worked. So it's possible that:
1. they got an old resource but then used a newer version of rand, maybe by using `cargo add` instead?
2. rand had a breaking change somewhere along the way there, and they got unlucky
Guess we'll never know...
> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.
Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.
Ahhh nice catch. Yeah, I think that might help, but also, on some level, if people choose to not follow instructions, additional instructions don’t tend to help. Doesn’t mean it’s not worth trying in some circumstances, of course…
I kind of have grown to like Rust, not for the language itself (I mean, I've got Common Lisp, so using another language is like chopping down a tree by biting off chunks with my teeth instead of using a chainsaw), but because various tools made with it, like Ripgrep, are very pleasant to use.
It's a shame, though, that people who want to 'rewrite it in Rust' always talk about rewriting things written in C or C++, when I really want them to rewrite stuff written in languages like Python or Ruby. Imagine if emerge was rewritten from Python to Rust, you could probably install Gentoo in 5 minutes, rather than the weekend it takes now. I wouldn't be surprised if rewriting all Python code in your average GNU/Linux system to Rust would make your computer run between 10^6 and 10^9 times faster.
Interesting -- I usually wish people would RiiR because of running into segfaults that I presume would be impossible in (safe) rust, or because installing the (mostly) static binaries is often much easier than wrangling (non-wheel) Python dependencies.
I have found disappointing performance gains rewriting my small Python projects in Rust as most time is spent in IO and many / most CPU-intensive tasks in Python are done in C or C extensions that release the GIL and seem just as fast as Rust would be.
No doubt the improved responsiveness / startup time for rust CLI apps is much appreciated, and it is trivial to intentionally write a very poorly performing CPU-intensive task in Python.
I dislike Rust, too. Not really for technical reasons, but just because I find it a very unpleasant language to program in. That's not a dealbreaker -- I regularly use several languages that I dislike using. But this fact:
> There was not a space for discussion with the Rustaceans - despite the inclusion discourse on the book on Rust, the community around the language felt awkwardly aggressive and exclusivistic.
ended up actually being a dealbreaker for me. The community around Rust is even more unpleasant than the language itself. It's hard to interact with a subculture that is constantly shitting on everyone else. In the end, it's why I've decided not to continue to pursue programming in Rust at all.
Agreed. The community can be very welcoming, which I sincerely appreciate, but seems like it could be prone to issues similar to the recent Hyprland dev's situation. The loudly broadcasted politically-relevant values mostly align with my own, but to me feel uncomfortably out of place at times.
I wonder how to name this pattern, feeling like respecting principles but failing to reckon you throw them away on touchy subjects.
I love a good rant, it's like watching a well-choreographed fight scene where you get multiple short cycles of tense setup and visceral payoff, building to a final climax that resolves the specific fight decisively whether or not it made any larger difference.
When a rant has almost exclusively ineffective, ignorant, and frankly bad-faith arguments, it's like one of those joke fights where a tiny character is limply slapping a tank that doesn't sell any impact. Those "fight" scenes don't last more than a few seconds because nothing interesting can come from that dynamic and everyone's time is better spent on something else.
This rant was far too long to get away with how thin its material is. I encourage people who want to criticize Rust to at least learn more about it so they can actually target relatable weaknesses for a meaningful payoff.
So is the problem with strings that Rust internally uses null-terminated (and if so, is there some way to make that safe), or that the OS inevitably uses null-terminated so you have to handle that at the edges? Because the latter is... kind of inevitable, unless you want to completely throw everything out and start over.
Rust’s native strings are not null terminated, though there are alternative string types (CString, CStr) that are. If you want to call a function that requires a zero terminated string, you’ll have to convert if you don’t have one already.
And yep, the latter is true. Just how it is. It’s unfortunate, but it’s also inevitable.
Different flavors for different use-cases. There was even $-terminated ones prevalent on DOS which got it from CP/M which got it from DEC OS/8.
Pascal-style strings (length + data or length + pointer to data) have the nice properties of O(1) size inquiry, simpler bounds checking, and easier to represent strings that contain embedded NULs. A downside is though you have to pick an unsigned integer width of power of 2, usually 0 to 3. Another upside is (length + pointer to data) immutable substrings (with longer lifetimes that the parent string) are very cheap because they just point to wherever in the start and specify how much of the parent string with the length. There was a language IIRC that implemented a more complicated Pascal-style strings perhaps for COW or reference counting of the underlying allocation.
This was a really weird complaint. I'm actually curious what language the author considered superior in this regard. Almost every language has agreed that string slicing is important enough that it's worth the slight impedance mismatch with legacy APIs.
Given the system APIs (heck, ABIs) will remain, the options are to {expose|hide} this detail {safely|unsafely}. Out of these, Rust seems to have made a fair choice: most APIs hide it safely, but you also get everything you need to engage with this detail when you must, safely if possible and well-contained otherwise.
How many languages engage with this concern so completely that they have compiler support for null-terminated C string literals? https://doc.rust-lang.org/edition-guide/rust-2021/c-string-l...
Even C++ eventually got std::string_view, it just got it with temporal unsafety and no type-level way to prevent you from using a non-terminated string slice to call an API expecting termination.
This was a problem even when it was Google's internal StringPiece and you were expected to take the subtle hint that StringPiece::data() didn't imply termination the same way that string::c_str() did. The many bugs that followed proved this was not a sufficient hint, reminding us yet again why comments are no substitute for type systems, and thus why Rust's extra guard rails around this problem are justified for the majority of cases.
The author here. The point there is not a critique of Rust. I'll offer a bit of context - I started my „from scratch” utility library with a std::string-like type that operates on reference counted buffers. In the end, any operations I try to do I have to put the sliced string in a zero-terminated string because that's how one interacts with the operating system and with other libraries as well. Which is a bit dumb, unfortunately.
A lot of C (and C++) memory-related issues are caused by this assumption that by just passing a `char *` one sends a string out into the world. A point that I made on other occasions in other contexts is that in the end POSIX makes us do this, and perhaps it's time to rewrite from the bottoms up.
That aside, the issue of safety of Rust doesn't change: just because one has the `unsafe` keyword doesn't mean that someone will not use it badly. Maybe the reader of this will not use unsafe unwisely, they will eventually call unsafe-by-design APIs. At their layer they will write safe code, but below them there's a rusty bucket, if one can pardon my pun.
Blaming tools is rather dumb to me. That good software has been made with languages other than Rust proves that the issue is not the tool but rather the person using the tool. Additionally, claiming that a language’s compiler automatically solves an issue is actually just shifting trust from one’s self to someone else who is magically better because reasons.
Well, just because you can use a tool doesn't mean you should. It's not always about skill but rather whether the tool is appropriate. It may be possible to clean your floor with a toothbrush but that doesn't mean it is a worthwhile tool for doing so. If you're trying to kill a fly, perhaps the best tool for the job is not a baseball bat.
Yes. It's a toolbox. And perhaps some people think different ways aligned with some tools over others. People come to tech from different backgrounds that are sometimes nontechnical, while some are highly academic and focused such as CS. Also, there are classes of tasks that some tools are better at than others.
> The code did not compile. I was shocked. It’s quite an amazing feat, that, to have a recommended learning material that can make your very first program not compile. I will not dig through my archives but I discussed this at length back then, because it was really funny. The problem was, of course, the fact that I didn’t copy-paste right the setup sequence, and instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.
Is this blog satire?
Is this question?
Skill issue
Yeah I have been trying soo hard to get into rust (My current stacks are very heavily Go based so performance for services is not a big concern for me and neither is the programming model - for doing long-running orchestration kinda work Go's CSP style is a god send). Main reason for wanting to get into Rust was doing more systems level stuff - ie CUDA, Parsers, DSLs etc. And frankly even though I thought i was great at learning new languages Rust has demanded a more distraction-free learning curve. Yep memsafety is great and all but if I cannot onboard piecemeal and I have to incur a reset each time I have to come back to it (say after a weak) that is a huge deal breaker.