from Hacker News

Rust Criticism from a Rustacean

by nikbackm on 6/8/23, 10:15 AM with 123 comments

by jcranmer on 6/8/23, 12:33 PM
When it comes to linking against the kernel, it is worth remembering that of the major operating systems, there is but one where the stable kernel interface is the syscalls directly--Linux. If you use Windows, the stable interface is linking against kernel32. If you use Darwin or the BSDs, your stable interface is libc (and for some of them, there's no stable ABI, only a stable C API). Note that Go has given up trying to avoid using libc on these systems, which should be a sign of how fantastical the idea of a pure, non-C system is for the foreseeable future.
by jstx1 on 6/8/23, 12:24 PM
The worst thing about Rust is easily the community - lots of drama and arguments, people building their personalities about something trivial like which programming language they use because it makes them feel superior, and many fans of Rust refusing to listen to any criticism of the language. It's a designed-by-committe language with a cult around it which might be the worst possible combo.
The second worst thing is how difficult to use it is which makes it not worth it for problems where you can use a higher-level garbage-collected language.
by insanitybit on 6/8/23, 12:32 PM
> Your systems programming language should be capable of interop with other languages but probably shouldn't require calling into C just to provide full functionality, such as interacting with the kernel.
Why tho? Like, that's how C and C++ do it, right?
> All you can do is live with it and realize that if you are that low on memory, the OS is likely going to be killing processes anyway. That said, I don't like the way Rust is inconsistent here. Rust normally enforces correctness, yet turns around and treats memory as an inexhaustible resource, ignoring or handicapping a lot of potential use cases for the language.
I think it would be more accurate to say that this is an issue of the standard library, not the language. And it's true, if you want to write certain types of software you need to throw away std.
> You can, at least in this particular case, have your cake and eat it, too.
Emphasis on "in this particular case" ? "Macros are a mistake" is a very broad, sweeping statement. I think it would be more accurate to say "Macros should not be a replacement for other forms of metaprogramming".
Having a native, supported language for compile time reflection is a powerful thing. If Rust one day gets it, that will be cool. I don't think macros are going to be a mistake on that day, they have gotten us extremely far at a very low implementation cost.]
> But at this point I just don't see anyone realistically switching to a std-2.0.
Well, to be fair, I think the vast majority of developers using Rust do not care about linking to libc or handling allocation errors and actually prefer things this way.
I agree that comptime would be cool. Personally, I don't think I'd want the other changes - I definitely prefer Rust stays on Github, for example.
by tialaramex on 6/8/23, 12:50 PM
I can't tell whether the author doesn't know, or is pretending to have no idea, that most systems do not offer a stable system call ABI.
Windows is the most obvious example. Microsoft does not officially document most of their system calls, and makes no promises that they work how you think they do/ how your unofficial documentation claims they do, or that what worked yesterday will keep working, the official documented APIs are to userspace code that you didn't write.
But this is also common on the other Unix systems besides Linux. You define the libc API as what you're promising and then you deliver or don't deliver features in your syscall ABI and the libc handles the slack.
by thadt on 6/8/23, 1:20 PM
Coming from outside, the take on macros resonates. Working with modern 'Rust' The Language is rather nice. But when one of my first main projects was to add support for a serialization format with Serde, running into macros feels like running into a wall. It's a whole next level of complexity and poor tooling support (at least at the time).
Granted, I've had similar feelings about C++'s template shenanigans, so take it with a grain of salt. Zig's comptime feels like a breath of fresh air in comparison.
by EscapeFromNY on 6/8/23, 1:49 PM
The article skips directly from #4 to #6, so I'll nominate something for #5: ranges should not be iterators. Instead they should impl IntoIterator and the iterators should be separate types. That way ranges can impl Copy without any issues. https://kaylynn.gay/blog/post/rust_ranges_and_suffering
by JodieBenitez on 6/8/23, 12:51 PM
Not a Rust user, so not some intelligent criticism... but boy how Rust source codes hurt my eyes ! Things like this:
```
    <'_>
    #[]
    stuff::thing::blah
    @gloop(gloop)
    if(fizz) |buzz|
    .Meh => |wtf|
```
I know, I know... you probably get used to it once you understand the semantics and it's subjective anyway and and and... but still, not all languages I know repel me visually.
by orf on 6/8/23, 12:08 PM
Interesting article, but:
> Then there's the issue that the crates.io registry is on GitHub, and only GitHub, and in order to publish on crates.io you have to have a GitHub account
This isn’t true. Crates.io publishes metadata to a GitHub repo, but that’s decoupled from them only supporting Github as a SSO.
by jmull on 6/8/23, 12:49 PM
> ...I'm actually looking for "the next language" to come after [Rust].
It would really be a better approach to work on getting Rust to adopt the features of Zig you're looking for. The work it goes into developing a language into a mature option is absolutely massive. Developing a full-featured language, building a (healthy) community around it, building dev mindshare/marketshare, building trust that it's sustainable, etc is a many-years effort by many talented and dedicated people. It's a huge amount of work when you could achieve the same output by adding a certain feature or two to rust.
Of course the leadership is a bit broken right now, but they may (or may not) be able to fix it.
There's also the Typescript approach. That is, extend rust with a comptime feature wrapper. Not nearly as elegant, but you don't need to work with broken rust leadership to develop it and, if it gains traction, you may then have the leverage to get it rolled in to the real thing (if you even want to at that point).
by noelwelsh on 6/8/23, 1:14 PM
> "The concept of generics is only possible with some sort of compile time reflection in any language"
This is not true.
* The standard implementation technique is to box everything (have a uniform in-memory representation for all types). Monomorphization[1], which is the compilation strategy used by Rust, C++, and I guess Zig, requires type knowledge at compile-time.
* Generic functions should not have any knowledge of the concrete types of the values they are passed, as this breaks an abstraction boundary. Theorems for free[2] is about this idea.
[1]: https://en.wikipedia.org/wiki/Monomorphization
[2]: https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14...
by einpoklum on 6/9/23, 3:25 PM
> In the meantime, you can and should use Rust. In spite of any shortcomings it's still the best language that has come so far in terms of enforcing memory access safety and overall correctness
1. I don't think programming languages can "enforce correctness". (Although I will say that my general experience is that functional languages, not Rust, tend make it more difficult to get things trivially incorrect.)
2. I'm not sure that's a good enough reason to use Rust. I mean, sure, Rust is usable, people do things with it, but - my biased experience is that at some point you just go C++ for some reason, and stay there.
by sam0x17 on 6/8/23, 1:33 PM
As an avid rust proc macro crate author, the zig macro example is quite humbling. I would welcome this kind of reflection and comptime stuff in place of (or more likely, in addition to) the existing macro systems (decl macros, and proc macros) that we have in rust.
Proc macros are particularly awkward because of the requirement that they must be defined in a separate proc macro crate. There are all sorts of things one could do if it were possible to instead make proc macros that generate proc macros _in place_ like one can with decl macros.
Then there is also the issue of macro expansion... the rustc framers openly admit that with an expression like foo!(bar!(..)) it is often preferable to have bar!(..) expand _before_ foo!(..) expands, because they have hacked in this behavior for several of the built-in macros like `concat!`, however this behavior is completely unavailable for custom macros. In fact, this one little issue is the ONLY blocker to all kinds of exotic and powerful behavior, the lack of which is holding the ecosystem back, for example the ability to eagerly expand a series of macro calls would enable the following things:
* the ability to determine the column, line, and source file in which a macro is being called, at compile-time
* the ability to determine the module path of the caller of your macro, at compile time
* the ability to determine the name of the crate in which a macro is being called, at compile-time
* the ability to implement complex compositional behavior purely in proc macros
* (very important) the ability to determine the `CARGO_MANIFEST_DIR` of the crate in which a macro is being called. Without this key ability, it is impossible to reliably determine where we are executing so we can do things like read metadata configuration values from _the caller's_ `Cargo.toml` at compile-time.
So yeah, really hoping at least eager expansion stabilizes sometime soon, but this zig stuff would be even better.
Some of my crates that would benefit from this:
* docify: https://crates.io/crates/docify
* macro_magic: https://crates.io/crates/macro_magic
* crate-settings (non-functional until this comes out): https://crates.io/crates/crate-settings
* proc-utils: https://crates.io/crates/proc-utils
by eviks on 6/9/23, 2:49 AM
Comptime on its surface is such a better alternative to macros, the fact that you don't need to learn another DSL is huge (and all the tooling works at is)
Would it be a major challenge to add it to Rust?
by anon23432343 on 6/8/23, 12:16 PM
For me it is the crates not having something like a namespace.
Something like this: @org/axum @user/axum
by titzer on 6/8/23, 12:42 PM
I think Rust should be bold and stop depending on C for anything. It's gaining enough momentum that eventually it should force kernels to be like Linux and adopt a stable ABI. In practice, most kernels have a "fairly stable" ABI just because coordinating kernel changes with userspace libc changes is tricky.
by hurril on 6/8/23, 1:14 PM
Who's going to tell him that comptime functions is what macros are?