13 ms·

Rust Criticism from a Rustacean

55 points by nikbackm 3y ago

orf 3y ago
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.
- capableweb 3y ago
  The point is that if you want to publish a crate to crates.io, you need a GitHub account, which is true and verifiable in ten seconds. Not sure why it's important how it's required, the end result is the same.
  - einpoklum 3y ago
    Wait, seriously? But GitHub is a censored platform, it's not universally accessible. Microsoft is blocking people from US-sanctioned world states: https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/ https://techcrunch.com/2019/07/29/github-ban-sanctioned-coun... how can Rust conduct any official business on such a platform?
    - insanitybit 3y ago
      Easily and with great success?
    - Strom 3y ago
      Rather successfully apparently. Maybe you’re overestimating the number of would-be contributors from sanctioned countries who aren’t using workarounds?
      - einpoklum 3y ago
        You realize this is a self-fulfilling prophecy. If people from certain countries are excluded - formally, technically or culturally - naturally they would not tend to even try to contribute.
    - Joker_vD 3y ago
      Rust Foundation is a US-based organization so it has to follow its declared goals and principles only to the extent that the US laws allow it, you know?
      - einpoklum 3y ago
        1. Don't know that there's anything preventing US-based organizations to use non-US-based computing platforms which are universally accessible. And if things are indeed that bad - that means Rust as a project has decided to define itself as a partisan US endeavor. USers might hear this and just shrug carelessly, but imagine how you would feel if the Rust foundation's websites would be inaccessible for people in, oh, say, New Jersey. Nobody from Jersey could publish rust crates. That's preposterous. 2. The UN's headquarters are in the US, the same principles should apply, although I realize legally that might not be the case. Then again - maybe projects like a programming language should actually be constituted via the UN, or ISO, to have the appropriate non-partisan legal basis for operations.
        Joker_vD 3y ago
        > there's anything preventing US-based organizations to use non-US-based computing platforms which are universally accessible Trade/technology embargoes and sanction regimes are just such things. For an example how arbitrary those can be, the US sanctioned a German port for participating in NordStream 2 construction — and that project had zilch to do with the US, even its financing was done in Euro, not USD. > The UN's headquarters are in the US, And the US somewhat regularly declines its visas to the UN representatives it doesn't particularly like. So? In any case, an international organization (and its members) is not automatically outside of the jurisdictions of the country (countries) it's physically in; if such a need arises, the governments have to pass specific laws regarding those specific organizations and its members, granting some sort of immunity or another. Or they just don't, and the organization simple has to function as a non-profit multinational.
    - eminence32 3y ago
      I am surprised that you are surprised that Rust is relying on GitHub. Hundreds (thousands probably?) of companies use GitHub to host their code and daily business operations, including Rust
  - orf 3y ago
    You’re commenting on a site that is fairly well known for being pedantic. > Then there's the issue that the crates.io registry is on GitHub, and only GitHub There are a number of issues with this. The public crates registry is available in sanctioned countries, and it’s not even used by default anymore. This is independent of crates.io only supporting GitHub as a sign-up option. People from sanctioned countries can also sign up for GitHub accounts, but cannot access private ones or paid membership features. The author conflates these two issues in a way that confuses the point they are trying to make, which has nothing to do with the crates.io registry being on GitHub or access from sanctioned countries.
anon23432343 3y ago
For me it is the crates not having something like a namespace. Something like this: @org/axum @user/axum
- MrBuddyCasino 3y ago
  "No this is a feature you see, that way people will have to come up with creative names" (that have nothing to do with its task and that nobody can remember, oc) was the standard reply I got when I said as much. They should have just copied the Maven Central mode of operation, it has matured over many years and works well, without any drama such as NPM is infamous for.
  - Yoric 3y ago
    Not really. The Rust community is very well aware of the problem. Not sure when namespacing will become possible, but it seems pretty clear to me that it will happen eventually.
    - insanitybit 3y ago
      The problem is adding namespaces on at this point seems very hard.
    - MrBuddyCasino 3y ago
      You say this like is some difficult technical challenge to overcome, when that was a very deliberate design decision upfront.
      - Yoric 3y ago
        It was. But the problems have emerged. Now it's a liability and the community is thinking about how to improve the situation.
  - insanitybit 3y ago
    The issue is "but people will just squat namespaces". I don't agree, fwiw, but that's one of the main push backs.
jstx1 3y ago
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.
- Yoric 3y ago
  FWIW, I have seen some of this behavior from people who have just discovered Rust, but none from people who are actually established members of the Rust community. In my personal experience, the Rust community is very welcoming, extremely open to criticism and discussing tradeoffs – and yes, pretty happy of the language, just as every PL community.
  - cmrdporcupine 3y ago
    I've said it before, and I'll say it again: the problem with Rust right now is that it is in the unfortunate position of being an ascendant language for "cool kids". It has captured some portion of the attention of a younger and more trend-focused audience, and people are attaching their egos and careers to it and jostling to make themselves "known" in its community, etc. That and some of the projects and types of work adopting it; last year the "web3" and "crypto" companies began piling in, which had a markedly corrosive effect on the language and its emphasis. In general, the amount of "webscale" type work being done in Rust right now has shifted the focus in published crates, etc. from "systems" type work to a lot of the "async serving" types of stuff. For someone like myself whose interest (and day job) in Rust is in embedded, "systems" (closer to the metal, storage, virtual machine, database internals, etc), and the like, this is a bit discouraging. In general the list of speakers at RustCon (before the whole fiasco) didn't look on the whole like the list of speakers around a "systems programming language" for example (with some exceptions). As more "boring" work is done in Rust, this will hopefully shift. The trend hoppers will move on.
insanitybit 3y ago
> 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.
- Strom 3y ago
  > 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’d say it’s about the deceptive marketing. Rust is talked about as a safe systems language. I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. It doesn’t of course stop at the marketing slogan. Problems like these aren’t sufficiently promoted in the documentation either. I think that being more open about these problems would help enable a solution.
  - Ygg2 3y ago
jcranmer 3y ago
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.
- titzer 3y ago
  It's really unfortunate. I've crowed about this before. The syscall interface on Darwin is so close to being stable. Even though it's not officially supported (TM), the UNIX syscalls basically don't change. (Only one needless breaking change that I recall in the past 10 years on x86). We need to shake the C demon and the only way is to push back on kernel ABIs changing. Virgil doesn't depend on C and runs happily on Linux and Darwin. And yea, I know, MacOS breaks.
  - eptcyka 3y ago
    IOCTLs have been broken between major versions before. And by broken, a field has been added to a struct.
    - einpoklum 3y ago
      And?... If the IOCTLs are different, then you compile a different binary. What's the big deal? Rust is a compiled language after all.
  - eqvinox 3y ago
    There is no C demon. The OS ABI is (de facto — please spare the de jure nitpickery) a bunch of symbols you can call and a calling convention for them. You call into that ABI. What language is used to implement the other side of that ABI is irrelevant. The fact that this ABI is called "libc" doesn't really mean a whole lot. Neither is the fact that the same library contains a whole bunch of functions primarily useful to programs written in C.
titzer 3y ago
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.
- dralley 3y ago
  That's just not going to happen, and is not even necessarily desirable.
- yjftsjthsd-h 3y ago
  > It's gaining enough momentum that eventually it should force kernels to be like Linux and adopt a stable ABI. This both misunderstands the impediments, and wildly overestimates Rust's position. First, on some platforms like OpenBSD, it's not just a matter of stability per-se; OpenBSD implements some of their security measures in libc, and therefore intentionally forces its use. Second... how exactly is rust going to "force", say, Windows, to change how they present the userspace/OS interface? > In practice, most kernels have a "fairly stable" ABI just because coordinating kernel changes with userspace libc changes is tricky. I don't know if you're using a loose enough definition of "fairly stable" that it's meaningless, or mistaken outright, but no, at least NT can and does change its syscall interface often enough that it actually prevents people from using it in any meaningful way (read: sure, you can do it as long as you never update, but then the next time you run Windows Update it will break).
jmull 3y ago
> ...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).
- cmrdporcupine 3y ago
  > It would really be a better approach to work on getting Rust to adopt the features of Zig you're looking for. I was just pondering the other day about how nice it would be to take to get the same level of quality C/C++ integration that Zig has, but in Rust. My new job has acres and acres of C++ which isn't going to go away. Linking and wrapping against C++ is one thing; build system integration is another. Zig has some serious advantages there. That and I really want allocator_api and simd to get into stable.
  - Ygg2 3y ago
    I'm not familiar with Rust vs Zig C++ integration. What are the stumbling blocks? Lack of stable ABI in Rust?
    - cmrdporcupine 3y ago
      I don't have much Zig experience at all, but from what I've read Zig is pretty genius because in addition to being a Zig compiler -- with its own sane build system -- the same tool also acts as a C/C++ compiler. So mixing Zig and C/C++ has a lot less friction.
tialaramex 3y ago
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.
JodieBenitez 3y ago
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.
- wizzwizz4 3y ago
  Your last three examples are syntactically invalid Rust. It should be more like: <'_> #[foo] stuff::thing::blah match gloop(gloop) { x @ _ => x } if fizz { |buzz| Some(buzz) } else { |_| None } Meh => |wtf| ()
  - JodieBenitez 3y ago
    You're certainly right, I just copy/pasted stuff from the article and changed identifiers, probably adding errors in the process, but the point was never to give accurate examples, just point that even reading Rust code requires significantly more learning than other languages. YMMV of course. Thanks for correcting me. Still not a joy to read though.
    - wizzwizz4 3y ago
      It requires less learning than Haskell. A tad more than C. Less than C++.
      - maleldil 3y ago
        > Less than C++ That depends. Rust requires less learning than C++ for writing safe code. There are plenty of C++ developers that feel like they know the language but produce unsafe code. Rust won't let you do that, so these developers complain.
- hucker 3y ago
  The last three are taken from the OPs Zig example, and is not valid Rust at all.
hurril 3y ago
Who's going to tell him that comptime functions is what macros are?
- Yoric 3y ago
  They're not?
noelwelsh 3y ago
> "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 https://en.wikipedia.org/wiki/Monomorphization [2]: https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14/free.pdf https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14...
- bestouff 3y ago
  How can you call a method on a type if you don't know anything about it ? How do you even know the method exist without some dynamic casting of sorts ?
  - noelwelsh 3y ago
    It's not calling methods on a type that is the issue. It's passing parameters to a method or function when that method or function has a generic type for that parameter. In Rust this is something like fn foo<A>(a: A): A (which can only have one implementation, the identity, if you don't break the abstraction barrier provided by generic types.)
  - dangitdangitdan 3y ago
    [flagged]
  - Joker_vD 3y ago
    You pass that method along with the value, so it's the caller's responsibility. At some point along the call stack there will be a monomorphic function which has to know the actual type it's calling its polymorphic callee with.
thadt 3y ago
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.
- insanitybit 3y ago
  Adding serialization with serde is a matter of adding `#[derive(Serialize, Deserialize)]`. I guess that's magical in a way, but does that matter?
  - estebank 3y ago
    GP is talking about adding support for a specific format to Serde, something equivalent to serde_json, not serializing an ADT they have. I've also found it to be difficult.
    - insanitybit 3y ago
      Ohhhh, I see. Yes, I think comptime would be a big win there.
sam0x17 3y ago
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 https://crates.io/crates/docify * macro_magic: https://crates.io/crates/macro_magic https://crates.io/crates/macro_magic * crate-settings (non-functional until this comes out): https://crates.io/crates/crate-settings https://crates.io/crates/crate-settings * proc-utils: https://crates.io/crates/proc-utils https://crates.io/crates/proc-utils
EscapeFromNY 3y ago
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 https://kaylynn.gay/blog/post/rust_ranges_and_suffering
- Ygg2 3y ago
  It's a well known issue, but it might never be solved due to backwards compatibility. They were made non-Copy to avoid a nasty footgun, and way before IntoIterator existed.
eviks 3y ago
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?
einpoklum 3y ago
> 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.

55 points by nikbackm 3y ago

orf 3y ago

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.

capableweb 3y ago
The point is that if you want to publish a crate to crates.io, you need a GitHub account, which is true and verifiable in ten seconds. Not sure why it's important how it's required, the end result is the same.
- einpoklum 3y ago
  Wait, seriously? But GitHub is a censored platform, it's not universally accessible. Microsoft is blocking people from US-sanctioned world states: https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/ https://techcrunch.com/2019/07/29/github-ban-sanctioned-coun... how can Rust conduct any official business on such a platform?
  - insanitybit 3y ago
    Easily and with great success?
  - Strom 3y ago
    Rather successfully apparently. Maybe you’re overestimating the number of would-be contributors from sanctioned countries who aren’t using workarounds?
    - einpoklum 3y ago
      You realize this is a self-fulfilling prophecy. If people from certain countries are excluded - formally, technically or culturally - naturally they would not tend to even try to contribute.
  - Joker_vD 3y ago
    Rust Foundation is a US-based organization so it has to follow its declared goals and principles only to the extent that the US laws allow it, you know?
    - einpoklum 3y ago
      1. Don't know that there's anything preventing US-based organizations to use non-US-based computing platforms which are universally accessible. And if things are indeed that bad - that means Rust as a project has decided to define itself as a partisan US endeavor. USers might hear this and just shrug carelessly, but imagine how you would feel if the Rust foundation's websites would be inaccessible for people in, oh, say, New Jersey. Nobody from Jersey could publish rust crates. That's preposterous. 2. The UN's headquarters are in the US, the same principles should apply, although I realize legally that might not be the case. Then again - maybe projects like a programming language should actually be constituted via the UN, or ISO, to have the appropriate non-partisan legal basis for operations.
      - Joker_vD 3y ago
        > there's anything preventing US-based organizations to use non-US-based computing platforms which are universally accessible Trade/technology embargoes and sanction regimes are just such things. For an example how arbitrary those can be, the US sanctioned a German port for participating in NordStream 2 construction — and that project had zilch to do with the US, even its financing was done in Euro, not USD. > The UN's headquarters are in the US, And the US somewhat regularly declines its visas to the UN representatives it doesn't particularly like. So? In any case, an international organization (and its members) is not automatically outside of the jurisdictions of the country (countries) it's physically in; if such a need arises, the governments have to pass specific laws regarding those specific organizations and its members, granting some sort of immunity or another. Or they just don't, and the organization simple has to function as a non-profit multinational.
  - eminence32 3y ago
    I am surprised that you are surprised that Rust is relying on GitHub. Hundreds (thousands probably?) of companies use GitHub to host their code and daily business operations, including Rust
- orf 3y ago
  You’re commenting on a site that is fairly well known for being pedantic. > Then there's the issue that the crates.io registry is on GitHub, and only GitHub There are a number of issues with this. The public crates registry is available in sanctioned countries, and it’s not even used by default anymore. This is independent of crates.io only supporting GitHub as a sign-up option. People from sanctioned countries can also sign up for GitHub accounts, but cannot access private ones or paid membership features. The author conflates these two issues in a way that confuses the point they are trying to make, which has nothing to do with the crates.io registry being on GitHub or access from sanctioned countries.

anon23432343 3y ago

For me it is the crates not having something like a namespace. Something like this: @org/axum @user/axum

MrBuddyCasino 3y ago
"No this is a feature you see, that way people will have to come up with creative names" (that have nothing to do with its task and that nobody can remember, oc) was the standard reply I got when I said as much. They should have just copied the Maven Central mode of operation, it has matured over many years and works well, without any drama such as NPM is infamous for.
- Yoric 3y ago
  Not really. The Rust community is very well aware of the problem. Not sure when namespacing will become possible, but it seems pretty clear to me that it will happen eventually.
  - insanitybit 3y ago
    The problem is adding namespaces on at this point seems very hard.
  - MrBuddyCasino 3y ago
    You say this like is some difficult technical challenge to overcome, when that was a very deliberate design decision upfront.
    - Yoric 3y ago
      It was. But the problems have emerged. Now it's a liability and the community is thinking about how to improve the situation.
- insanitybit 3y ago
  The issue is "but people will just squat namespaces". I don't agree, fwiw, but that's one of the main push backs.

jstx1 3y ago

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.

Yoric 3y ago
FWIW, I have seen some of this behavior from people who have just discovered Rust, but none from people who are actually established members of the Rust community. In my personal experience, the Rust community is very welcoming, extremely open to criticism and discussing tradeoffs – and yes, pretty happy of the language, just as every PL community.
- cmrdporcupine 3y ago
  I've said it before, and I'll say it again: the problem with Rust right now is that it is in the unfortunate position of being an ascendant language for "cool kids". It has captured some portion of the attention of a younger and more trend-focused audience, and people are attaching their egos and careers to it and jostling to make themselves "known" in its community, etc. That and some of the projects and types of work adopting it; last year the "web3" and "crypto" companies began piling in, which had a markedly corrosive effect on the language and its emphasis. In general, the amount of "webscale" type work being done in Rust right now has shifted the focus in published crates, etc. from "systems" type work to a lot of the "async serving" types of stuff. For someone like myself whose interest (and day job) in Rust is in embedded, "systems" (closer to the metal, storage, virtual machine, database internals, etc), and the like, this is a bit discouraging. In general the list of speakers at RustCon (before the whole fiasco) didn't look on the whole like the list of speakers around a "systems programming language" for example (with some exceptions). As more "boring" work is done in Rust, this will hopefully shift. The trend hoppers will move on.

insanitybit 3y ago

> 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.

Strom 3y ago
> 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’d say it’s about the deceptive marketing. Rust is talked about as a safe systems language. I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. It doesn’t of course stop at the marketing slogan. Problems like these aren’t sufficiently promoted in the documentation either. I think that being more open about these problems would help enable a solution.
- Ygg2 3y ago

jcranmer 3y ago

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.

titzer 3y ago
It's really unfortunate. I've crowed about this before. The syscall interface on Darwin is so close to being stable. Even though it's not officially supported (TM), the UNIX syscalls basically don't change. (Only one needless breaking change that I recall in the past 10 years on x86). We need to shake the C demon and the only way is to push back on kernel ABIs changing. Virgil doesn't depend on C and runs happily on Linux and Darwin. And yea, I know, MacOS breaks.
- eptcyka 3y ago
  IOCTLs have been broken between major versions before. And by broken, a field has been added to a struct.
  - einpoklum 3y ago
    And?... If the IOCTLs are different, then you compile a different binary. What's the big deal? Rust is a compiled language after all.
- eqvinox 3y ago
  There is no C demon. The OS ABI is (de facto — please spare the de jure nitpickery) a bunch of symbols you can call and a calling convention for them. You call into that ABI. What language is used to implement the other side of that ABI is irrelevant. The fact that this ABI is called "libc" doesn't really mean a whole lot. Neither is the fact that the same library contains a whole bunch of functions primarily useful to programs written in C.

titzer 3y ago

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.

dralley 3y ago
That's just not going to happen, and is not even necessarily desirable.
yjftsjthsd-h 3y ago
> It's gaining enough momentum that eventually it should force kernels to be like Linux and adopt a stable ABI. This both misunderstands the impediments, and wildly overestimates Rust's position. First, on some platforms like OpenBSD, it's not just a matter of stability per-se; OpenBSD implements some of their security measures in libc, and therefore intentionally forces its use. Second... how exactly is rust going to "force", say, Windows, to change how they present the userspace/OS interface? > In practice, most kernels have a "fairly stable" ABI just because coordinating kernel changes with userspace libc changes is tricky. I don't know if you're using a loose enough definition of "fairly stable" that it's meaningless, or mistaken outright, but no, at least NT can and does change its syscall interface often enough that it actually prevents people from using it in any meaningful way (read: sure, you can do it as long as you never update, but then the next time you run Windows Update it will break).

jmull 3y ago

> ...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).

cmrdporcupine 3y ago
> It would really be a better approach to work on getting Rust to adopt the features of Zig you're looking for. I was just pondering the other day about how nice it would be to take to get the same level of quality C/C++ integration that Zig has, but in Rust. My new job has acres and acres of C++ which isn't going to go away. Linking and wrapping against C++ is one thing; build system integration is another. Zig has some serious advantages there. That and I really want allocator_api and simd to get into stable.
- Ygg2 3y ago
  I'm not familiar with Rust vs Zig C++ integration. What are the stumbling blocks? Lack of stable ABI in Rust?
  - cmrdporcupine 3y ago
    I don't have much Zig experience at all, but from what I've read Zig is pretty genius because in addition to being a Zig compiler -- with its own sane build system -- the same tool also acts as a C/C++ compiler. So mixing Zig and C/C++ has a lot less friction.

tialaramex 3y ago

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.

JodieBenitez 3y ago

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.

wizzwizz4 3y ago
Your last three examples are syntactically invalid Rust. It should be more like: <'_> #[foo] stuff::thing::blah match gloop(gloop) { x @ _ => x } if fizz { |buzz| Some(buzz) } else { |_| None } Meh => |wtf| ()
- JodieBenitez 3y ago
  You're certainly right, I just copy/pasted stuff from the article and changed identifiers, probably adding errors in the process, but the point was never to give accurate examples, just point that even reading Rust code requires significantly more learning than other languages. YMMV of course. Thanks for correcting me. Still not a joy to read though.
  - wizzwizz4 3y ago
    It requires less learning than Haskell. A tad more than C. Less than C++.
    - maleldil 3y ago
      > Less than C++ That depends. Rust requires less learning than C++ for writing safe code. There are plenty of C++ developers that feel like they know the language but produce unsafe code. Rust won't let you do that, so these developers complain.
hucker 3y ago
The last three are taken from the OPs Zig example, and is not valid Rust at all.

hurril 3y ago

Who's going to tell him that comptime functions is what macros are?

Yoric 3y ago
They're not?

noelwelsh 3y ago

> "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 https://en.wikipedia.org/wiki/Monomorphization [2]: https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14/free.pdf https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14...

bestouff 3y ago
How can you call a method on a type if you don't know anything about it ? How do you even know the method exist without some dynamic casting of sorts ?
- noelwelsh 3y ago
  It's not calling methods on a type that is the issue. It's passing parameters to a method or function when that method or function has a generic type for that parameter. In Rust this is something like fn foo<A>(a: A): A (which can only have one implementation, the identity, if you don't break the abstraction barrier provided by generic types.)
- dangitdangitdan 3y ago
  [flagged]
- Joker_vD 3y ago
  You pass that method along with the value, so it's the caller's responsibility. At some point along the call stack there will be a monomorphic function which has to know the actual type it's calling its polymorphic callee with.

thadt 3y ago

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.

insanitybit 3y ago
Adding serialization with serde is a matter of adding `#[derive(Serialize, Deserialize)]`. I guess that's magical in a way, but does that matter?
- estebank 3y ago
  GP is talking about adding support for a specific format to Serde, something equivalent to serde_json, not serializing an ADT they have. I've also found it to be difficult.
  - insanitybit 3y ago
    Ohhhh, I see. Yes, I think comptime would be a big win there.

sam0x17 3y ago

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 https://crates.io/crates/docify * macro_magic: https://crates.io/crates/macro_magic https://crates.io/crates/macro_magic * crate-settings (non-functional until this comes out): https://crates.io/crates/crate-settings https://crates.io/crates/crate-settings * proc-utils: https://crates.io/crates/proc-utils https://crates.io/crates/proc-utils

EscapeFromNY 3y ago

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 https://kaylynn.gay/blog/post/rust_ranges_and_suffering

Ygg2 3y ago
It's a well known issue, but it might never be solved due to backwards compatibility. They were made non-Copy to avoid a nasty footgun, and way before IntoIterator existed.

eviks 3y ago

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?

einpoklum 3y ago

> 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.