32 ms·

Rust: A Critical Retrospective

577 points by sohkamyung 4y ago

farzatv 4y ago
tommyage 4y ago
I did not read the post, but scanned for the first contra-argument: A very dense syntax. This is the reason Rust did not attract me. I want to raise the following: Rust is overengineered. If these highly-intelligent contributors would settle on D, I think humanity/developer-community would archive more collaborations on essential pieces of software. Imo a statically-typed language is required to develop maintainable code. Human communications, read documentation, is much easier to extend than compilation-restrictions of a programming language. What are the non-fixable downsizes, which prevent serious adaptation of D? readsupuponthepostbecauseaCcomparsionwasspotted My personal opinion is: The convenience of tooling. Currently I am developing a language agnostic language server, which aims to be integrated in unix environmets without requiring exorbitant memory (currently 8 MB + file-contents). I feel, that this is my only contribution I can submit to the community iff I suceed.
cek 4y ago
As I was reading the article (in which I learned a ton about Rust, of which I know little), I kept thinking "I know that guy!". Then I realized the OP was THE "Bunnie" of Xbox reverse engineering fame [1]. <3 [1] https://en.wikipedia.org/wiki/Andrew_Huang_(hacker) https://en.wikipedia.org/wiki/Andrew_Huang_(hacker)
cmrdporcupine 4y ago
Good article. I have some things to say, because that's what I do. To start: I have to say that I find some of the comments here a little odd -- the competition for Rust is not Go or TypeScript or Kotlin or whatever. If you're using Rust in your full-stack webdev world to serve, like, database queries to webpages or whatever... I don't know why. Rust is clearly for things like: writing an OS, writing a browser, writing a low latency high throughput transaction server, writing a game. For the other things I'd say there's plenty of other options. It's been years since I worked in web applications, but I struggle to see the need for Rust there. Rust is for the same niche that C++ and C sit in now. A similar niche that Zig is targeting. I don't think D with its <admittedly now optional> GC or Golang sit in this same space at all. Also, having spent a year working in Go I don't understand how anybody could complain about Rust encouraging boilerplate but propose Go with a straightface. Go (at least the Go I was working on at Google) was just a pile of boilerplate. Awful. The syntax of the language is... fine. Generics will fix most of my complaints with it. The culture around the language I found repulsive. Anways, for years (prior to C++-11) I whined about the state of C++. Not just its lack of safety but the idiosyncracies of its syntax and its lack of modern language features I was familiar with from e.g. OCaml and from hanging out on Lambda The Ultimate. By modern features I mean pattern matching & option / result types, lambdas, type inference, and a generics/parameterized type system which wasn't ... insane. Remember, this is pre-C++11. It was awful. C++-11 and beyond addressed some concerns but not others. And I actually really love writing in C++ these days, but I'm still well aware that it is a dogs breakfast and full of foot guns and oddities. I've just learned to think like it. Anyways, back to Rust...before C++11, when I saw Graydon Hoare had kickstarted a project at Mozilla to make a systems programming language (that is without a GC) that supported modern language features I was super stoked. I tended to follow what Graydon was doing because he's talented and he's a friend-of-friends. Rust as described sounded like exactly what I wanted. But the final delivery, with the complexities of the borrow checker... are maybe something that I hadn't gambled on. Every few months I give another wack at starting a project in Rust and every few months I tend to run up against the borrow checker with frustration. But I think I have it licked now, I think I will write some Rust code in my time off work. So my personal take on Rust is this: on paper it's the fantasy language I always wanted, but in reality it has many of the complexity warts that other people have pointed to. However it is better than all the alternatives (other than maybe Zig) in this space in many many ways. But most importantly it seems to have gained momentum especially in the last 2-3 years. It seems clear to me now that the language will have success. So I think systems developers will probably need to learn and "love" it just like they do C/C++ now. And I don't think that's a bad thing because I think a culture will build up that will get people up to speed and some of the syntactical oddities just won't look that odd anymore. And the world of software dev will hopefully be a bit safer, and build systems less crazy, and so on.
- devnull3 4y ago
  > other than maybe Zig As much as I like Rust, I am keeping an eye on Zig. But Zig 1.0 is too far away to be considered as a contender right now.
  - merely-unlikely 4y ago
    Agree. I'm very much looking forward to 1.0 but I'll be waiting sitting down.
jacquesm 4y ago
Absolute gold this article. "In the long term, the philosophy behind Xous is that eventually it should “get good enough”, at which point we should stop futzing with it." I wished more people would get this.
- lodovic 4y ago
  You do need a very patient sponsor for such projects though
  - StillBored 4y ago
    I'm not sure I understand what you mean here. If anything a sponsor should be happy if there is an end goal. Far to many projects feel the need to constantly futz with their product long past when its "done". I think the most people understand this about windows. No one is asking for yet another UI change, or intrusive snooping. Windows could have been done the day they released 64-bit windows XP (or windows7 depending on your politics), and we would have a far better OS, if they had simply laid off 90% of the team leaving the remaining people in a bug fix only maintenance mode.
daviddever23box 4y ago
Nicely balanced article.
nu11ptr 4y ago
> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read I'm a huge Rust fan, but sort of agree. First, I dislike C-style syntax in general and find it all very noisy with lots of unnecessary symbols. Second, while I love traits, when you have a trait heavy type all those impl blocks start adding up giving you lots of boilerplate and often not much substance (esp. with all the where clauses on each block). Add in generics and it is often hard to see what is trying to be achieved. That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up. I've even done some prototyping of what alternative syntaxes might look like and they aren't much improvement. There is just a lot of data that is needed by the compiler. In summary, Rust syntax is noisy and excessive, but I'm not convinced much could have been done about it.
- jillesvangurp 4y ago
  Something like Kotlin but with a borrow checker might be the ultimate in developer ergonomics for me. I sat down at some point to wrap my head around Rust and ended up abandoning that project due to a lack of time. And because it was hard. The syntax is a hurdle. Still, I would like to pick that up at some point but things don't look good in terms of me finding the time. However, Rust's borrow checker is a very neat idea and one that is worthy of copying for new languages; or even some existing ones. Are there any other languages that have this at this point? I think the issue with Rust is simply that it emerged out of the C/C++ world and they started by staying close to its syntax and concepts (pointers and references) and it kind of went down hill from there. Adding macros to the mix allowed developers to fix a lot of issues; but at the price of having code that is not very obvious about its semantics to a reader. It works and it's probably pretty in the eyes of some. But too me it looks like Perl and C had a baby. Depending on your background, that might be the best thing ever of course.
  - cogman10 4y ago
    The borrow checker doesn’t really work without lifetime annotations. When I see complaints about rust, that’s seems to be the thing most are talking about. The issue is the notion of an object lifetime is a hard thing to express with familiar type systems. It’s an unfamiliar concept.
ducktective 4y ago
About the installation method ('hi! download this random shell script and execute it'), I agree this is really dangerous but mere installing stuff is a hairy thing on linux distros. I mean what is the practical alternative? Distro package manager versions are almost always way behind. NixOS/guix are gonna solve this issue once and for all (famous last words)
- IshKebab 4y ago
  > this is really dangerous People repeat this a lot but really it just seems dangerous. Can you give an example of a scenario where offering a download via `curl | bash` is more dangerous than "download this installer with the hash 01234 and then execute it"?
  - ben0x539 4y ago
    The site could detect that it's invoked as part of a `curl | bash` and sometimes serve a different script than you would get if you manually downloaded the script or the installer for manual inspection/auditing, making it harder to detect shenanigans. I think someone wrote this up as a PoC/blog post at some point.
    - IshKebab 4y ago
      A binary that you download could be obfuscated to make it hard to audit. A site could offer different binaries to different people, locations, times of day, user agents, etc. That's not really a realistic risk.
      - ben0x539 4y ago
        It's not so much script vs binary, but once everybody downloads a file they can compare them to make sure they're getting the same file.
        IshKebab 4y ago
        You can download the script using curl and then inspect it and run it if you really want?
Starlevel001 4y ago
> This is in part because all the Rust documentation is either written in eli5 style (good luck figuring out “feature”s from that example), or you’re greeted with a formal syntax definition (technically, everything you need to know to define a “feature” is in there, but nowhere is it summarized in plain English), and nothing in between. I wish I wish that Rust had a better documentation system. It's rather telling that any serious project has to use an entirely separate static site generator because the official doc system is so crippled. Compare this to the Python docs, or some truly excellent Python library docs (like Trio: https://trio.readthedocs.io/en/stable/ https://trio.readthedocs.io/en/stable/, or Flask: https://flask.palletsprojects.com/en/2.1.x/ https://flask.palletsprojects.com/en/2.1.x/, or Django: https://docs.djangoproject.com/en/4.0/https://docs.djangoproject.com/en/4.0/ https://docs.djangoproject.com/en/4.0/https://docs.djangopro...), which are all written using Sphinx and integrate properly with crossrefs and such rather than writing manual markdown links as an example.
- pitaj 4y ago
  I don't find rustdoc lacking at all. It's great for API documentation and it does have intradoc links. Of course for a more serialized tutorial, rustdoc is not a good fit so we have mdbook.
  - est31 4y ago
    intradoc links are great, and I disagree with GP that rust's documentation tools are bad, they are pretty great. However, intra doc links have the limitation that you can't link to downstream crates: https://github.com/rust-lang/rust/issues/74481 https://github.com/rust-lang/rust/issues/74481
- deleted 4y ago
  [deleted]
- burntsushi 4y ago
  'cargo doc' is absolutely one of my most favorite things about Rust. I've never once seen it as crippled and I've never once reached for an "entirely separate static site generator" to write docs despite maintaining several serious projects. Writing out explicit links sucked, but we have intradoc links now. It was a huge win. But my first paragraph above was true even before intradoc links too. Also, I hate Sphinx. It's awesome that folks have been able to use it to produce great docs, but I've never been successful in using it. I disliked it enough that I wrote my own tool for generating API documentation in Python.[1] [1]: https://github.com/mitmproxy/pdoc https://github.com/mitmproxy/pdoc
collaborative 4y ago
I experimented with replacing an Express server with Rust while keeping the same js syntax and still running on Node Granted this adds overhead, but my conclusion was that the performance gain is not worth the effort. Sure, memory looks almost flat but response times aren't that much better https://github.com/javieranton-zz/warp_like_express https://github.com/javieranton-zz/warp_like_express
- lllr_finger 4y ago
  It's really cool that you experimented with this! My experience is that choosing Rust just for performance gains usually doesn't pay off. In your case, node already uses C/C++ under the hood, so some of what you're replacing could just be switching that for Rust. The primary reason I reach for it is when I want the stability provided by the type system and runtime, and to prevent a litany of problems that impact other languages. If those problems aren't something I'm looking to solve, I'll usually reach for a different language.
  - curun1r 4y ago
    > choosing Rust just for performance gains usually doesn't pay off Performance is a complex topic. Other languages can be fast and you’re likely right that with simple initial benchmarks, Rust isn’t going to out-perform other languages by enough to make much of a difference. But what about consistency of performance? Is your 1,752,974,468th response going to be as fast as the ones in your benchmark? To me, that’s been the eye opener of deploying Rust in production. We saw P100 response times within 10ms of P0. The absolute worst case was below the threshold for human observability from the absolute best case over many months of heavy use. The metrics graphs were literal flat lines for months on end across tens of billions of requests. I have never seen that in any garbage-collected language. That kind of performance may not be necessary for your needs and you may be able to tolerate or otherwise live with occasional slowdowns. But there are plenty of cases where consistent performance is necessary or extremely desirable. And in those cases, it’s nice to have Rust as an option.
throwaway17_17 4y ago
‘Before [const generic], Rust had no native ability to deal with arrays bigger than 32 elements’. Is this a correct statement? I have seen posts talking about const generics being a new thing as of 2022. Did Rust actually lack the ability to have an array with more than 32 elements? I find it hard to believe that there was no way to have an array of longer length and Rust still being a production level language.
- Animats 4y ago
  There were some awful hacks to make integer parameters to generics sort of work before "const generic" went in. There were tables of named values for 0..32, then useful numbers such as 64, 128, 256, etc. Those haven't all been cleaned out yet.
- carry_bit 4y ago
  You could have bigger arrays, what was missing were the trait implementations. Originally the traits were implemented using a macro, and the macro only generated implementations for up to length 32.
- masklinn 4y ago
  It’s not quite correct no. Before const generics most traits were only implemented up to 32 elements though, which could be quite annoying. Even more so as the compilation error was not exactly informative.
- est31 4y ago
  You have always been allowed to have arrays longer than 32 elements, but dealing with them used to be hard. Beyond the Copy trait, which is a compiler builtin, many traits weren't implemented for arrays with more than 32 elements. The first such change was implemented in 1.47.0 in 2020 where a bunch of traits were made work on all array sizes: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1470-2020-10-08 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... It took a few releases, until 1.51.0 in 2021, until custom traits could be implemented for arrays of any length: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1510-2021-03-25 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... And the feature is still limited. For example, legacy users like serde still can't switch to the new const generics based approach, because of the same issue that the Default trait is facing. Both traits could be using const generics, if they were allowed to break their API, but neither want to, so they are waiting for improvements that allow them to switch without doing a hard API break.
alkonaut 4y ago
> “Hi, run this shell script from a random server on your machine.” You shouldn't run scripts from a random server but you probably have to consider running scripts from a server you trust. If you don't trust the server you run the script from, are you really going to run the executables this script installs? If we ignore the idea of downloading and building every program from source, then you'll download and run programs compiled by someone else. And you need to trust them, or sandbox the programs. There are no alternatives. Yes, the bash script or msi can kill your dog and eat your homework but there isn't much we can do about that without running things in in sandboxes - and the (old/normal) windows app model doesn't have that. Auditing the script won't help you, because it'll say it will install a program somewhere. Which is what you want, so you'll consider the audit "ok". But the people who wrote the script/installer are the same people that created the program (or have compromised the computers producing both) and now you'll run the rustc.exe program you just installed and that will eat your homework! To most people there is no difference in how transparent a bash script is compared to an msi. Downloading an msi from a https server I trust, signed with a cert I trust, is something I'm mostly comfortable with. The same applies to running a bash script from a location that is trustworthy.
- usrn 4y ago
  With the other languages the apps on my machine are built with (C, and to a large degree Python) I have the benefit of the distribution maintainers at least looking in the general direction of the source for things I install (including development libraries.) Tools like Cargo shortcut that and open me up to a lot of nastiness. It's very similar to the problem on Windows really and I wouldn't be surprised if you started seeing malware disturbed that way like we're currently seeing on NPM and Pypi.
  - pornel 4y ago
    rustup in particular is well-behaved. It installs itself in a single directory, without modifying the system, apart from PATH which it warns you about, lets you skip it, and when it does it, it does with care. OTOH many distros don't take care to build and package Rust properly. For example, Rust patches its version of LLVM to avoid known bugs. The particular combination of Rust version + LLVM version is most tested. Distros that insist on unbundling build Rust with a stock LLVM that doesn't have these bugfixes, and often is an older version of LLVM that hasn't been thoroughly tested with Rust. Then there's the mismatch of upgrade approach between the Rust project and most distros. Rust uses an "evergreen" (Chrome-like) approach to upgrades, in which the focus is on making upgrades seamless and not breaking anything so that they can be small and frequent. Most distros prefer infrequent big upgrades, so they package unusably old and officially unmaintained versions of Rust for no good reason.
beardicus 4y ago
bunnie is so kind and thoughtful, even when being critical. compare this to the typical frothy-mouthed 'rant' format we see here. i'm sure rants are cathartic for the writer, but i rarely find them compelling.
- rob74 4y ago
  Well, that's the difference between the "I like [X], but have a few complaints that I want to get off my chest" kind of rant and the "I hate [X], and want to convince everyone how bad it is and to never ever use it again" kind of rant...
- jacquesm 4y ago
  Not only that, he's modest.
NoGravitas 4y ago
> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. I'm not sure this is a superficial complaint. People say the hard thing about learning Rust is the new concepts, but I haven't found that to be true at all. The concepts are easy, but the combinatorial explosion of syntax that supports them is untenable.
- kkoning 4y ago
  > but the combinatorial explosion of syntax that supports them is untenable. I wouldn't go quite that far myself, but it's definitely one of the sharper edges of the language currently--particularly because some of the features don't work together yet. E.g., async and traits.
- devit 4y ago
  How would you change the syntax? I don't think that Rust has much redundant syntax. I guess you could do things like replace &'a Type with Ref<'a, Type> and *Type with Ptr<Type>, and get rid of some sugar like "if let" and print!, but I'm not sure that would have much of an impact.
- sidlls 4y ago
  Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom. And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems. First, I don't want to work with languages that attract this kind of person. Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. "You get used to it," "with practice it fades to the background," etc. are responses I've seen in these comments, and more generally when this issue comes up. They're inaccurate at best, and often simply another way the above mentioned "geniuses" manifest that particular personality flaw. No, thank you. I'll pass.
est31 4y ago
I wonder what the author means by the alloc crate not being stable? The alloc crate is stable since 1.36.0: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1360-2019-07-04 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... Regarding the reproducible builds concern around paths being integrated into the binary, a flag exists to get rid of paths: --remap-path-prefix https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output https://doc.rust-lang.org/rustc/command-line-arguments.html#... On nightly, there is also remap-cwd-prefix added by the chromium team to address some of the shortcomings with remap-path-prefix: https://github.com/rust-lang/rust/issues/89434 https://github.com/rust-lang/rust/issues/89434 Overall I'm really impressed that an individual wrote 100 thousand lines of Rust. That's a lot!
- ntoskrnl 4y ago
  Yep, this is a great article, but that section (the whole "Rust Isn’t Finished" section) jumped out as a place where there were some simple ways he could have made his life easier. It could also have been a failure of the Rust community to teach a good workflow. You don't need to force every contributor to upgrade every six weeks in lockstep, since releases of Rust and std are backwards compatible. Upgrade at your leisure, and run tests in CI with the minimum version you want to support. If you're doing something crazier that requires ABI compatibility between separate builds (or you just want consistency), you can add a `rust-toolchain` file that upgrades the compiler on dev machines automatically, as seamlessly as Cargo downloads new dependency versions.
  - burntsushi 4y ago
    To clarify a bit, the key thing here is that the OP is maintaining their own patches to Rust's standard library. While the API of std is itself backwards compatible, its implementation uses a whole mess of unstable nightly features. That means that std for Rust 1.x can't necessarily be built with Rust 1.(x-1). EDIT: Nor can std for Rust 1.(x-1) be necessarily built by Rust 1.x. It's true that you don't have to force every contributor to upgrade every six weeks, but you do very likely need to have every contributor use the same version of Rust. (Which can be accomplished with a rust-toolchain file, as you mention.) The problem here is that if you don't do this upgrade whenever a new Rust release is made, you're just putting off that work to some other point. Maybe you do it every 12 weeks instead of 6 weeks, that would probably be okay. But I'd imagine waiting a year, for example, could be unpleasant.
sim7c00 4y ago
really interesting read, and nice to see people writing operating systems on rust and have also plus points besides grievances. particularly enjoyed you found rust sometimes spares you the 'damn i need to rewrite this entire thing' tour that C always hits me with :D. now i am more hopeful my re-write-the-entire-thing-in-rust was an ok'ish choice.
- bunnie 4y ago
  Took me a full year of questioning life choices before it felt worth it, but fearless refactoring is so nice. I may have trouble going back to C just for that.
ReactiveJelly 4y ago
> I wrote a small tool called `crate-scraper` which downloads the source package for every source specified in our Cargo.toml file, and stores them locally so we can have a snapshot of the code used to build a Xous release. I thought `cargo vendor` already did this? https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html > This cargo subcommand will vendor all crates.io and git dependencies for a project into the specified directory at <path>. After this command completes the vendor directory specified by <path> will contain all remote sources from dependencies specified. Maybe he doesn't want to depend on Cargo. Fair enough, it's a big program.
- bunnie 4y ago
  The big thing I wanted was the summary of all the build.rs files concatenated together so I wasn't spending lots of time grepping and searching for them (and possibly missing one). The script isn't that complicated... it actually uses an existing tool, cargo-download, to obtain the crates, and then a simple Python script searches for all the build.rs files and concatenation them into a builds.rs mega file. The other reason to give the tool its own repo is crate-scraper actually commits the crates back into git so we have a publicly accessible log of all the crates used in a given release by the actual build machine (in case the attack involved swapping out a crate version, but only for certain build environments, as a highly targeted supply chain attack is less likely to be noticed right away). It's more about leaving a public trail of breadcrumbs we can use to do forensics to try and pinpoint an attack in retrospect, and making it very public so that any attacker who cares about discretion or deniability has deal with this in their counter-threat model.
  - woojoo666 4y ago
    Reminds me of your talk on supply chain security[1], I loved that one. [1]: https://www.youtube.com/watch?v=RqQhWitJ1As https://www.youtube.com/watch?v=RqQhWitJ1As
  - epage 4y ago
    Don't forget about proc macros. If they don't, I wonder if one of the auditing commands should support drawing attention to build.rs and proc macros like this.
alexfromapex 4y ago
When Nightly is breaking no-std targets, is there not a way to pin a specific Nightly release to prevent that?
- xobs 4y ago
  You can do that! But you may run into a problem where one of the crates you use detects that you're using nightly, and then opts in to nightly-only features. Except it may be using features that are only available on the latest version of nightly, or an ancient version that you don't have, and there is no version that makes both your code and the dependent package happy. It's much better to just use stable. Then you're guaranteed to have forward compatibility, and you only have one place where you need to deal with the nightly weirdness.
- steveklabnik 4y ago
  There is, yes. You put a file in the root of your project with the specific version of Rust you want, and it’ll get picked up and used by the tooling.
- vgel 4y ago
  There is, but then you're pinning yourself to whatever bugs are in that nightly, and making the eventual upgrade that much worse.
_wldu 4y ago
Once rust stabilizes, I think it needs an ISO standard like C and C++ have. I can't see automobile manufactures using rust without one. One reason C and C++ are still widely used is due to this. When we are writing code that is expected to run for decades, having a corporate/community backed language is not sufficient. We need global standards and versions that we can rely on decades latter.
- avgcorrection 4y ago
  I think C caught on because it spread like a cancer through institutions like universities. Want to catch on? Be a virus. Not some gosh-darned international standard.
  - pjmlp 4y ago
    Nice way to view UNIX, a virus.
- rwaksmunski 4y ago
  Lack of standards committee body making decisions is feature, not a bug. Car manufactures can stick with C.
  - Avamander 4y ago
    Considering how "smart" cars are getting, no, they shouldn't.
- pie_flavor 4y ago
  What has the standard actually gotten C and C++? Basic features needed in every single code base like type punning on structures are standardly UB, while design-by-committee results in C++ feature hell. It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs. A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.
deleted 4y ago
[deleted]
bfrog 4y ago
Very cool, and it’s true Rust is dense. On the other hand C, the other typical option, either requires massive amounts of ancillary tooling and macros like Zephyr to get even close to doing as much at compile time. Those tools and macros add density and complexity. Arguably C++ is about equivalent with fewer pros over C and plenty of the cons of C still there along with some new ones. I appreciate the idea of trying to create a auditable OS for an MMU capable CPU, the reality is once you have feature you care about that becomes harder and harder it seems.
wiz21c 4y ago
FTA : "This is the point at which Rust’s very strict typing and borrow checker converts from a productivity liability into a productivity asset." that's what rust is about in my own experience. Especially with threads.
- ModernMech 4y ago
  Me too. A lot of people who try Rust encounter a very steep learning curve, and tend to question whether the borrow checker and strict typing is even worth it. For me, it's allowed me to build larger threaded and distributed systems than I've ever been able to before. I've tried to build such systems in C/C++ but I've never been able to make something that isn't incredibly brittle, and I've been writing in those languages for 25 years. For a long time I thought maybe I'm just a bad programmer. Rust changed all that. I'm kind of a bad programmer I guess, because Rust caught a lot of bad decisions I was making architecturally, and forced me to rewrite things to conform to the borrow checker. This is the point at which I've found many people give up Rust. They say to themselves "This is awful, I've written my program one way I'm used to, and now it looks like I have to completely rewrite it to make this stupid borrow checker happy. If I had written in C++ I'd be done by now!" But will you really be done? Because I had the same attitude and every time I went back to C++ I surely built something, but if it got too large it would be a sandcastle that would fall over at the slightest breeze. With Rust I feel like I'm making skyscrapers that could withstand an earthquake, and I actually am because the programs I've written have weathered some storms that would have washed my C++ code out to sea. Of course one can make stable, secure, performant systems in C++ and many other languages. But apparently I can't, and I need something like Rust to empower me. Someone else here said that Rust attracts people who want to feel powerful and smart by writing complicated code, but I like to write Rust code just to not feel inept!
- epage 4y ago
  I remember someone saying that "Rust skipped leg day", feeling that Rust was overly focused on the borrow checker while only solving a small number of problems. 1. I think its easy, especially for GC users, to forget that memory management is really about resource management. 2. The composability of features with the borrow checker is outstanding, like proper session types / locks or Send+Sync for safe use data with threads.
jvanderbot 4y ago
I loved this perspective from a hardware oriented engineer coming to appreciate the enormous complexity and difficulty in providing a stable and useful data structures and algorithms library as part of, say, rust std. Each complaint is valid, but some of it is (they admit) coming from a bit of naivete. They're surprised red black trees are included in the Linux kernel? why? They were surprised at how useful rust std and a good? data structure foundation was? why?
voidhorse 4y ago
I wholeheartedly agree that rust’s syntax is way noisier and uglier than I’d like, and it’s nice to see someone else raise the point seriously. People tend to act like syntax is an ancillary detail in a language, but actually it’s fundamental! It’s our direct interface into the language itself and if it’s painful to read and write the language won’t be pleasant to use, no matter how great it’s semantics may be. Beyond the line noise problem. I feel some of rust’s syntactic choices are confusing. For instance: let x = 2 Introduces a new name and binds it to the value 2 while if let Some(x) = y Is a shorthand for pattern matching. Meanwhile other matching structures have no need of “let” at all. Likewise this extends the semantics of what “if” means and also overloads “=“ (e.g, glancing at this, would you say equals is binding a value to a pattern, performing a Boolean check, or both?) Rust has a couple of one-off weird syntactical devices that have been introduced as shorthand that imo quickly increase the cognitive load required to read code because several structures and keywords are reused in slightly different ways to mean entirely different things. There are a lot of similar syntactic hoops around type signatures because they didn’t go with the old “type variables must be lowercase” rule which leads to subtle potential ambiguities in parsing T as a variable or proper type in some cases that thus forces additional syntax on the user. I also think there are too many ways to express equivalent things in Rust, which again leads to more cognitive overhead. Reading the current docs, I get the sense the language is becoming “write biased”. Whenever they introduce some syntactic shortcut the justification is to save typing and eliminate small amounts of repetition, which is great in theory but now we have N ways of writing and reading the same thing which quickly makes code hard to grok efficiently imo. This minor gripe comes with the big caveat that it remains probably the most interesting language to become vogue since Haskell.
- avgcorrection 4y ago
  Conservative Java has something similar with try-with-resource and the upcoming instanceof pattern matching.
- irishsultan 4y ago
  > For instance: > let x = 2 > Introduces a new name and binds it to the value 2 while > if let Some(x) = y > Is a shorthand for pattern matching. Both introduce a new name (x) and both pattern match, it's just that the pattern in let x = 2 is simply match anything and assign it the name x, you could just as well write let t@(x, y) = (2, 4); Which binds t to (2, 4), x to 2 and y to 4 and there it's perhaps more clear that normal let is pattern matching as much as if let is pattern matching.
ArdelleF 4y ago
We do a lot of Rust compilation exploration during the development of TiKV(github.com/tikv/tikv), a lot of interesting learnings ... https://en.pingcap.com/blog/rust-huge-compilation-units/ https://en.pingcap.com/blog/rust-huge-compilation-units/
- SemanticStrengh 4y ago
  thanks for maintaining jemalloc :)
fmakunbound 4y ago
> It’s 2022 after all, and transistors are cheap: why don’t all our microcontrollers feature page-level memory protection like their desktop counterparts? I always thought it was because of the added cost from increased design complexity. Is it something else?
- riskable 4y ago
  Haha, no: It's because if you put an MMU in a microcontroller it's not a microcontroller anymore! That makes it an "application processor" of which there are many tens of thousands to choose from these days. There's nothing stopping you from taking say, a Raspberry Pi 4 and using it as a bare metal device (no OS) just like an Arduino. Or taking that same chip (BCM2711) and putting it in your own board to do something similar. It just wouldn't be economical for that sort of purpose most of the time.
- bunnie 4y ago
  Secretly, I suspect the answer is market differentiation. You can charge a higher royalty for a CPU core that has an MMU, and bundling it into the low end stuff erodes margins. The complexity is real, but in a typical SoC the actual CPU core is maybe 10% of the area and tossing in an MMU impacts maybe 1-2% of the total chip area. I haven't seen the pricing sheets, but I suspect the much bigger cost is the higher royalty payment associated with instantiating the MMU.
SemanticStrengh 4y ago
Let me takes this opportunity to explain that among the many contraints of rust, it is the undertalked one about the absurd no cast promotion from smaller integer (e.g. a char) to a bigger integer that made me quit and save my sanity. Having to make explicit casts a dozen times per functions for basic manipulations of numbers on a grid (and the index type mismatch) is an insult to the developer intelligence. It seems some people are resilient and are able to write nonsensical parts of code repeatedly but for me, I can't tolerate it.
- josephg 4y ago
  I don’t mind a few “as usize” casts because usually you can cast once and be done with it. But the cast that kills me is this one: How do you add an unsigned and a signed number together in rust, in a way which is fast (no branches in release mode), correct and which panics in debug mode in the right places (if the addition over- or under-flows)? Nearly a year in to rust and I’m still stumped!
  - steveklabnik 4y ago
    https://rust.godbolt.org/z/e377o5148 https://rust.godbolt.org/z/e377o5148 is the first thing I thought of. You didn't specify sizes, or if you wanted the result to be signed or unsigned, but "assume two's compliment wrapping in release and panic in debug on over/underflow" is the default behavior of +.
    - mjw1007 4y ago
      That fails the "panics in debug mode in the right places" requirement: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f242c49005c7386dfaae45d01b56dc95 https://play.rust-lang.org/?version=stable&mode=debug&editio...
      - steveklabnik 4y ago
        Oh duh, yeah, my bad. I was tweaking stuff around and lost that property. And seems like TryInto doesn't compile away entirely. Boo. You can write your own debug_assert! though: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ac1becf96a6f956a5bf8bf7551f2c253 https://play.rust-lang.org/?version=stable&mode=debug&editio... not as nice, but it does work. If you were doing this a lot you could macro it up, impl as a method on all the various types you want... a pain, but it is possible.
secondcoming 4y ago
This was a very interesting read. IMO the author underplays the visual ugliness of some Rust code. Programmers tend to look at code for hours a day for years, and so it should not be visually taxing to read and parse. This is why syntax highlighting exists, after all. But the gist I got from it is that Rust is really a very good static analyser.
- bb010g 4y ago
  I find Rust code rather pleasant to read.
gary17the 4y ago
> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read :) If you think that Rust is dense and difficult to eyeball, please do try... Swift - purely for therapeutic reasons. But not the usual, trivial, educational-sample, evangelism-slideshow Swift, please, but real-world, advanced Swift with generics. All the unique language constructs to memorize, all the redundant syntactic sugar variations to recognize, all the special-purpose language features to understand, all the inconsistent keyword placement variations to observe, all the inferred complex types to foresee, etc. will make you suddenly want to quit being a programming linguist and instead become a nature-hugging florist and/or run back to Go, Python, or even friggin' LOGO. I'm tellin' ya. And, when considering Swift, we're not even talking about a systems programming language usable with, say, lightweight wearable hardware devices, but about a frankenstein created (almost) exclusively for writing GUIs on mobile devices usually more powerful than desktop workstations of yesteryear :). Rust is complex, but very good.
- pphysch 4y ago
  Interesting, I had no idea what I was missing out on. Conversation from last week: Me: "So what are you working on at $company?" Friend: "We're building a complete HVAC management system for all types of buildings, from hardware to software" Me: "Cool! What technologies are you building it on?" Friend: "Swift" Me: "...for like an iOS app to monitor the system?" Friend: "No, everything is written in Swift. The entire backend too." Me: "Interesting... Have you shipped anything yet?" Friend: "No but the founder is running a prototype in his house and we just secured another round of funding..." ** Is this a common thing?
  - gary17the 4y ago
    Considering the speed of adoption of server-side Swift as well as the progress of Swift's support for Linux, I am guessing we are talking about some expert variation of the pump-and-dump investment technique here ;).
bilkow 4y ago
It looks like I'm on the minority here, but I generally like Rust's syntax and think it's pretty readable. Of course, when you use generics, lifetimes, closures, etc, all on the same line it can become hard to read. But on my experience on "high level" application code, it isn't usually like that. The hardest thing to grep at first for me, coming from python, was the :: for navigating namespaces/modules. I also find functional style a lot easier to read than Python, because of chaining (dot notation) and the closure syntax. Python: array = [1, 0, 2, 3] new_array = map( lambda x: x * 2, filter( lambda x: x != 0, array ) ) Rust: let array = [1, 0, 2, 3]; let new_vec: Vec<_> = array.into_iter() .filter(|&x| x != 0) .map(|x| x * 2) .collect(); I mean, I kind of agree to the criticism, specially when it comes to macros and lifetimes, but I also feel like that's more applicable for low level code or code that uses lots of features that just aren't available in e.g. C, Python or Go. Edit: Collected iterator into Vec
- Too 4y ago
  I want to like rust but the fact that there are replies with 9 different ways to write that loop posted here alone, and no consensus on which one is the idiomatic, is not a good sign.
- rajman187 4y ago
  minor point but your python code creates a generator here not an array, you'd have to wrap it in a `list()` to get the same data type and be able to for example assert its length (of course you can just iterate over the generator)
- xigoi 4y ago
  You can only do this chaining when everything happens to be a method. Compare to Nim or D, where you can chain arbitrary procedures like this.
- klodolph 4y ago
  There are people who write Python code like that, but it's an extreme minority. Here's the more likely way: array = [1, 0, 2, 3] new_array = [x * 2 for x in array if x != 0] Just as a matter of style, few Python programmers will use lambda outside something like this: array = [...] arry.sort(key=lambda ...)
StillBored 4y ago
" Yes, it is my fault for not being smart enough to parse the language’s syntax, but also, I do have other things to do with my life, like build hardware." and "Rust Is Powerful, but It Is Not Simple" among all the other points, should be enough to disqualify it for mainstream use. The core of most arguments against C++ boil down to those two points too. If a large percentage of the engineers working in the language have a problem understanding it, they are going to have a hard time proving that their aren't any unexpected side effects. Of which both C++ and rust seems to be full of, given the recent bug reports in rust and projects people are using it in. So, I'm still firmly in the camp that while there are better system programming languages than C, rust isn't one of them (hell even Pascal is probably better, at least it has length checked strings).
- IshKebab 4y ago
  > The core of most arguments against C++ boil down to those two points too. If a large percentage of the engineers working in the language have a problem understanding it, they are going to have a hard time proving that their aren't any unexpected side effects. That's true for C++ but not for Rust, because Rust will tell you if there's some kind of unexpected behaviour that you didn't think about, whereas C++ will allow UB or whatever without telling you. That's the big difference between (safe) Rust's complexity and C++'s complexity. They are both very complex, but in Rust it doesn't matter too much if you don't memorise the complexity (complicated lifetime rules, etc.) because it will just result in a compile error. Whereas in C++ you have to remember the rule of 3... no 5... etc. (that's a really simple example; don't think "I know the rule of 5; C++ is easy!").
  - pjmlp 4y ago
    Not in unsafe code blocks, and plenty of people reach to them, even for stuff they shouldn't, like fake dependent types in Rust.
- lawn 4y ago
  C++ is one of the most used languages, and it does seem to me that Rust has enough momentum going for it to be a commonly used system programming language as well. I do agree with his points, but I don't think it's enough to disqualify it for mainstream use.
jmartin2683 4y ago
Rust is awesome. I’ve been in love since the moment I met it.
dgan 4y ago
> 100k LOC over two years Dude wrote more code per week than me in last 6 month at daily job
- sydthrowaway 4y ago
  Well, he quit Big Tech long ago, now actually builds things instead of phoning it in.
dimgl 4y ago
> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. > Rust Is Powerful, but It Is Not Simple This is exactly why I haven't gotten into Rust.
- klysm 4y ago
  What do you use instead?

577 points by sohkamyung 4y ago

I did not read the post, but scanned for the first contra-argument: A very dense syntax. This is the reason Rust did not attract me. I want to raise the following: Rust is overengineered. If these highly-intelligent contributors would settle on D, I think humanity/developer-community would archive more collaborations on essential pieces of software. Imo a statically-typed language is required to develop maintainable code. Human communications, read documentation, is much easier to extend than compilation-restrictions of a programming language. What are the non-fixable downsizes, which prevent serious adaptation of D? readsupuponthepostbecauseaCcomparsionwasspotted My personal opinion is: The convenience of tooling. Currently I am developing a language agnostic language server, which aims to be integrated in unix environmets without requiring exorbitant memory (currently 8 MB + file-contents). I feel, that this is my only contribution I can submit to the community iff I suceed.

cek 4y ago

As I was reading the article (in which I learned a ton about Rust, of which I know little), I kept thinking "I know that guy!". Then I realized the OP was THE "Bunnie" of Xbox reverse engineering fame [1]. <3 [1] https://en.wikipedia.org/wiki/Andrew_Huang_(hacker) https://en.wikipedia.org/wiki/Andrew_Huang_(hacker)

cmrdporcupine 4y ago

Good article. I have some things to say, because that's what I do. To start: I have to say that I find some of the comments here a little odd -- the competition for Rust is not Go or TypeScript or Kotlin or whatever. If you're using Rust in your full-stack webdev world to serve, like, database queries to webpages or whatever... I don't know why. Rust is clearly for things like: writing an OS, writing a browser, writing a low latency high throughput transaction server, writing a game. For the other things I'd say there's plenty of other options. It's been years since I worked in web applications, but I struggle to see the need for Rust there. Rust is for the same niche that C++ and C sit in now. A similar niche that Zig is targeting. I don't think D with its <admittedly now optional> GC or Golang sit in this same space at all. Also, having spent a year working in Go I don't understand how anybody could complain about Rust encouraging boilerplate but propose Go with a straightface. Go (at least the Go I was working on at Google) was just a pile of boilerplate. Awful. The syntax of the language is... fine. Generics will fix most of my complaints with it. The culture around the language I found repulsive. Anways, for years (prior to C++-11) I whined about the state of C++. Not just its lack of safety but the idiosyncracies of its syntax and its lack of modern language features I was familiar with from e.g. OCaml and from hanging out on Lambda The Ultimate. By modern features I mean pattern matching & option / result types, lambdas, type inference, and a generics/parameterized type system which wasn't ... insane. Remember, this is pre-C++11. It was awful. C++-11 and beyond addressed some concerns but not others. And I actually really love writing in C++ these days, but I'm still well aware that it is a dogs breakfast and full of foot guns and oddities. I've just learned to think like it. Anyways, back to Rust...before C++11, when I saw Graydon Hoare had kickstarted a project at Mozilla to make a systems programming language (that is without a GC) that supported modern language features I was super stoked. I tended to follow what Graydon was doing because he's talented and he's a friend-of-friends. Rust as described sounded like exactly what I wanted. But the final delivery, with the complexities of the borrow checker... are maybe something that I hadn't gambled on. Every few months I give another wack at starting a project in Rust and every few months I tend to run up against the borrow checker with frustration. But I think I have it licked now, I think I will write some Rust code in my time off work. So my personal take on Rust is this: on paper it's the fantasy language I always wanted, but in reality it has many of the complexity warts that other people have pointed to. However it is better than all the alternatives (other than maybe Zig) in this space in many many ways. But most importantly it seems to have gained momentum especially in the last 2-3 years. It seems clear to me now that the language will have success. So I think systems developers will probably need to learn and "love" it just like they do C/C++ now. And I don't think that's a bad thing because I think a culture will build up that will get people up to speed and some of the syntactical oddities just won't look that odd anymore. And the world of software dev will hopefully be a bit safer, and build systems less crazy, and so on.

devnull3 4y ago
> other than maybe Zig As much as I like Rust, I am keeping an eye on Zig. But Zig 1.0 is too far away to be considered as a contender right now.
- merely-unlikely 4y ago
  Agree. I'm very much looking forward to 1.0 but I'll be waiting sitting down.

jacquesm 4y ago

Absolute gold this article. "In the long term, the philosophy behind Xous is that eventually it should “get good enough”, at which point we should stop futzing with it." I wished more people would get this.

lodovic 4y ago
You do need a very patient sponsor for such projects though
- StillBored 4y ago
  I'm not sure I understand what you mean here. If anything a sponsor should be happy if there is an end goal. Far to many projects feel the need to constantly futz with their product long past when its "done". I think the most people understand this about windows. No one is asking for yet another UI change, or intrusive snooping. Windows could have been done the day they released 64-bit windows XP (or windows7 depending on your politics), and we would have a far better OS, if they had simply laid off 90% of the team leaving the remaining people in a bug fix only maintenance mode.

daviddever23box 4y ago

Nicely balanced article.

nu11ptr 4y ago

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read I'm a huge Rust fan, but sort of agree. First, I dislike C-style syntax in general and find it all very noisy with lots of unnecessary symbols. Second, while I love traits, when you have a trait heavy type all those impl blocks start adding up giving you lots of boilerplate and often not much substance (esp. with all the where clauses on each block). Add in generics and it is often hard to see what is trying to be achieved. That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up. I've even done some prototyping of what alternative syntaxes might look like and they aren't much improvement. There is just a lot of data that is needed by the compiler. In summary, Rust syntax is noisy and excessive, but I'm not convinced much could have been done about it.

jillesvangurp 4y ago
Something like Kotlin but with a borrow checker might be the ultimate in developer ergonomics for me. I sat down at some point to wrap my head around Rust and ended up abandoning that project due to a lack of time. And because it was hard. The syntax is a hurdle. Still, I would like to pick that up at some point but things don't look good in terms of me finding the time. However, Rust's borrow checker is a very neat idea and one that is worthy of copying for new languages; or even some existing ones. Are there any other languages that have this at this point? I think the issue with Rust is simply that it emerged out of the C/C++ world and they started by staying close to its syntax and concepts (pointers and references) and it kind of went down hill from there. Adding macros to the mix allowed developers to fix a lot of issues; but at the price of having code that is not very obvious about its semantics to a reader. It works and it's probably pretty in the eyes of some. But too me it looks like Perl and C had a baby. Depending on your background, that might be the best thing ever of course.
- cogman10 4y ago
  The borrow checker doesn’t really work without lifetime annotations. When I see complaints about rust, that’s seems to be the thing most are talking about. The issue is the notion of an object lifetime is a hard thing to express with familiar type systems. It’s an unfamiliar concept.

ducktective 4y ago

About the installation method ('hi! download this random shell script and execute it'), I agree this is really dangerous but mere installing stuff is a hairy thing on linux distros. I mean what is the practical alternative? Distro package manager versions are almost always way behind. NixOS/guix are gonna solve this issue once and for all (famous last words)

IshKebab 4y ago
> this is really dangerous People repeat this a lot but really it just seems dangerous. Can you give an example of a scenario where offering a download via `curl | bash` is more dangerous than "download this installer with the hash 01234 and then execute it"?
- ben0x539 4y ago
  The site could detect that it's invoked as part of a `curl | bash` and sometimes serve a different script than you would get if you manually downloaded the script or the installer for manual inspection/auditing, making it harder to detect shenanigans. I think someone wrote this up as a PoC/blog post at some point.
  - IshKebab 4y ago
    A binary that you download could be obfuscated to make it hard to audit. A site could offer different binaries to different people, locations, times of day, user agents, etc. That's not really a realistic risk.
    - ben0x539 4y ago
      It's not so much script vs binary, but once everybody downloads a file they can compare them to make sure they're getting the same file.
      - IshKebab 4y ago
        You can download the script using curl and then inspect it and run it if you really want?

Starlevel001 4y ago

> This is in part because all the Rust documentation is either written in eli5 style (good luck figuring out “feature”s from that example), or you’re greeted with a formal syntax definition (technically, everything you need to know to define a “feature” is in there, but nowhere is it summarized in plain English), and nothing in between. I wish I wish that Rust had a better documentation system. It's rather telling that any serious project has to use an entirely separate static site generator because the official doc system is so crippled. Compare this to the Python docs, or some truly excellent Python library docs (like Trio: https://trio.readthedocs.io/en/stable/ https://trio.readthedocs.io/en/stable/, or Flask: https://flask.palletsprojects.com/en/2.1.x/ https://flask.palletsprojects.com/en/2.1.x/, or Django: https://docs.djangoproject.com/en/4.0/https://docs.djangoproject.com/en/4.0/ https://docs.djangoproject.com/en/4.0/https://docs.djangopro...), which are all written using Sphinx and integrate properly with crossrefs and such rather than writing manual markdown links as an example.

pitaj 4y ago
I don't find rustdoc lacking at all. It's great for API documentation and it does have intradoc links. Of course for a more serialized tutorial, rustdoc is not a good fit so we have mdbook.
- est31 4y ago
  intradoc links are great, and I disagree with GP that rust's documentation tools are bad, they are pretty great. However, intra doc links have the limitation that you can't link to downstream crates: https://github.com/rust-lang/rust/issues/74481 https://github.com/rust-lang/rust/issues/74481
deleted 4y ago
[deleted]
burntsushi 4y ago
'cargo doc' is absolutely one of my most favorite things about Rust. I've never once seen it as crippled and I've never once reached for an "entirely separate static site generator" to write docs despite maintaining several serious projects. Writing out explicit links sucked, but we have intradoc links now. It was a huge win. But my first paragraph above was true even before intradoc links too. Also, I hate Sphinx. It's awesome that folks have been able to use it to produce great docs, but I've never been successful in using it. I disliked it enough that I wrote my own tool for generating API documentation in Python.[1] [1]: https://github.com/mitmproxy/pdoc https://github.com/mitmproxy/pdoc

collaborative 4y ago

I experimented with replacing an Express server with Rust while keeping the same js syntax and still running on Node Granted this adds overhead, but my conclusion was that the performance gain is not worth the effort. Sure, memory looks almost flat but response times aren't that much better https://github.com/javieranton-zz/warp_like_express https://github.com/javieranton-zz/warp_like_express

lllr_finger 4y ago
It's really cool that you experimented with this! My experience is that choosing Rust just for performance gains usually doesn't pay off. In your case, node already uses C/C++ under the hood, so some of what you're replacing could just be switching that for Rust. The primary reason I reach for it is when I want the stability provided by the type system and runtime, and to prevent a litany of problems that impact other languages. If those problems aren't something I'm looking to solve, I'll usually reach for a different language.
- curun1r 4y ago
  > choosing Rust just for performance gains usually doesn't pay off Performance is a complex topic. Other languages can be fast and you’re likely right that with simple initial benchmarks, Rust isn’t going to out-perform other languages by enough to make much of a difference. But what about consistency of performance? Is your 1,752,974,468th response going to be as fast as the ones in your benchmark? To me, that’s been the eye opener of deploying Rust in production. We saw P100 response times within 10ms of P0. The absolute worst case was below the threshold for human observability from the absolute best case over many months of heavy use. The metrics graphs were literal flat lines for months on end across tens of billions of requests. I have never seen that in any garbage-collected language. That kind of performance may not be necessary for your needs and you may be able to tolerate or otherwise live with occasional slowdowns. But there are plenty of cases where consistent performance is necessary or extremely desirable. And in those cases, it’s nice to have Rust as an option.

throwaway17_17 4y ago

‘Before [const generic], Rust had no native ability to deal with arrays bigger than 32 elements’. Is this a correct statement? I have seen posts talking about const generics being a new thing as of 2022. Did Rust actually lack the ability to have an array with more than 32 elements? I find it hard to believe that there was no way to have an array of longer length and Rust still being a production level language.

Animats 4y ago
There were some awful hacks to make integer parameters to generics sort of work before "const generic" went in. There were tables of named values for 0..32, then useful numbers such as 64, 128, 256, etc. Those haven't all been cleaned out yet.
carry_bit 4y ago
You could have bigger arrays, what was missing were the trait implementations. Originally the traits were implemented using a macro, and the macro only generated implementations for up to length 32.
masklinn 4y ago
It’s not quite correct no. Before const generics most traits were only implemented up to 32 elements though, which could be quite annoying. Even more so as the compilation error was not exactly informative.
est31 4y ago
You have always been allowed to have arrays longer than 32 elements, but dealing with them used to be hard. Beyond the Copy trait, which is a compiler builtin, many traits weren't implemented for arrays with more than 32 elements. The first such change was implemented in 1.47.0 in 2020 where a bunch of traits were made work on all array sizes: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1470-2020-10-08 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... It took a few releases, until 1.51.0 in 2021, until custom traits could be implemented for arrays of any length: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1510-2021-03-25 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... And the feature is still limited. For example, legacy users like serde still can't switch to the new const generics based approach, because of the same issue that the Default trait is facing. Both traits could be using const generics, if they were allowed to break their API, but neither want to, so they are waiting for improvements that allow them to switch without doing a hard API break.

alkonaut 4y ago

> “Hi, run this shell script from a random server on your machine.” You shouldn't run scripts from a random server but you probably have to consider running scripts from a server you trust. If you don't trust the server you run the script from, are you really going to run the executables this script installs? If we ignore the idea of downloading and building every program from source, then you'll download and run programs compiled by someone else. And you need to trust them, or sandbox the programs. There are no alternatives. Yes, the bash script or msi can kill your dog and eat your homework but there isn't much we can do about that without running things in in sandboxes - and the (old/normal) windows app model doesn't have that. Auditing the script won't help you, because it'll say it will install a program somewhere. Which is what you want, so you'll consider the audit "ok". But the people who wrote the script/installer are the same people that created the program (or have compromised the computers producing both) and now you'll run the rustc.exe program you just installed and that will eat your homework! To most people there is no difference in how transparent a bash script is compared to an msi. Downloading an msi from a https server I trust, signed with a cert I trust, is something I'm mostly comfortable with. The same applies to running a bash script from a location that is trustworthy.

usrn 4y ago
With the other languages the apps on my machine are built with (C, and to a large degree Python) I have the benefit of the distribution maintainers at least looking in the general direction of the source for things I install (including development libraries.) Tools like Cargo shortcut that and open me up to a lot of nastiness. It's very similar to the problem on Windows really and I wouldn't be surprised if you started seeing malware disturbed that way like we're currently seeing on NPM and Pypi.
- pornel 4y ago
  rustup in particular is well-behaved. It installs itself in a single directory, without modifying the system, apart from PATH which it warns you about, lets you skip it, and when it does it, it does with care. OTOH many distros don't take care to build and package Rust properly. For example, Rust patches its version of LLVM to avoid known bugs. The particular combination of Rust version + LLVM version is most tested. Distros that insist on unbundling build Rust with a stock LLVM that doesn't have these bugfixes, and often is an older version of LLVM that hasn't been thoroughly tested with Rust. Then there's the mismatch of upgrade approach between the Rust project and most distros. Rust uses an "evergreen" (Chrome-like) approach to upgrades, in which the focus is on making upgrades seamless and not breaking anything so that they can be small and frequent. Most distros prefer infrequent big upgrades, so they package unusably old and officially unmaintained versions of Rust for no good reason.

beardicus 4y ago

bunnie is so kind and thoughtful, even when being critical. compare this to the typical frothy-mouthed 'rant' format we see here. i'm sure rants are cathartic for the writer, but i rarely find them compelling.

rob74 4y ago
Well, that's the difference between the "I like [X], but have a few complaints that I want to get off my chest" kind of rant and the "I hate [X], and want to convince everyone how bad it is and to never ever use it again" kind of rant...
jacquesm 4y ago
Not only that, he's modest.

NoGravitas 4y ago

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. I'm not sure this is a superficial complaint. People say the hard thing about learning Rust is the new concepts, but I haven't found that to be true at all. The concepts are easy, but the combinatorial explosion of syntax that supports them is untenable.

kkoning 4y ago
> but the combinatorial explosion of syntax that supports them is untenable. I wouldn't go quite that far myself, but it's definitely one of the sharper edges of the language currently--particularly because some of the features don't work together yet. E.g., async and traits.
devit 4y ago
How would you change the syntax? I don't think that Rust has much redundant syntax. I guess you could do things like replace &'a Type with Ref<'a, Type> and *Type with Ptr<Type>, and get rid of some sugar like "if let" and print!, but I'm not sure that would have much of an impact.
sidlls 4y ago
Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom. And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems. First, I don't want to work with languages that attract this kind of person. Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction. "You get used to it," "with practice it fades to the background," etc. are responses I've seen in these comments, and more generally when this issue comes up. They're inaccurate at best, and often simply another way the above mentioned "geniuses" manifest that particular personality flaw. No, thank you. I'll pass.

est31 4y ago

I wonder what the author means by the alloc crate not being stable? The alloc crate is stable since 1.36.0: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1360-2019-07-04 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... Regarding the reproducible builds concern around paths being integrated into the binary, a flag exists to get rid of paths: --remap-path-prefix https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output https://doc.rust-lang.org/rustc/command-line-arguments.html#... On nightly, there is also remap-cwd-prefix added by the chromium team to address some of the shortcomings with remap-path-prefix: https://github.com/rust-lang/rust/issues/89434 https://github.com/rust-lang/rust/issues/89434 Overall I'm really impressed that an individual wrote 100 thousand lines of Rust. That's a lot!

ntoskrnl 4y ago
Yep, this is a great article, but that section (the whole "Rust Isn’t Finished" section) jumped out as a place where there were some simple ways he could have made his life easier. It could also have been a failure of the Rust community to teach a good workflow. You don't need to force every contributor to upgrade every six weeks in lockstep, since releases of Rust and std are backwards compatible. Upgrade at your leisure, and run tests in CI with the minimum version you want to support. If you're doing something crazier that requires ABI compatibility between separate builds (or you just want consistency), you can add a `rust-toolchain` file that upgrades the compiler on dev machines automatically, as seamlessly as Cargo downloads new dependency versions.
- burntsushi 4y ago
  To clarify a bit, the key thing here is that the OP is maintaining their own patches to Rust's standard library. While the API of std is itself backwards compatible, its implementation uses a whole mess of unstable nightly features. That means that std for Rust 1.x can't necessarily be built with Rust 1.(x-1). EDIT: Nor can std for Rust 1.(x-1) be necessarily built by Rust 1.x. It's true that you don't have to force every contributor to upgrade every six weeks, but you do very likely need to have every contributor use the same version of Rust. (Which can be accomplished with a rust-toolchain file, as you mention.) The problem here is that if you don't do this upgrade whenever a new Rust release is made, you're just putting off that work to some other point. Maybe you do it every 12 weeks instead of 6 weeks, that would probably be okay. But I'd imagine waiting a year, for example, could be unpleasant.

sim7c00 4y ago

really interesting read, and nice to see people writing operating systems on rust and have also plus points besides grievances. particularly enjoyed you found rust sometimes spares you the 'damn i need to rewrite this entire thing' tour that C always hits me with :D. now i am more hopeful my re-write-the-entire-thing-in-rust was an ok'ish choice.

bunnie 4y ago
Took me a full year of questioning life choices before it felt worth it, but fearless refactoring is so nice. I may have trouble going back to C just for that.

ReactiveJelly 4y ago

> I wrote a small tool called `crate-scraper` which downloads the source package for every source specified in our Cargo.toml file, and stores them locally so we can have a snapshot of the code used to build a Xous release. I thought `cargo vendor` already did this? https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html > This cargo subcommand will vendor all crates.io and git dependencies for a project into the specified directory at <path>. After this command completes the vendor directory specified by <path> will contain all remote sources from dependencies specified. Maybe he doesn't want to depend on Cargo. Fair enough, it's a big program.

bunnie 4y ago
The big thing I wanted was the summary of all the build.rs files concatenated together so I wasn't spending lots of time grepping and searching for them (and possibly missing one). The script isn't that complicated... it actually uses an existing tool, cargo-download, to obtain the crates, and then a simple Python script searches for all the build.rs files and concatenation them into a builds.rs mega file. The other reason to give the tool its own repo is crate-scraper actually commits the crates back into git so we have a publicly accessible log of all the crates used in a given release by the actual build machine (in case the attack involved swapping out a crate version, but only for certain build environments, as a highly targeted supply chain attack is less likely to be noticed right away). It's more about leaving a public trail of breadcrumbs we can use to do forensics to try and pinpoint an attack in retrospect, and making it very public so that any attacker who cares about discretion or deniability has deal with this in their counter-threat model.
- woojoo666 4y ago
  Reminds me of your talk on supply chain security[1], I loved that one. [1]: https://www.youtube.com/watch?v=RqQhWitJ1As https://www.youtube.com/watch?v=RqQhWitJ1As
- epage 4y ago
  Don't forget about proc macros. If they don't, I wonder if one of the auditing commands should support drawing attention to build.rs and proc macros like this.

alexfromapex 4y ago

When Nightly is breaking no-std targets, is there not a way to pin a specific Nightly release to prevent that?

xobs 4y ago
You can do that! But you may run into a problem where one of the crates you use detects that you're using nightly, and then opts in to nightly-only features. Except it may be using features that are only available on the latest version of nightly, or an ancient version that you don't have, and there is no version that makes both your code and the dependent package happy. It's much better to just use stable. Then you're guaranteed to have forward compatibility, and you only have one place where you need to deal with the nightly weirdness.
steveklabnik 4y ago
There is, yes. You put a file in the root of your project with the specific version of Rust you want, and it’ll get picked up and used by the tooling.
vgel 4y ago
There is, but then you're pinning yourself to whatever bugs are in that nightly, and making the eventual upgrade that much worse.

_wldu 4y ago

Once rust stabilizes, I think it needs an ISO standard like C and C++ have. I can't see automobile manufactures using rust without one. One reason C and C++ are still widely used is due to this. When we are writing code that is expected to run for decades, having a corporate/community backed language is not sufficient. We need global standards and versions that we can rely on decades latter.

avgcorrection 4y ago
I think C caught on because it spread like a cancer through institutions like universities. Want to catch on? Be a virus. Not some gosh-darned international standard.
- pjmlp 4y ago
  Nice way to view UNIX, a virus.
rwaksmunski 4y ago
Lack of standards committee body making decisions is feature, not a bug. Car manufactures can stick with C.
- Avamander 4y ago
  Considering how "smart" cars are getting, no, they shouldn't.
pie_flavor 4y ago
What has the standard actually gotten C and C++? Basic features needed in every single code base like type punning on structures are standardly UB, while design-by-committee results in C++ feature hell. It doesn't get any harder to write a function exhibiting a bug just because there's a standard saying the function shouldn't have bugs in it. No matter what, you are trusting a compiler vendor that the code it compiles and the functions it links against don't have bugs. A standard is not a magic spell that creates better software through its incantation; it provides for multiple separate compiler vendors to be able to compile the same code the same way, which is a total fiction in C/C++, and not required for languages like Python or Lua. I view it as nothing more than the streetlight effect.

deleted 4y ago

[deleted]

bfrog 4y ago

Very cool, and it’s true Rust is dense. On the other hand C, the other typical option, either requires massive amounts of ancillary tooling and macros like Zephyr to get even close to doing as much at compile time. Those tools and macros add density and complexity. Arguably C++ is about equivalent with fewer pros over C and plenty of the cons of C still there along with some new ones. I appreciate the idea of trying to create a auditable OS for an MMU capable CPU, the reality is once you have feature you care about that becomes harder and harder it seems.

wiz21c 4y ago

FTA : "This is the point at which Rust’s very strict typing and borrow checker converts from a productivity liability into a productivity asset." that's what rust is about in my own experience. Especially with threads.

ModernMech 4y ago
Me too. A lot of people who try Rust encounter a very steep learning curve, and tend to question whether the borrow checker and strict typing is even worth it. For me, it's allowed me to build larger threaded and distributed systems than I've ever been able to before. I've tried to build such systems in C/C++ but I've never been able to make something that isn't incredibly brittle, and I've been writing in those languages for 25 years. For a long time I thought maybe I'm just a bad programmer. Rust changed all that. I'm kind of a bad programmer I guess, because Rust caught a lot of bad decisions I was making architecturally, and forced me to rewrite things to conform to the borrow checker. This is the point at which I've found many people give up Rust. They say to themselves "This is awful, I've written my program one way I'm used to, and now it looks like I have to completely rewrite it to make this stupid borrow checker happy. If I had written in C++ I'd be done by now!" But will you really be done? Because I had the same attitude and every time I went back to C++ I surely built something, but if it got too large it would be a sandcastle that would fall over at the slightest breeze. With Rust I feel like I'm making skyscrapers that could withstand an earthquake, and I actually am because the programs I've written have weathered some storms that would have washed my C++ code out to sea. Of course one can make stable, secure, performant systems in C++ and many other languages. But apparently I can't, and I need something like Rust to empower me. Someone else here said that Rust attracts people who want to feel powerful and smart by writing complicated code, but I like to write Rust code just to not feel inept!
epage 4y ago
I remember someone saying that "Rust skipped leg day", feeling that Rust was overly focused on the borrow checker while only solving a small number of problems. 1. I think its easy, especially for GC users, to forget that memory management is really about resource management. 2. The composability of features with the borrow checker is outstanding, like proper session types / locks or Send+Sync for safe use data with threads.

jvanderbot 4y ago

I loved this perspective from a hardware oriented engineer coming to appreciate the enormous complexity and difficulty in providing a stable and useful data structures and algorithms library as part of, say, rust std. Each complaint is valid, but some of it is (they admit) coming from a bit of naivete. They're surprised red black trees are included in the Linux kernel? why? They were surprised at how useful rust std and a good? data structure foundation was? why?

voidhorse 4y ago

I wholeheartedly agree that rust’s syntax is way noisier and uglier than I’d like, and it’s nice to see someone else raise the point seriously. People tend to act like syntax is an ancillary detail in a language, but actually it’s fundamental! It’s our direct interface into the language itself and if it’s painful to read and write the language won’t be pleasant to use, no matter how great it’s semantics may be. Beyond the line noise problem. I feel some of rust’s syntactic choices are confusing. For instance: let x = 2 Introduces a new name and binds it to the value 2 while if let Some(x) = y Is a shorthand for pattern matching. Meanwhile other matching structures have no need of “let” at all. Likewise this extends the semantics of what “if” means and also overloads “=“ (e.g, glancing at this, would you say equals is binding a value to a pattern, performing a Boolean check, or both?) Rust has a couple of one-off weird syntactical devices that have been introduced as shorthand that imo quickly increase the cognitive load required to read code because several structures and keywords are reused in slightly different ways to mean entirely different things. There are a lot of similar syntactic hoops around type signatures because they didn’t go with the old “type variables must be lowercase” rule which leads to subtle potential ambiguities in parsing T as a variable or proper type in some cases that thus forces additional syntax on the user. I also think there are too many ways to express equivalent things in Rust, which again leads to more cognitive overhead. Reading the current docs, I get the sense the language is becoming “write biased”. Whenever they introduce some syntactic shortcut the justification is to save typing and eliminate small amounts of repetition, which is great in theory but now we have N ways of writing and reading the same thing which quickly makes code hard to grok efficiently imo. This minor gripe comes with the big caveat that it remains probably the most interesting language to become vogue since Haskell.

avgcorrection 4y ago
Conservative Java has something similar with try-with-resource and the upcoming instanceof pattern matching.
irishsultan 4y ago
> For instance: > let x = 2 > Introduces a new name and binds it to the value 2 while > if let Some(x) = y > Is a shorthand for pattern matching. Both introduce a new name (x) and both pattern match, it's just that the pattern in let x = 2 is simply match anything and assign it the name x, you could just as well write let t@(x, y) = (2, 4); Which binds t to (2, 4), x to 2 and y to 4 and there it's perhaps more clear that normal let is pattern matching as much as if let is pattern matching.

ArdelleF 4y ago

We do a lot of Rust compilation exploration during the development of TiKV(github.com/tikv/tikv), a lot of interesting learnings ... https://en.pingcap.com/blog/rust-huge-compilation-units/ https://en.pingcap.com/blog/rust-huge-compilation-units/

SemanticStrengh 4y ago
thanks for maintaining jemalloc :)

fmakunbound 4y ago

> It’s 2022 after all, and transistors are cheap: why don’t all our microcontrollers feature page-level memory protection like their desktop counterparts? I always thought it was because of the added cost from increased design complexity. Is it something else?

riskable 4y ago
Haha, no: It's because if you put an MMU in a microcontroller it's not a microcontroller anymore! That makes it an "application processor" of which there are many tens of thousands to choose from these days. There's nothing stopping you from taking say, a Raspberry Pi 4 and using it as a bare metal device (no OS) just like an Arduino. Or taking that same chip (BCM2711) and putting it in your own board to do something similar. It just wouldn't be economical for that sort of purpose most of the time.
bunnie 4y ago
Secretly, I suspect the answer is market differentiation. You can charge a higher royalty for a CPU core that has an MMU, and bundling it into the low end stuff erodes margins. The complexity is real, but in a typical SoC the actual CPU core is maybe 10% of the area and tossing in an MMU impacts maybe 1-2% of the total chip area. I haven't seen the pricing sheets, but I suspect the much bigger cost is the higher royalty payment associated with instantiating the MMU.

SemanticStrengh 4y ago

Let me takes this opportunity to explain that among the many contraints of rust, it is the undertalked one about the absurd no cast promotion from smaller integer (e.g. a char) to a bigger integer that made me quit and save my sanity. Having to make explicit casts a dozen times per functions for basic manipulations of numbers on a grid (and the index type mismatch) is an insult to the developer intelligence. It seems some people are resilient and are able to write nonsensical parts of code repeatedly but for me, I can't tolerate it.

josephg 4y ago
I don’t mind a few “as usize” casts because usually you can cast once and be done with it. But the cast that kills me is this one: How do you add an unsigned and a signed number together in rust, in a way which is fast (no branches in release mode), correct and which panics in debug mode in the right places (if the addition over- or under-flows)? Nearly a year in to rust and I’m still stumped!
- steveklabnik 4y ago
  https://rust.godbolt.org/z/e377o5148 https://rust.godbolt.org/z/e377o5148 is the first thing I thought of. You didn't specify sizes, or if you wanted the result to be signed or unsigned, but "assume two's compliment wrapping in release and panic in debug on over/underflow" is the default behavior of +.
  - mjw1007 4y ago
    That fails the "panics in debug mode in the right places" requirement: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f242c49005c7386dfaae45d01b56dc95 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - steveklabnik 4y ago
      Oh duh, yeah, my bad. I was tweaking stuff around and lost that property. And seems like TryInto doesn't compile away entirely. Boo. You can write your own debug_assert! though: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ac1becf96a6f956a5bf8bf7551f2c253 https://play.rust-lang.org/?version=stable&mode=debug&editio... not as nice, but it does work. If you were doing this a lot you could macro it up, impl as a method on all the various types you want... a pain, but it is possible.

secondcoming 4y ago

This was a very interesting read. IMO the author underplays the visual ugliness of some Rust code. Programmers tend to look at code for hours a day for years, and so it should not be visually taxing to read and parse. This is why syntax highlighting exists, after all. But the gist I got from it is that Rust is really a very good static analyser.

bb010g 4y ago
I find Rust code rather pleasant to read.

gary17the 4y ago

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read :) If you think that Rust is dense and difficult to eyeball, please do try... Swift - purely for therapeutic reasons. But not the usual, trivial, educational-sample, evangelism-slideshow Swift, please, but real-world, advanced Swift with generics. All the unique language constructs to memorize, all the redundant syntactic sugar variations to recognize, all the special-purpose language features to understand, all the inconsistent keyword placement variations to observe, all the inferred complex types to foresee, etc. will make you suddenly want to quit being a programming linguist and instead become a nature-hugging florist and/or run back to Go, Python, or even friggin' LOGO. I'm tellin' ya. And, when considering Swift, we're not even talking about a systems programming language usable with, say, lightweight wearable hardware devices, but about a frankenstein created (almost) exclusively for writing GUIs on mobile devices usually more powerful than desktop workstations of yesteryear :). Rust is complex, but very good.

pphysch 4y ago
Interesting, I had no idea what I was missing out on. Conversation from last week: Me: "So what are you working on at $company?" Friend: "We're building a complete HVAC management system for all types of buildings, from hardware to software" Me: "Cool! What technologies are you building it on?" Friend: "Swift" Me: "...for like an iOS app to monitor the system?" Friend: "No, everything is written in Swift. The entire backend too." Me: "Interesting... Have you shipped anything yet?" Friend: "No but the founder is running a prototype in his house and we just secured another round of funding..." ** Is this a common thing?
- gary17the 4y ago
  Considering the speed of adoption of server-side Swift as well as the progress of Swift's support for Linux, I am guessing we are talking about some expert variation of the pump-and-dump investment technique here ;).

bilkow 4y ago

It looks like I'm on the minority here, but I generally like Rust's syntax and think it's pretty readable. Of course, when you use generics, lifetimes, closures, etc, all on the same line it can become hard to read. But on my experience on "high level" application code, it isn't usually like that. The hardest thing to grep at first for me, coming from python, was the :: for navigating namespaces/modules. I also find functional style a lot easier to read than Python, because of chaining (dot notation) and the closure syntax. Python: array = [1, 0, 2, 3] new_array = map( lambda x: x * 2, filter( lambda x: x != 0, array ) ) Rust: let array = [1, 0, 2, 3]; let new_vec: Vec<_> = array.into_iter() .filter(|&x| x != 0) .map(|x| x * 2) .collect(); I mean, I kind of agree to the criticism, specially when it comes to macros and lifetimes, but I also feel like that's more applicable for low level code or code that uses lots of features that just aren't available in e.g. C, Python or Go. Edit: Collected iterator into Vec

Too 4y ago
I want to like rust but the fact that there are replies with 9 different ways to write that loop posted here alone, and no consensus on which one is the idiomatic, is not a good sign.
rajman187 4y ago
minor point but your python code creates a generator here not an array, you'd have to wrap it in a `list()` to get the same data type and be able to for example assert its length (of course you can just iterate over the generator)
xigoi 4y ago
You can only do this chaining when everything happens to be a method. Compare to Nim or D, where you can chain arbitrary procedures like this.
klodolph 4y ago
There are people who write Python code like that, but it's an extreme minority. Here's the more likely way: array = [1, 0, 2, 3] new_array = [x * 2 for x in array if x != 0] Just as a matter of style, few Python programmers will use lambda outside something like this: array = [...] arry.sort(key=lambda ...)

StillBored 4y ago

" Yes, it is my fault for not being smart enough to parse the language’s syntax, but also, I do have other things to do with my life, like build hardware." and "Rust Is Powerful, but It Is Not Simple" among all the other points, should be enough to disqualify it for mainstream use. The core of most arguments against C++ boil down to those two points too. If a large percentage of the engineers working in the language have a problem understanding it, they are going to have a hard time proving that their aren't any unexpected side effects. Of which both C++ and rust seems to be full of, given the recent bug reports in rust and projects people are using it in. So, I'm still firmly in the camp that while there are better system programming languages than C, rust isn't one of them (hell even Pascal is probably better, at least it has length checked strings).

IshKebab 4y ago
> The core of most arguments against C++ boil down to those two points too. If a large percentage of the engineers working in the language have a problem understanding it, they are going to have a hard time proving that their aren't any unexpected side effects. That's true for C++ but not for Rust, because Rust will tell you if there's some kind of unexpected behaviour that you didn't think about, whereas C++ will allow UB or whatever without telling you. That's the big difference between (safe) Rust's complexity and C++'s complexity. They are both very complex, but in Rust it doesn't matter too much if you don't memorise the complexity (complicated lifetime rules, etc.) because it will just result in a compile error. Whereas in C++ you have to remember the rule of 3... no 5... etc. (that's a really simple example; don't think "I know the rule of 5; C++ is easy!").
- pjmlp 4y ago
  Not in unsafe code blocks, and plenty of people reach to them, even for stuff they shouldn't, like fake dependent types in Rust.
lawn 4y ago
C++ is one of the most used languages, and it does seem to me that Rust has enough momentum going for it to be a commonly used system programming language as well. I do agree with his points, but I don't think it's enough to disqualify it for mainstream use.

jmartin2683 4y ago

Rust is awesome. I’ve been in love since the moment I met it.

dgan 4y ago

> 100k LOC over two years Dude wrote more code per week than me in last 6 month at daily job

sydthrowaway 4y ago
Well, he quit Big Tech long ago, now actually builds things instead of phoning it in.

dimgl 4y ago

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read. > Rust Is Powerful, but It Is Not Simple This is exactly why I haven't gotten into Rust.

klysm 4y ago
What do you use instead?