23 ms·

Two Years with Rust

265 points by anotherevan 7y ago

jpz 7y ago
Is it just me and my 30" monitor, or is the font for this webpage extremely small?
- syrgian 7y ago
  It's somewhat small, for optimal reading I zoomed to 130%.
- nicoburns 7y ago
  It's small on 13" MacBook screen too. Turns out it's set to 12px!
- aliceryhl 7y ago
  It's not just you.
- Veen 7y ago
  Not just you. It's tiny. I also wish people would turn on hyphenation if they insist on justifying text on the web.
WilliamEdward 7y ago
A south african domain, but a blogger from seattle... you don't see that every day :)
- matdehaast 7y ago
  You don't but considering he works for AWS, he was probably a part of the Cape Town AWS team doing EC2 stuff before moving.
- nivertech 7y ago
  The EC2 project was started in Cape Town. Also Amazon's CTO has some links to South Africa (or maybe he is from Amsterdam). https://www.allthingsdistributed.com/ https://www.allthingsdistributed.com/
- mjlee 7y ago
  https://www.youtube.com/watch?v=KLxwhsJuZ44 https://www.youtube.com/watch?v=KLxwhsJuZ44 His accent is a mash of both of those!
- mjb 7y ago
  Hi, I'm the post author. As you guessed, I'm South African. I worked at Amazon in Cape Town in the early days of EC2, and live in Seattle now. A lot of core development on EC2 (and other AWS products) still happens in Cape Town.
rvz 7y ago
I would expect Rust to do well in these sorts of areas involving systems programming and low level development including projects like Firecracker. The features that are very compelling is that installation is painless, static linking is encouraged and used widely and its APIs aren't tied to any specific platform, thus is a true cross-platform language done right. It would be better to compare it to C++ rather than C since they both interface and surpass the complexity of the language. While the language is mature, the author fails to mention that most of the crates ecosystem is immature and some are unsafe. Especially in the domain the author is working in, there's a degree of risk in importing some crates which can compromise the safety of the project (use at your own risk). Cross-compilation is there in Rust, it requires downloading the toolchain for the specific platform and Go has it truly built-in, so I'll give them that one. Lastly, it may be possible to use a cross-platform GUI library like gtk-rs, but it isn't widely adopted unlike Qt, Electron and Flutter. The question around that is whether if Rust is suitable for that use-case? As many ideas and crates for Rust GUI development are coming, for now I'd say soon. The author is certainly bullish on Rust in general and in low-level development and so am I.
- Random_ernest 7y ago
  > The author is certainly bullish on Rust in general and in low-level development and so am I. While I share your sentiment, I've recently talked to about 5 people who write software for low-level, security relevant things in airplanes. Imho the best application for Rust one could think of. None of them had even heard of Rust. But this is highly anecdotal of course.
  - jksmith 7y ago
    But they aren't using Ada?
    - Random_ernest 7y ago
      They are mostly using C/C++.
      - 7y ago
twsted 7y ago
> It's been over 10 years since I last worked with C++ every day, and I'm nowhere near being a competent C++ programmer anymore. Part of that is because C++ has evolved, which is a very good thing. Part of it is because C++ is huge. From a decade away, it seems hard to be a competent part-time C++ programmer: you need to be fully immersed, or you'll never fit the whole thing in your head. This is really true. I have worked with C++ for 15/20 years, reading and studying everything I could. I've reached a good competence but every time I stopped for a while I immediately fell behind. C++ is a difficult beast.
- rtkaratekid 7y ago
  This is so true for almost everyone I’ve talked with. It’s almost like each release is its own language too. I’ve been programming in Rust recently, and didn’t realize how much I love it till I tried doing something in C++ again. I will say I still really enjoy the simplicity of C, but the guarantees of Rust are really hard to beat.
  - skocznymroczny 7y ago
    I am kind of in a similar camp with D. I just can't go back to C++, no matter what.
    - pjmlp 7y ago
      Me with managed compiled languages. Still need to go back to C++ every now and then, unfortunately not all interesting libraries have bindings available.
  - BubRoss 7y ago
    C++11 you could say that about, but I don't think any other revision is anywhere close to needing that much work to get up to speed. Ownership semantics mean that many times there are much more elegant ways of doing almost everything. In later versions, not using the latest features is not such a big deal, you don't miss out on the same leap forward.
- 7y ago
jksmith 7y ago
" I've also found that programs seem more likely to work on their first run, but haven't made any effort to quantify that." Had the same experience with Modula-2, once I got all the compile errors cleared. I think there is a real need for the current generation of business programmers to start focusing more on safety and rigor as they transition into IoT. For instance, I don't see most programmers I've worked with capable or will to use enough rigor to make autonomous cars safe. All these programmers have generally been slinging java for years, without even much effort to exposed themselves to other languages unless there is a business requirement to do so. So the concern I have with Rust (as a newbie) is it isn't consumable enough to have it's value adopted by most business programmers out there, and I've wondered if Ada would serve that role better because it seems generally easier to grok percentage wise.
- batter 7y ago
  Whatever bad things you see in this world - it's done by java developers. Go, scala, kotlin, JavaScript, python developers would never do anything as bad as java developers. I see that a lot of people stick to that mantra.
  - yaktubi 7y ago
    Huh, JavaScript developers? They do something bad by default: loop in a million dependencies from 3rd party modules!
  - jksmith 7y ago
    Not suggesting that it's the language. It's the language that is popular for large-organization commodity programming. Agency people who want well paying jobs with not necessarily a lot of interest in software development itself.
  - barrkel 7y ago
    Java is used on projects with more scale (business process complexity) than the other languages you list, though. There are reasons for the things that are done in the Java community. We might not like the result, but there are reasons, and most of them have to do with scale and process at scale. There are other ways to build out scale, but they may require different kinds of organizations to build them, with a different mix of people. Big Java projects tend to be structured to make efficient use of developers with 0-5 years of experience, because at scale those developers are reasonably easy to hire. Those developers need to colour inside the lines (=> framework, we'll call you, follow the patterns, don't invent abstractions), create code which can be tested in isolation (=> inversion of control), and have their output glued into position (=> dependency injection) in a much larger solution. Most of the structure of the Java ecosystem follows from this.
modernerd 7y ago
Everyone always seems so positive about Rust. I'd love to try it for some personal projects. Are there any downsides beyond the niggle the author mentioned? Are compilation speeds an issue for anyone? Is there much that can be done to improve this? (Both in Rust itself and at a developer level; presumably a faster dev machine helps?)
- the8472 7y ago
  > Are compilation speeds an issue for anyone? It really depends on what you're doing. An incremental change on a small project can debug-build in seconds on a beefy machine, syntax-check is even faster. If you're working on rust itself and do a full 2-stage rebuild to benchmark something and upstream changed the llvm revision in the meantime and you do that on a laptop it can take more than an hour.
- dpbriggs 7y ago
  If you're trying to do something very specific that doesn't align with Rust's ownership/memory model it can be quite challenging. For example, I wanted to make a skiplist library with features not present in other crates. Trying to go the totally safe route was a cognitive overload, and trying to express complex invariants in that form was painful. Completely doable though, if you're willing to learn it all. I eventually settled on a much more unsafe, but very granular approach that's probably not going to get a good rating with cargo-crev.
  - probably_wrong 7y ago
    I want to echo this point. I tried to write an implementation of an automata-based algorithm in Rust, and my main takeaway was that Rust really doesn't like linked lists. There is currently a popular book [1] that focuses entirely on how one would write such a thing. That's not to say that it can't be done - I believe there's a crate implementing the same algorithm I was going for. But my main point is: if you see "systems programming" and think "oh, like C", then you are going to have a difficult time. [1] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
bitfield 7y ago
"I want off Mr Rust's wild ride."
krebs_liebhaber 7y ago
This is only tangentially related to the article, but why does any discussion of Rust and/or Go asymptotically approach "RUST VERSUS GO RUST VERSUS GO", or at least have everyone and their grandma chip in on which one they prefer (like this very post)? I'll admit that I only have experience with the former, but they seem like totally different beasts to me, intended for very different domains / target audiences. I figured that the holy war would be between Rust and the other trendy systems languages (Nim, Zig, Crystal) or between Go and other Web-oriented / glue languages (Java, Python, Perl, et cetera).
- deleted 7y ago
  [deleted]
- lmkg 7y ago
  It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages." As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck. The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense. There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)
  - steveklabnik 7y ago
    While there's a lot of truth in this comment, at the same time, the domains are wide enough that there are a lot of similar usages, and teams that decide to use one, the other, or both.
    - umanwizard 7y ago
      True, but you could say the same of nearly any pair of general-purpose languages. Even Python and C overlap to some non-trivial extent. Go and Rust certainly have overlap, but I'm not sure I'd agree that they have an unusually high level of overlap. I think the closest language to Rust in niche is, by far, C++. I'm surprised to see it compared less often to that than to Go.
tannhaeuser 7y ago
Seeing as the prime (and arguably only essential ^1) use cases for C are 1. O/S kernels and drivers, 2. embedded code for tiny microcontrollers, 3. language interpreters/runtimes and JITters, 4. bootstrap compilers, 5. portable command-line utilities, 6. low-level/mixed asm routines for performance, and 7. the large body of legacy apps of course, are there any examples for successful implementations for these categories in Rust? I'd imagine developing a nontrivial language runtime using Rust's memory model could be hard or impossible to do performantly. But that is or was the mainstay of C programming on Unix - implementing higher-level languages such as shell or awk. ^1: This is of course opinionated, but my reasoning for not including application code, and in particular long-lived evented or multithreaded app servers is that I personally think these are beyond C's memory management capabilities (even if you get malloc/free 100% right, there's still the problem of memory fragmentation) and are basically erratic outcomes of 1990's multithreading code originating from corouting in GUI programs
- steveklabnik 7y ago
  > are there any examples for successful implementations for these categories in Rust? Depends on how you define "successful", I'll toss some things in. This won't be comprehensive. 1. O/S kernels and drivers, Amazon has multiple projects in this space: Firecracker, Bottlerocket. So does Google: ChromeOS, Fuchsia. Kernel maintainers have said that they would accept non-essential drivers in Rust, but they want some examples first. 2. embedded code for tiny microcontrollers, Tons of stuff here. Multiple RTOSes like Tock and RTFM. Lots of little projects. One of the first Rust-only consultancies does a lot of embedded contracts. 3. language interpreters/runtimes and JITters, Most of the languages that have existed are bigger than toys, but don't have large user bases. Gluon and Dyon are two examples. JITs exist but aren't really "production", Cranelift has a JIT for example. 4. bootstrap compilers, rustc is written in Rust (it does use LLVM though) 5. portable command-line utilities, Tons and tons and tons. ripgrep is the most famous. On the "portable" end, I'm a Windows user, and most things I try Just Work, though they may print out funny paths sometimes. (if you escape a native\windows\path you'll get a native\\windows\\path since \ ends up getting escaped. Only a display issue though, things still work just fine.) 6. low-level/mixed asm routines for performance, This isn't "for performance" but I like https://crates.io/crates/x86 https://crates.io/crates/x86 as an example here. Inline asm isn't stable yet, but we're getting pretty close, it seems. 7. and the large body of legacy apps of course, It's not clear to me what this actually means.
abinaya_codes 7y ago
Recently we've added support to curate the Rust programming remote jobs at Remote Leaf[1]. We've seen a some surge in the Rust remote jobs in the recent months. Maybe because it's being accepted by a wide variety of developers and also hiring companies started using it? [1] - https://remoteleaf.com https://remoteleaf.com
herodotus 7y ago
Here is an historical note for those who might be interested. In 1979 I did a Post-doc with Rod Burstall. I helped implement the programming language Hope, which was the first functional programming language to use pattern-matching in function definitions. The implementation was written in an older language called POP-2. Robin Milner and his group were at the the time working on LCF and ML, and they eventually incorporated Burstall's pattern ideas. Eventually, I recall there was a decision within the UK functional programming community to consolidate their efforts into what became Haskell. And of course we see how much Haskell has influenced the newest crop of imperative languages. It is interesting (to me) to compare factorial in Rust with factorial in Hope: Rust: fn factorial(i: u64) -> u64 { match I { 0 => 1, n => n * factorial(n-1) } } Hope: dec factorial : num -> num; --- factorial 0 <= 1; --- factorial n <= n* factorial(n-1); Note that, in Hope (unlike its own inspiration, Prolog, and, I think unlike Rust), the order of the rules does not matter: the most specific pattern takes precedence. Hope was primitive with respect to types, and did not use Milner's type inferrencing ideas. I don't think Burstall ever intended it to be a "real" programming language. When I left Edinburgh, Don Sanella took over from me, so I was not involved in writing the paper about Hope, but my contribution is acknowledged. I implemented the pattern matching code, and the idea of pattern compilation occurred to me. I remember showing it to Rod. He freaked out at first, but after about a five minute harangue, the penny dropped, and I remember him saying "clever Michael", "clever Michael" in his charming way.
- steveklabnik 7y ago
  Very cool, thank you for this history! > I think unlike Rust Yes, this is correct: Rust looks at patterns in order, top to bottom. Incidentally, some folks have asked for a syntax closer to Hope (and Haskell, and others) https://github.com/rust-lang/rfcs/pull/1564 https://github.com/rust-lang/rfcs/pull/1564 fn factorial(0: u64) -> u64 { 1 } fn factorial(n: u64) -> u64 { n * factorial(n - 1) } I doubt this will ever happen, though.
  - hota_mazi 7y ago
    I really hope this doesn't happen. I've never understood the infatuation for this Haskell type syntax where you need to repeat the name of the function for each and every single match case. It's so needlessly verbose.
BooneJS 7y ago
I’ve been immersed in C++ at the office for over a year. It is a big language, but like all big languages one ends up finding the parts of it they need to use and get really good at it. The more languages I learn, the more I dislike language zealots. They’re great to leverage when learning, but they’re blinded by their own opinions to see that they’re making mountains out molehills.
- 6gvONxR4sf7o 7y ago
  I think part of the tension is that some people are in it for a better hammer, while others are in it as an end unto itself. PL is just plain interesting as a hobby interest.
eternalban 7y ago
I find it interesting that both Go and Rust, in practice, step on one of their relative foundational concepts. (2010: https://blog.golang.org/codelab-share https://blog.golang.org/codelab-share, for Go, and I suppose don't need to cite "safe system code" for Rust). For example, Go community could have stuck to their guns about building server side concurrent code only using channels and value objects, performance impact be damned, and we would not have high performance server code written in Go (using locks and shared memory). And as OP points out, "system level" code written in Rust likely will have (possibly opaque) unsafe code segments. Intent here isn't to rag on either language. It's more musing out loud about the impact of conceptual consistency in course of development on product success: is it a (practical) mistake to insist on it? Based on Go and Rust teams' decisions to date, it seems it pays to be pragmatic. (Or are we simply throwing the towel in too early?)
- steveklabnik 7y ago
  I'm not entirely sure. I think this line of inquiry is interesting, but I'm also not entirely sure that you're declaring Rust's original principles correctly. That is, the safe/unsafe dichotomy was always there. It's impossible to build real systems without it, and so I think that's why people gloss over it a bit. See slide 16 of http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf, the original presentation of Rust to the world.
  - eternalban 7y ago
    (I ~think Go also always had facilities for sharing memory as well. Don't remember.) The issue appears to be: - "It's impossible to build real systems" according to pure conceptual CS models, - or, our conceptual models are not sufficiently strong and expressive, and fall short bridging the gap between symbolic and physical realm, and these gaps manifest in code. - or that it's impossible to practically realize more complex conceptual models, and that even if possible, they would not be accessible to the general programming community. - or we're building on poor legacy foundations which will dog us until we finally rethink approaches from ground up. (Possibly those ORs are all ANDs.)
  - 7y ago
metreo 7y ago
I've had a much shorter frame of time with Rust and I have to say I really enjoy the learning experience, and that is to say that learning the language is a pleasurable experience. Other languages with larger more established communities are often unable to replicate this same feeling of inclusion and value as a member of the ecosystem of contributors.
manifoldgeo 7y ago
"Static linking and cross-compiling are built-in." I found out that the above is not completely true. According to the official Rust documentation, only Rust dependencies are statically linked by default. But compiled Rust programs depend on more than Rust dependencies, as they also use shared C libraries. The capability is built-in, but it's definitely not straightforward. "Pure-Rust dependencies are statically linked by default so you can use created binaries and libraries without installing Rust everywhere. By contrast, native libraries (e.g. libc and libm) are usually dynamically linked..."[1]. I did a small experiment to make a from-scratch Docker container with no dependencies and a single Rust binary and found out that I could not do that without jumping through some hoops[2]. I had to have it include a minimal implementation of libc called "musl". See my write-up here[3]. If anyone has found another way around this I would love to hear about it and make a correction in my write-up. References: [1]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#static-linking https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#... [2]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#linux https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#... [3]: https://bxbrenden.github.io https://bxbrenden.github.io
- kouteiheika 7y ago
  To be honest you're overcomplicating the whole thing by involving Docker in the build process. Assuming you have Rust installed (which is only one `apt-get` or `curl` + `sh` invocation away) and your project does not depend on any external C libraries (except libc) then building a fully-static Linux executable is as simple as those two commands: rustup target add x86_64-unknown-linux-musl cargo build --release --target=x86_64-unknown-linux-musl There are no hoops to jump through here. I can totally understand using Docker for something which can be a pain to setup a toolchain for or install all of the dependencies for, but for the Rust compiler I see very little reason for running it inside of a container except in a very few very niche cases.
  - staticassertion 7y ago
    At one point docker was the only way to do this, I think. So if you start searching the internet for how to do static linking with musl you're very likely to find links to the docker'd approach.
nrclark 7y ago
I see a lot of people comparing Rust favorably against C++, largely due to C++'s complexity. And yet at the same time, the Rust dev team are changing and expanding the language very quickly. Is there any plan to feature-freeze Rust? Otherwise it'll just become C++ 2.0 - a giant mass of features that are progressively designed to replace each other, until the language becomes too complex for any one person to master.
- steveklabnik 7y ago
  There is no plan to do that, but as time goes on, the bar gets higher and higher. We are not changing the language in backwards-incompatible ways.
  - nrclark 7y ago
    Good to know. Worth pointing out that the C++ standards committee also almost never breaks backwards-compatibility. Instead, they just introduce The New Way (and then The Old Way becomes just one more trap). If you're in a position to affect this for Rust, it's worth thinking about. Give the documentation and libraries a few years to catch up, so that we don't have to chase a moving target. Maybe focus more on compiler and toolchain optimizations, and less on language features. It's a little rough to play in an ecosystem where the language itself effectively has a nightly/unstable variant.
    - steveklabnik 7y ago
      We are all very much aware :) That's very much been the theme of 2019 and 2020. 2019 really only saw the introduction of async/await as a new language feature. Almost all other additions were smaller things, like "this feature expanded a bit" or "this edge case is no longer an edge case." There was only one instance of something straight-up replacing the old thing; mem::uninitialized by MaybeUninit.
- nicoburns 7y ago
  Notably almost none of Rust's new features are replacing old ones. Most of them are either opening up new capabilities (e.g. async-await), or making existing mechanisms more general/flexible (e.g. const generics, GATs). It might accumulate cruft eventually, but I think it's at an inherent advantage over C++ due to its heavy functional influence, which is all based on math / PL theory. On the other hand C has always been a quick-and-dirty language, and C++ inherited a lot of that legacy. The macro system also helps a lot, as features can be prototyped as macros, and only stabilised once the design has been iterated and used. More niche features can stay as macros in 3rd party libraries.
rstuart4133 7y ago
> The biggest long-term issue in my mind is unsafe I'd say that, but for different reasons. It's depressing how often you have to use unsafe. I would not mind if it was hidden in libraries tested within an inch of their life 99.9% of the time, but it didn't work out that way for me. Recursively defined data structures like trees were just a nightmare to do without unsafe's. I thought that was perhaps because I just sucked at Rust, but then I listened to a talk from one of the Mozilla core devs working on Servo. Their code had more unsafe's than mine. The amount of parallelism they were trying to get was extreme of course, so it wasn't really much of a comparison. It made me feel much better all the same.

Two Years with Rust

265 points by anotherevan 7y ago

jpz 7y ago

Is it just me and my 30" monitor, or is the font for this webpage extremely small?

syrgian 7y ago
It's somewhat small, for optimal reading I zoomed to 130%.
nicoburns 7y ago
It's small on 13" MacBook screen too. Turns out it's set to 12px!
aliceryhl 7y ago
It's not just you.
Veen 7y ago
Not just you. It's tiny. I also wish people would turn on hyphenation if they insist on justifying text on the web.

WilliamEdward 7y ago

A south african domain, but a blogger from seattle... you don't see that every day :)

matdehaast 7y ago
You don't but considering he works for AWS, he was probably a part of the Cape Town AWS team doing EC2 stuff before moving.
nivertech 7y ago
The EC2 project was started in Cape Town. Also Amazon's CTO has some links to South Africa (or maybe he is from Amsterdam). https://www.allthingsdistributed.com/ https://www.allthingsdistributed.com/
mjlee 7y ago
https://www.youtube.com/watch?v=KLxwhsJuZ44 https://www.youtube.com/watch?v=KLxwhsJuZ44 His accent is a mash of both of those!
mjb 7y ago
Hi, I'm the post author. As you guessed, I'm South African. I worked at Amazon in Cape Town in the early days of EC2, and live in Seattle now. A lot of core development on EC2 (and other AWS products) still happens in Cape Town.

rvz 7y ago

I would expect Rust to do well in these sorts of areas involving systems programming and low level development including projects like Firecracker. The features that are very compelling is that installation is painless, static linking is encouraged and used widely and its APIs aren't tied to any specific platform, thus is a true cross-platform language done right. It would be better to compare it to C++ rather than C since they both interface and surpass the complexity of the language. While the language is mature, the author fails to mention that most of the crates ecosystem is immature and some are unsafe. Especially in the domain the author is working in, there's a degree of risk in importing some crates which can compromise the safety of the project (use at your own risk). Cross-compilation is there in Rust, it requires downloading the toolchain for the specific platform and Go has it truly built-in, so I'll give them that one. Lastly, it may be possible to use a cross-platform GUI library like gtk-rs, but it isn't widely adopted unlike Qt, Electron and Flutter. The question around that is whether if Rust is suitable for that use-case? As many ideas and crates for Rust GUI development are coming, for now I'd say soon. The author is certainly bullish on Rust in general and in low-level development and so am I.

Random_ernest 7y ago
> The author is certainly bullish on Rust in general and in low-level development and so am I. While I share your sentiment, I've recently talked to about 5 people who write software for low-level, security relevant things in airplanes. Imho the best application for Rust one could think of. None of them had even heard of Rust. But this is highly anecdotal of course.
- jksmith 7y ago
  But they aren't using Ada?
  - Random_ernest 7y ago
    They are mostly using C/C++.
    - 7y ago

twsted 7y ago

> It's been over 10 years since I last worked with C++ every day, and I'm nowhere near being a competent C++ programmer anymore. Part of that is because C++ has evolved, which is a very good thing. Part of it is because C++ is huge. From a decade away, it seems hard to be a competent part-time C++ programmer: you need to be fully immersed, or you'll never fit the whole thing in your head. This is really true. I have worked with C++ for 15/20 years, reading and studying everything I could. I've reached a good competence but every time I stopped for a while I immediately fell behind. C++ is a difficult beast.

rtkaratekid 7y ago
This is so true for almost everyone I’ve talked with. It’s almost like each release is its own language too. I’ve been programming in Rust recently, and didn’t realize how much I love it till I tried doing something in C++ again. I will say I still really enjoy the simplicity of C, but the guarantees of Rust are really hard to beat.
- skocznymroczny 7y ago
  I am kind of in a similar camp with D. I just can't go back to C++, no matter what.
  - pjmlp 7y ago
    Me with managed compiled languages. Still need to go back to C++ every now and then, unfortunately not all interesting libraries have bindings available.
- BubRoss 7y ago
  C++11 you could say that about, but I don't think any other revision is anywhere close to needing that much work to get up to speed. Ownership semantics mean that many times there are much more elegant ways of doing almost everything. In later versions, not using the latest features is not such a big deal, you don't miss out on the same leap forward.
7y ago

jksmith 7y ago

" I've also found that programs seem more likely to work on their first run, but haven't made any effort to quantify that." Had the same experience with Modula-2, once I got all the compile errors cleared. I think there is a real need for the current generation of business programmers to start focusing more on safety and rigor as they transition into IoT. For instance, I don't see most programmers I've worked with capable or will to use enough rigor to make autonomous cars safe. All these programmers have generally been slinging java for years, without even much effort to exposed themselves to other languages unless there is a business requirement to do so. So the concern I have with Rust (as a newbie) is it isn't consumable enough to have it's value adopted by most business programmers out there, and I've wondered if Ada would serve that role better because it seems generally easier to grok percentage wise.

batter 7y ago
Whatever bad things you see in this world - it's done by java developers. Go, scala, kotlin, JavaScript, python developers would never do anything as bad as java developers. I see that a lot of people stick to that mantra.
- yaktubi 7y ago
  Huh, JavaScript developers? They do something bad by default: loop in a million dependencies from 3rd party modules!
- jksmith 7y ago
  Not suggesting that it's the language. It's the language that is popular for large-organization commodity programming. Agency people who want well paying jobs with not necessarily a lot of interest in software development itself.
- barrkel 7y ago
  Java is used on projects with more scale (business process complexity) than the other languages you list, though. There are reasons for the things that are done in the Java community. We might not like the result, but there are reasons, and most of them have to do with scale and process at scale. There are other ways to build out scale, but they may require different kinds of organizations to build them, with a different mix of people. Big Java projects tend to be structured to make efficient use of developers with 0-5 years of experience, because at scale those developers are reasonably easy to hire. Those developers need to colour inside the lines (=> framework, we'll call you, follow the patterns, don't invent abstractions), create code which can be tested in isolation (=> inversion of control), and have their output glued into position (=> dependency injection) in a much larger solution. Most of the structure of the Java ecosystem follows from this.

modernerd 7y ago

Everyone always seems so positive about Rust. I'd love to try it for some personal projects. Are there any downsides beyond the niggle the author mentioned? Are compilation speeds an issue for anyone? Is there much that can be done to improve this? (Both in Rust itself and at a developer level; presumably a faster dev machine helps?)

the8472 7y ago
> Are compilation speeds an issue for anyone? It really depends on what you're doing. An incremental change on a small project can debug-build in seconds on a beefy machine, syntax-check is even faster. If you're working on rust itself and do a full 2-stage rebuild to benchmark something and upstream changed the llvm revision in the meantime and you do that on a laptop it can take more than an hour.
dpbriggs 7y ago
If you're trying to do something very specific that doesn't align with Rust's ownership/memory model it can be quite challenging. For example, I wanted to make a skiplist library with features not present in other crates. Trying to go the totally safe route was a cognitive overload, and trying to express complex invariants in that form was painful. Completely doable though, if you're willing to learn it all. I eventually settled on a much more unsafe, but very granular approach that's probably not going to get a good rating with cargo-crev.
- probably_wrong 7y ago
  I want to echo this point. I tried to write an implementation of an automata-based algorithm in Rust, and my main takeaway was that Rust really doesn't like linked lists. There is currently a popular book [1] that focuses entirely on how one would write such a thing. That's not to say that it can't be done - I believe there's a crate implementing the same algorithm I was going for. But my main point is: if you see "systems programming" and think "oh, like C", then you are going to have a difficult time. [1] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/

bitfield 7y ago

"I want off Mr Rust's wild ride."

krebs_liebhaber 7y ago

This is only tangentially related to the article, but why does any discussion of Rust and/or Go asymptotically approach "RUST VERSUS GO RUST VERSUS GO", or at least have everyone and their grandma chip in on which one they prefer (like this very post)? I'll admit that I only have experience with the former, but they seem like totally different beasts to me, intended for very different domains / target audiences. I figured that the holy war would be between Rust and the other trendy systems languages (Nim, Zig, Crystal) or between Go and other Web-oriented / glue languages (Java, Python, Perl, et cetera).

deleted 7y ago
[deleted]
lmkg 7y ago
It's an accident of history and messaging. They were both publicly announced at the same time, and both described themselves as "systems programming languages." As it turns out, the two languages have entirely different ideas of what "systems programming" means. And Go was announced very close to its 1.0 launch while Rust was announced very, very early in its development cycle. So in reality they actually align neither in timing, nor in target domain. Still, the initial contrast seems to have stuck. The only real overlap is that both deign to be C successors. But in such different ways that the head-to-head comparisons make little sense. There's also the perception that they're the only recently-created languages that have gained any real traction. You don't see nearly the ink spilt on Nim or Zig as you do on Rust or Go. So there's maybe some sibling rivalry there. (In this vein, I occasionally see comparisons of Rust vs Swift.)
- steveklabnik 7y ago
  While there's a lot of truth in this comment, at the same time, the domains are wide enough that there are a lot of similar usages, and teams that decide to use one, the other, or both.
  - umanwizard 7y ago
    True, but you could say the same of nearly any pair of general-purpose languages. Even Python and C overlap to some non-trivial extent. Go and Rust certainly have overlap, but I'm not sure I'd agree that they have an unusually high level of overlap. I think the closest language to Rust in niche is, by far, C++. I'm surprised to see it compared less often to that than to Go.

tannhaeuser 7y ago

Seeing as the prime (and arguably only essential ^1) use cases for C are 1. O/S kernels and drivers, 2. embedded code for tiny microcontrollers, 3. language interpreters/runtimes and JITters, 4. bootstrap compilers, 5. portable command-line utilities, 6. low-level/mixed asm routines for performance, and 7. the large body of legacy apps of course, are there any examples for successful implementations for these categories in Rust? I'd imagine developing a nontrivial language runtime using Rust's memory model could be hard or impossible to do performantly. But that is or was the mainstay of C programming on Unix - implementing higher-level languages such as shell or awk. ^1: This is of course opinionated, but my reasoning for not including application code, and in particular long-lived evented or multithreaded app servers is that I personally think these are beyond C's memory management capabilities (even if you get malloc/free 100% right, there's still the problem of memory fragmentation) and are basically erratic outcomes of 1990's multithreading code originating from corouting in GUI programs

steveklabnik 7y ago
> are there any examples for successful implementations for these categories in Rust? Depends on how you define "successful", I'll toss some things in. This won't be comprehensive. 1. O/S kernels and drivers, Amazon has multiple projects in this space: Firecracker, Bottlerocket. So does Google: ChromeOS, Fuchsia. Kernel maintainers have said that they would accept non-essential drivers in Rust, but they want some examples first. 2. embedded code for tiny microcontrollers, Tons of stuff here. Multiple RTOSes like Tock and RTFM. Lots of little projects. One of the first Rust-only consultancies does a lot of embedded contracts. 3. language interpreters/runtimes and JITters, Most of the languages that have existed are bigger than toys, but don't have large user bases. Gluon and Dyon are two examples. JITs exist but aren't really "production", Cranelift has a JIT for example. 4. bootstrap compilers, rustc is written in Rust (it does use LLVM though) 5. portable command-line utilities, Tons and tons and tons. ripgrep is the most famous. On the "portable" end, I'm a Windows user, and most things I try Just Work, though they may print out funny paths sometimes. (if you escape a native\windows\path you'll get a native\\windows\\path since \ ends up getting escaped. Only a display issue though, things still work just fine.) 6. low-level/mixed asm routines for performance, This isn't "for performance" but I like https://crates.io/crates/x86 https://crates.io/crates/x86 as an example here. Inline asm isn't stable yet, but we're getting pretty close, it seems. 7. and the large body of legacy apps of course, It's not clear to me what this actually means.

abinaya_codes 7y ago

Recently we've added support to curate the Rust programming remote jobs at Remote Leaf[1]. We've seen a some surge in the Rust remote jobs in the recent months. Maybe because it's being accepted by a wide variety of developers and also hiring companies started using it? [1] - https://remoteleaf.com https://remoteleaf.com

herodotus 7y ago

Here is an historical note for those who might be interested. In 1979 I did a Post-doc with Rod Burstall. I helped implement the programming language Hope, which was the first functional programming language to use pattern-matching in function definitions. The implementation was written in an older language called POP-2. Robin Milner and his group were at the the time working on LCF and ML, and they eventually incorporated Burstall's pattern ideas. Eventually, I recall there was a decision within the UK functional programming community to consolidate their efforts into what became Haskell. And of course we see how much Haskell has influenced the newest crop of imperative languages. It is interesting (to me) to compare factorial in Rust with factorial in Hope: Rust: fn factorial(i: u64) -> u64 { match I { 0 => 1, n => n * factorial(n-1) } } Hope: dec factorial : num -> num; --- factorial 0 <= 1; --- factorial n <= n* factorial(n-1); Note that, in Hope (unlike its own inspiration, Prolog, and, I think unlike Rust), the order of the rules does not matter: the most specific pattern takes precedence. Hope was primitive with respect to types, and did not use Milner's type inferrencing ideas. I don't think Burstall ever intended it to be a "real" programming language. When I left Edinburgh, Don Sanella took over from me, so I was not involved in writing the paper about Hope, but my contribution is acknowledged. I implemented the pattern matching code, and the idea of pattern compilation occurred to me. I remember showing it to Rod. He freaked out at first, but after about a five minute harangue, the penny dropped, and I remember him saying "clever Michael", "clever Michael" in his charming way.

steveklabnik 7y ago
Very cool, thank you for this history! > I think unlike Rust Yes, this is correct: Rust looks at patterns in order, top to bottom. Incidentally, some folks have asked for a syntax closer to Hope (and Haskell, and others) https://github.com/rust-lang/rfcs/pull/1564 https://github.com/rust-lang/rfcs/pull/1564 fn factorial(0: u64) -> u64 { 1 } fn factorial(n: u64) -> u64 { n * factorial(n - 1) } I doubt this will ever happen, though.
- hota_mazi 7y ago
  I really hope this doesn't happen. I've never understood the infatuation for this Haskell type syntax where you need to repeat the name of the function for each and every single match case. It's so needlessly verbose.

BooneJS 7y ago

I’ve been immersed in C++ at the office for over a year. It is a big language, but like all big languages one ends up finding the parts of it they need to use and get really good at it. The more languages I learn, the more I dislike language zealots. They’re great to leverage when learning, but they’re blinded by their own opinions to see that they’re making mountains out molehills.

6gvONxR4sf7o 7y ago
I think part of the tension is that some people are in it for a better hammer, while others are in it as an end unto itself. PL is just plain interesting as a hobby interest.

eternalban 7y ago

I find it interesting that both Go and Rust, in practice, step on one of their relative foundational concepts. (2010: https://blog.golang.org/codelab-share https://blog.golang.org/codelab-share, for Go, and I suppose don't need to cite "safe system code" for Rust). For example, Go community could have stuck to their guns about building server side concurrent code only using channels and value objects, performance impact be damned, and we would not have high performance server code written in Go (using locks and shared memory). And as OP points out, "system level" code written in Rust likely will have (possibly opaque) unsafe code segments. Intent here isn't to rag on either language. It's more musing out loud about the impact of conceptual consistency in course of development on product success: is it a (practical) mistake to insist on it? Based on Go and Rust teams' decisions to date, it seems it pays to be pragmatic. (Or are we simply throwing the towel in too early?)

steveklabnik 7y ago
I'm not entirely sure. I think this line of inquiry is interesting, but I'm also not entirely sure that you're declaring Rust's original principles correctly. That is, the safe/unsafe dichotomy was always there. It's impossible to build real systems without it, and so I think that's why people gloss over it a bit. See slide 16 of http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf, the original presentation of Rust to the world.
- eternalban 7y ago
  (I ~think Go also always had facilities for sharing memory as well. Don't remember.) The issue appears to be: - "It's impossible to build real systems" according to pure conceptual CS models, - or, our conceptual models are not sufficiently strong and expressive, and fall short bridging the gap between symbolic and physical realm, and these gaps manifest in code. - or that it's impossible to practically realize more complex conceptual models, and that even if possible, they would not be accessible to the general programming community. - or we're building on poor legacy foundations which will dog us until we finally rethink approaches from ground up. (Possibly those ORs are all ANDs.)
- 7y ago

metreo 7y ago

I've had a much shorter frame of time with Rust and I have to say I really enjoy the learning experience, and that is to say that learning the language is a pleasurable experience. Other languages with larger more established communities are often unable to replicate this same feeling of inclusion and value as a member of the ecosystem of contributors.

manifoldgeo 7y ago

"Static linking and cross-compiling are built-in." I found out that the above is not completely true. According to the official Rust documentation, only Rust dependencies are statically linked by default. But compiled Rust programs depend on more than Rust dependencies, as they also use shared C libraries. The capability is built-in, but it's definitely not straightforward. "Pure-Rust dependencies are statically linked by default so you can use created binaries and libraries without installing Rust everywhere. By contrast, native libraries (e.g. libc and libm) are usually dynamically linked..."[1]. I did a small experiment to make a from-scratch Docker container with no dependencies and a single Rust binary and found out that I could not do that without jumping through some hoops[2]. I had to have it include a minimal implementation of libc called "musl". See my write-up here[3]. If anyone has found another way around this I would love to hear about it and make a correction in my write-up. References: [1]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#static-linking https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#... [2]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#linux https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#... [3]: https://bxbrenden.github.io https://bxbrenden.github.io

kouteiheika 7y ago
To be honest you're overcomplicating the whole thing by involving Docker in the build process. Assuming you have Rust installed (which is only one `apt-get` or `curl` + `sh` invocation away) and your project does not depend on any external C libraries (except libc) then building a fully-static Linux executable is as simple as those two commands: rustup target add x86_64-unknown-linux-musl cargo build --release --target=x86_64-unknown-linux-musl There are no hoops to jump through here. I can totally understand using Docker for something which can be a pain to setup a toolchain for or install all of the dependencies for, but for the Rust compiler I see very little reason for running it inside of a container except in a very few very niche cases.
- staticassertion 7y ago
  At one point docker was the only way to do this, I think. So if you start searching the internet for how to do static linking with musl you're very likely to find links to the docker'd approach.

nrclark 7y ago

I see a lot of people comparing Rust favorably against C++, largely due to C++'s complexity. And yet at the same time, the Rust dev team are changing and expanding the language very quickly. Is there any plan to feature-freeze Rust? Otherwise it'll just become C++ 2.0 - a giant mass of features that are progressively designed to replace each other, until the language becomes too complex for any one person to master.

steveklabnik 7y ago
There is no plan to do that, but as time goes on, the bar gets higher and higher. We are not changing the language in backwards-incompatible ways.
- nrclark 7y ago
  Good to know. Worth pointing out that the C++ standards committee also almost never breaks backwards-compatibility. Instead, they just introduce The New Way (and then The Old Way becomes just one more trap). If you're in a position to affect this for Rust, it's worth thinking about. Give the documentation and libraries a few years to catch up, so that we don't have to chase a moving target. Maybe focus more on compiler and toolchain optimizations, and less on language features. It's a little rough to play in an ecosystem where the language itself effectively has a nightly/unstable variant.
  - steveklabnik 7y ago
    We are all very much aware :) That's very much been the theme of 2019 and 2020. 2019 really only saw the introduction of async/await as a new language feature. Almost all other additions were smaller things, like "this feature expanded a bit" or "this edge case is no longer an edge case." There was only one instance of something straight-up replacing the old thing; mem::uninitialized by MaybeUninit.
nicoburns 7y ago
Notably almost none of Rust's new features are replacing old ones. Most of them are either opening up new capabilities (e.g. async-await), or making existing mechanisms more general/flexible (e.g. const generics, GATs). It might accumulate cruft eventually, but I think it's at an inherent advantage over C++ due to its heavy functional influence, which is all based on math / PL theory. On the other hand C has always been a quick-and-dirty language, and C++ inherited a lot of that legacy. The macro system also helps a lot, as features can be prototyped as macros, and only stabilised once the design has been iterated and used. More niche features can stay as macros in 3rd party libraries.

rstuart4133 7y ago

> The biggest long-term issue in my mind is unsafe I'd say that, but for different reasons. It's depressing how often you have to use unsafe. I would not mind if it was hidden in libraries tested within an inch of their life 99.9% of the time, but it didn't work out that way for me. Recursively defined data structures like trees were just a nightmare to do without unsafe's. I thought that was perhaps because I just sucked at Rust, but then I listened to a talk from one of the Mozilla core devs working on Servo. Their code had more unsafe's than mine. The amount of parallelism they were trying to get was extreme of course, so it wasn't really much of a comparison. It made me feel much better all the same.