17 ms·

Why I rewrote the mesh generator of Dust3D from Rust to C++

174 points by sagartewari01 8y ago

adamnemecek 8y ago
"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background." To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed. Here is a good article that arrives at the opposite conclusion: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.
- nraynaud 8y ago
  XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might eventually be money in it, but I am certainly not a convert.
  - adamnemecek 8y ago
    > XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?
    - nraynaud 8y ago
      Basically you have some kind of hierarchy of crates according to the abstraction level, and those crates are owned by some loose organisation. The trick is that the those crates are new and there is only very few MCU features exposed in them (and modern MCUs are so "big" that there is no real hope to get out of the situation quickly), so when you're doing a project, you either have to send a PR upstream and have it die there immediately or argue for days before it dies, or you have to fork the crate yourself. I couldn't find a way to add code in the namespace of a crate without actually re-compiling it. It was extremely naive to split the crates horizontally and have only a limited group of people able to access the register they want to use, and not expose some kind of extension mechanism. some examples: STM32F103 doesn't expose DMA, there is no provision for async SPI, no provision for changing the speed of any communication device (nor any bus for that matter). Which we could attribute to the thing being new, but drivers are already being written in such a way that thing are getting calcified like that, and the task of exposing all the functions of the MCU in rust is infinite, it has to be open to outsiders and that involve having a different slicing of API, and always making sure that from any configuration we can call release().
    - sanxiyn 8y ago
      There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision-making people. https://github.com/rust-embedded/wg/issues/64 https://github.com/rust-embedded/wg/issues/64 details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.
sanxiyn 8y ago
"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving." This is very much true while learning, and very much not true once you finished learning. It would be very concerning indeed if it were otherwise. As is, it is very concerning for Rust adoption, as this post evidences.
jsiepkes 8y ago
> As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. While anyone is obviously free to use any language he or she likes the whole article comes across to me as someone arguing why they dont want / need seatbelts: "They constrain my movement, I'm a good driver, etc.". These are also the same kind of arguments one could make for wanting to use a weakly typed language instead of a strongly typed language. Personally I like my types strong and my memory safe...
- htfy96 8y ago
  There are always trade-offs. I mean when I'm writing really low-level stuffs (e.g., optimizing matrix multiplication kernels) I frequently find type system annoying. In that case I would definitely prefer C/asm, because they are simply closer to bare medals.
- fulafel 8y ago
  Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)
  - adamnemecek 8y ago
    Most of those langauges don’t have the perf of rust or cpp.
    - sanxiyn 8y ago
      Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.
      - adamnemecek 8y ago
        Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.
Barrin92 8y ago
The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, error free and perfect at time of production. The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. Coupling components by types propagating through software, increasing time and effort to make changes to your software, increasing the overhead for others to contribute. In my opinion the dominant metric to evaluate the usefulness of a language's type system should be its overall effect on cost, time spent, productivity, ease of development and capacity to change. Everything else is very subjective or just an aesthetic concern.
- sanxiyn 8y ago
  I disagree, because Rust compile time checks are not prohibitive. I agree on all other points: you shouldn't try to write perfect software first time, mental overhead is a serious concern, battling type system is bad (but you don't do that in Rust). Overall, Rust is a productive language, especially compared to C++.
- adamnemecek 8y ago
  > capacity to change Good luck making changes to a 100kloc Python codebase.
  - gmueckl 8y ago
    You could perhaps start by adding type annotation. They are not perfect, but they help.
    - adamnemecek 8y ago
      Too little too late.
  - 8y ago
gmueckl 8y ago
Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C++ is utterly entrenched in that space like Fortran is for HPC.
- est31 8y ago
  Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.
  - gmueckl 8y ago
    And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.
    - jayd16 8y ago
      Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.
      - gmueckl 8y ago
        Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion. IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming. Compare all this to Unreal. By sticking to C++, they do not have to commit the same amount of resources to programming language related tooling.
Vogtinator 8y ago
Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.
- adamnemecek 8y ago
  You can use dynamic linking but you have to recompile.
- fxfan 8y ago
  "completely unusable" You forgot to tell Microsoft (biggest software seller on earth)and they decided to use it in actix
  - pjmlp 8y ago
    And are proposing it alongside C# and Core Guidelines compliant C++ for new systems software.
    - adamnemecek 8y ago
      Do you have a link?
      - pjmlp 8y ago
        Sure. Check the presentation slides. https://github.com/Microsoft/MSRC-Security-Research/tree/master/presentations/2019_02_BlueHatIL https://github.com/Microsoft/MSRC-Security-Research/tree/mas...
- sanxiyn 8y ago
  Rust supports stable ABI with extern C. I agree it is highly suboptimal, but it works well enough that there are multiple production Redis modules entirely written in Rust, for example.
- galooga 8y ago
  rust is trash but the kind of person who puts stickers on a laptop thinks it's a good thing, so hey let's drop C++ for it.
gcc_programmer 8y ago
I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be honest, the tools available are enough to make you figure out any issue: gdb/core dumps/valgrind, when combined with good software practices and unit tests seem to work ok for the rest of us. The compilers now have sanitizers, and new versions of gcc actually tell you what your template errors are. It's 2019, not 2005 for C++. Smart pointers are now available: use them! Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions? Not everything a program uses is memory: we sometimes need sockets! In C++ using RAII works well, does the Rust Type System statically error/type check non-memory resources automatically, or is that out of scope?
- sanxiyn 8y ago
  I can. I (well, it's the team effort, so we) rewrote production system written in C++ with Rust. Even before the rewrite, C++ codebase was in modern C++17. Re: general resource management. It works exactly the same. Rust also does RAII. Rust also doesn't use exceptions for error handling. One easy to state advantage of Rust over C++ is that it checks your threading design.
- arcticbull 8y ago
  Rust memory management is just RAII, and there are no exceptions, just nice Result types and syntax that makes returning them and handling error cases simple and pleasant. If you want to handle closing a socket, it’s as easy as implementing the Drop trait on your type. Without an unsafe block there’s no way your destructor won’t be called. struct Socket(u16); impl Drop for Socket {...} To answer your question there’s no special casing around memory vs non-memory resources. Your socket is backed by a kernel ID which must exist in memory, of course, so by adding a Drop implementation you can then define the special treatment yourself. If threading considerations exist you can explore the Sync and Send marker traits too. It’s largely a much simpler language than C++, you just have to learn how to write it. A lot of the friction/confusion IMO is that it looks so similar to languages you use at first glance you just start writing the code you used to in a Rust-y way, instead of Rust, then are frustrated as to why it won’t build. In some ways it’d be clearer if it looked “foreign” like prolog — it’d be a lot less popular though haha.
bsder 8y ago
One thing that I don't see pointed out is that Rust is a nightmare if you are dependent upon mutable algorithms. I suspect that mesh generation is very much a mutable algorithm domain and probably a high impedance mismatch with Rust. For example, simple things like mapping a struct of three elements to a vector of three elements were, at one point, very difficult if not impossible in Rust.
nnq 8y ago
...hasn't Swift become a viable alternative in this space by now? I see it's getting used in ML a bit, and looks nicer than D and easier to learn than Rust.
- nazka 8y ago
  What's really missing in Swift it's all the multithread tools you can have with Rust like channels, MPMC... Anything from the "Fearless Concurrency". Personally I will love to see that happening for Swift to be able to really use it for the backend.
- pjmlp 8y ago
  Just like Objective-C, Swift is mostly a thing on Apple platforms.
- adamnemecek 8y ago
  Swift is somewhat higher level than Rust. You don't think much about allocations in Swift, whereas Rust is DSL for reasoning about allocations.
galooga 8y ago
but rust is supposed to make everything better? surely this is just conservative propaganda?
__s 8y ago
/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_the_mesh_generator_of_dust3d_from https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..
- ThrowawayR2 8y ago
  > You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment "If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make this code "safe" regardless of language. " , elsewhere "I get that this project probably values developer efficiency over safety or correctness, and probably makes sense in this use case.", etc. Still smells kind of elitist to me.
  - mlthoughts2018 8y ago
    Exactly. A bunch of link spam to reddit or quora doesn’t add up to evidence that the Rust community is reasonable or fair in its evaluation of alternative language choices or trade-offs against other languages.
    - bluejekyll 8y ago
      Are you suggesting that Rust is not as safe as it claims? Or that C++ is as safe as Rust? There’s a lot of research to disagree with either of those positions.
      - mlthoughts2018 8y ago
        No, not at all. Rust is a very good tool and is useful in many situations. I believe it offers better automatic memory safety. However, there are many cases when Rust is not a good tool for the job, and when specifically having greater manual control of memory or thread safety is a better choice. Additionally, in many applications you can build almost everything in a fully dynamically typed language, often interpreted as well, and only choose small sections of code to target for a specialized compiled implementation. In those cases, avoiding the overhead of a compiler and using rapid unit tests with high coverage as an alternative to compiler checks may often be a far safer and superior way to develop code, leading to adequately safe and performant code that is easier to maintain, faster to create, easier to explain, etc. All I’m saying is that Rust is another tool in the toolbox. It’s not intrinsically or unilaterally better than any other tool, and other tools can inhabit parts of trade-off space that make them better choices than Rust, even for applications that need memory safety or high performance. In my experience though, most interactions with Rust community leave me feeling like a vocal and significant fraction are trying to seriously claim that Rust is categorically and unilaterally a better choice across almost all possible use cases, let alone across a wide range of practical use cases.
ilovecaching 8y ago
Three problems with this: 1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way a human does, and that’s value added not detracted. 2. Having the benifit of actually having a package manager, Rust is much easier to download and use dependencies with. That said, I agree with the general premise of not using Rust if you have an immediate business need and it’s missing a core library. My issue is that it should be fairly apparent before you start a project what dependencies you need, so a rewrite back to C++ seems odd. Also, Rust is an open source ecosystem, and people using it should feel compelled to consider writing the missing pieces they need for the benifit of the community. It’s also odd to say that Rust doesn’t have what you need, it sounds like there are C libraries that already do what you want, and Rust can wrap C. 3. If something is written in C and you don’t have time to replace it, just wrap it in unsafe and make a safe interface over it. Rust is exceedingly good at interfacing with C, so any library you can use in C can potentially be used in Rust.
- mrfredward 8y ago
  >You still have to fight with borrow checking in Rust as in C++, it’s just not automated. It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and mutating things from different places in your code. In rust, the borrowchecker disallows shared mutable state...that's a huge win if you want to parallelize your code later on, but it also means that things that are trivial in C++ take a lot of thought and effort in rust, especially if you're thinking in a C++ paradigm (as opposed to coming from a functional language).
  - shepmaster 8y ago
    My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability (https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...)
JabavuAdams 8y ago
This is why I gave up on Haskell. Code is still (currently) written by humans. Sure the code was more terse, but I had to expend more time thinking about every tiny piece of that terse code. I've been programming for 36 years. Just as some people think out loud, I think by shaping and reshaping code. Top-down doesn't work for me, although I know there are other developers for whom it does. I like to build bottom-up by fooling around with little pieces. I have no experience with Rust, but fooling around in Haskell just took all the joy out of programming, for me, while adding frustration. EDIT> I would rather have better CASE tools / an AI pair-programmer than be straitjacketed into a top-down correct-first then code way of working.
- sjcoles 8y ago
  Even with a top down approach you can end up with insane type level machinations or group/category theory that only the best Haskell developer can decode. Sure it's elegant, but damn near indecipherable.
  - deleted 8y ago
    [deleted]
alexnewman 8y ago
I was a fan of rust when it first started. i wrote some consensus algorithms and metrics packages in rust. i also hosted a rust podcast. I now believe Rust has failed. Mostly because of the arrogance of organizations like the rust community and the inability to form stronger relationships with companies like apple. I now think that people should focus on swift and soon it will have the same native code support and a borrow checker. I think we all learned a lot but it’s time to realize people still don’t understand why not go and swift. C programmers continue to prefer c and more and more people are shifting back from rust to c++. rust will never provide enough
mcguire 8y ago
"When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving." Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., because "nobody has got time for that." I periodically fired up valgrind and chased down assorted memory issues. So, yeah...
- lixtra 8y ago
  Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.
  - kbenson 8y ago
    It seems to me that letting yourself work under the assumption something may be easy to fix later when you add the safety constraints back is just asking for major pains when it isn't easy. A wrong assumption at that level can render your entire algorithm unworkable if your plan was to make it safe in the end, since some patters just don't lend themselves to easy expression in rust. Then you're stuck with the choice, leave it unsafe and worry about it from them on, or rewrite it safely using an altered or entirely different algorithm. That doesn't seem like a gamble that's worth it to me. Even for exploratory code. Unless it's such a performance critical portion of the project that I'm willing to write it in a different language for speed, why bait myself so? If one of my goals for a project is to write somewhat functionally, I wouldn't start off with an exploratory approach using procedural techniques. I think we can all see what I'd probably end up with in the end, and it might work, but it probably wouldn't have some of the attributes I was hoping for.
  - bluesroo 8y ago
    I've found that more often, it should be reworded as "unsafe fast, painfully maintain without the resources to ever fix later".
Dowwie 8y ago
One day, social anthropologists will read these Hacker News message forums to learn about tribal warfare among programmers. What will they say, considering their entire new world was based on Rust? Kidding. Stop fighting, people. You're all on the same team.
- Verdex 8y ago
  My theory is that there are two basic ways of understanding the world around you and solving problems. Statistically and structurally. Everyone can do statistical problem solving. At least everyone who can talk. What you do is that you start making sounds when you're an infant and then you receive positive or negative feedback. This continues until suddenly you know how to talk. Similarly, in industrial chicken raising you need to differentiate between male and female chicks right after they're born. However, there isn't any guide to determine the difference. Instead what you do is that you take one person who knows how to do it and pair them with someone who doesn't know how to do it. The person who doesn't know how to do it will guess at the sex of the chick and they will be corrected by the person who does know how to do it. After enough time you have two people who know how to do it. Sounding familiar yet? Most people learn programming languages in a statistical fashion. They try a bunch of stuff and get positive or negative results (compile fails, runtime errors, etc). However, just like determining whether a chick is a male or female in the chicken raising industry, nobody can really give you the specification of how to program. All they can do is tell you that you are doing it wrong or doing it right for any given scenario. Now of course there are problems with the statistical method (also benefits, but we're interested in failure right now). 1) You can't say why you're right [in order to do that you have to sit down an analyze what you've been doing in a structural fashion]. 2) The only teaching method you know involves telling people they're wrong when your gut tells you they're wrong. 3) You'll have a terrible intuition for any situation that only causes a failure after a period of time or some of the time (think undefined behavior in C). If you have only learned programming statistically and haven't sat down and reflected on what the structure of what you're doing actually is, then when you are faced with information that is contrary to what you know your natural reaction is going to be to listen to your gut (even if your gut is wrong) and provide the same negative response that you got when you were first learning. Additionally, the only "reasons" that you'll be able to give are paper thin metaphors and thought terminating cliches that don't stand up to even the smallest amount of examination. The end result? You get a bunch of programmers that freak out every time a new language comes out.
dvnguyen 8y ago
My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt. Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for greenfield projects. You'd want to fight your problems, not your problems plus Rust. On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite. Personally I don't think Rust is that hard to learn and some of my side projects are being written in Rust. But if I ever had a business with Rust as a main language, I'd be worry I could find enough Rust programmers. Fortunately the community is addressing its ergonomics and hopefully one day its approachability and learning curve will also gain more attention.
- adamnemecek 8y ago
  > On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite. Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes on.
- deleted 8y ago
  [deleted]
fooker 8y ago
Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong". I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.
- steveklabnik 8y ago
  > the only response we are seeing is "you're holding it wrong". We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're very interested in improving them; if you have good ideas about it, you'll get heard out.
  - fooker 8y ago
    Can you point me to a document listing the changes from this effort?
    - steveklabnik 8y ago
      Probably the closest is https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html, which laid out the plans to do so. That being said, there wasn’t a single real document I can point you to: it was a label attached to a number of RFCs, and not really tracked as one thing. Some stuff that ended up landing under this banner was: Non-lexical lifetimes “Match ergonomics” Implied lifetime bounds The anonymous lifetime The question mark operator Async/await (this one is still in progress) The removal of “extern crate” ... and some other things I’m sure I’ve forgotten. I also said “last year” but that blog post is from 2017, and that’s because it took a long time for RFCs to be created, accepted, implemented, and stabilized; a lot of this stuff landed in the latter half of last year, though some before then too.
peatmoss 8y ago
As someone who never learned C++, I keep hearing about how today’s C++ is much better than the C++ of a few years ago. Can anyone recommend a resource for learning some C++ basics using today’s modern C++?

174 points by sagartewari01 8y ago

"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. I know the friction is greater because I am still a Rust learner, not a veteran, but I think this experience stops a lot of new comers, speaking as someone who already conquered the uncomfortable syntax of Rust, coming from a C/C++ background." To be honest, this article seems somewhat ingenuous. The author wasn't comfortable with Rust, and it seems like he missed the point of the borrow checker. This article will now be circulated whenever Rust is discussed. Here is a good article that arrives at the opposite conclusion: https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html I've been writing Rust full time for the last month and a half or so and the language is a joy to use. The main difference is that the code I write feels very sturdy and permanent. I've heard other people say the same thing.

nraynaud 8y ago
XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. I have been studying rust for embedded since January and I am not really impressed by what I have seen. I am mostly hacking around the deficiencies of the libraries, the crazy organisation of the stack, and the issues with the community. I am sticking with rust for now because I feel like there is a bandwagon and there might eventually be money in it, but I am certainly not a convert.
- adamnemecek 8y ago
  > XML didn't work? use more XML. Everybody has a breaking point, and they reached theirs. This argument could be applied to anything. What's crazy about Rust stack organization? What are the issues with the community?
  - nraynaud 8y ago
    Basically you have some kind of hierarchy of crates according to the abstraction level, and those crates are owned by some loose organisation. The trick is that the those crates are new and there is only very few MCU features exposed in them (and modern MCUs are so "big" that there is no real hope to get out of the situation quickly), so when you're doing a project, you either have to send a PR upstream and have it die there immediately or argue for days before it dies, or you have to fork the crate yourself. I couldn't find a way to add code in the namespace of a crate without actually re-compiling it. It was extremely naive to split the crates horizontally and have only a limited group of people able to access the register they want to use, and not expose some kind of extension mechanism. some examples: STM32F103 doesn't expose DMA, there is no provision for async SPI, no provision for changing the speed of any communication device (nor any bus for that matter). Which we could attribute to the thing being new, but drivers are already being written in such a way that thing are getting calcified like that, and the task of exposing all the functions of the MCU in rust is infinite, it has to be open to outsiders and that involve having a different slicing of API, and always making sure that from any configuration we can call release().
  - sanxiyn 8y ago
    There are lots of issues with using Rust for embedded development, most of them long standing, which are often felt to be neglected, and some suspicion that progress is slow because it is not the highest priority for decision-making people. https://github.com/rust-embedded/wg/issues/64 https://github.com/rust-embedded/wg/issues/64 details some of these technical issues. Personally issues with Cargo are the most pressing, and math/compiler_builtins is very annoying.

sanxiyn 8y ago

"As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving." This is very much true while learning, and very much not true once you finished learning. It would be very concerning indeed if it were otherwise. As is, it is very concerning for Rust adoption, as this post evidences.

jsiepkes 8y ago

> As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. While anyone is obviously free to use any language he or she likes the whole article comes across to me as someone arguing why they dont want / need seatbelts: "They constrain my movement, I'm a good driver, etc.". These are also the same kind of arguments one could make for wanting to use a weakly typed language instead of a strongly typed language. Personally I like my types strong and my memory safe...

htfy96 8y ago
There are always trade-offs. I mean when I'm writing really low-level stuffs (e.g., optimizing matrix multiplication kernels) I frequently find type system annoying. In that case I would definitely prefer C/asm, because they are simply closer to bare medals.
fulafel 8y ago
Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)
- adamnemecek 8y ago
  Most of those langauges don’t have the perf of rust or cpp.
  - sanxiyn 8y ago
    Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.
    - adamnemecek 8y ago
      Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

Barrin92 8y ago

The first few comments here seem to argue against the article, as do comments below the post but I am very much with the author. I strongly disagree with the Rust mentality, and the general mentality of statically typed languages with extremely prohibitive compile time checks, that seem to become more common. Underlying that model seems to be a concept of software like a sort of renaissance master's marble statue, error free and perfect at time of production. The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. Coupling components by types propagating through software, increasing time and effort to make changes to your software, increasing the overhead for others to contribute. In my opinion the dominant metric to evaluate the usefulness of a language's type system should be its overall effect on cost, time spent, productivity, ease of development and capacity to change. Everything else is very subjective or just an aesthetic concern.

sanxiyn 8y ago
I disagree, because Rust compile time checks are not prohibitive. I agree on all other points: you shouldn't try to write perfect software first time, mental overhead is a serious concern, battling type system is bad (but you don't do that in Rust). Overall, Rust is a productive language, especially compared to C++.
adamnemecek 8y ago
> capacity to change Good luck making changes to a 100kloc Python codebase.
- gmueckl 8y ago
  You could perhaps start by adding type annotation. They are not perfect, but they help.
  - adamnemecek 8y ago
    Too little too late.
- 8y ago

gmueckl 8y ago

Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C++ is utterly entrenched in that space like Fortran is for HPC.

est31 8y ago
Unity, one of the most popular engines out there, is mainly about C# for the gamedevs.
- gmueckl 8y ago
  And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.
  - jayd16 8y ago
    Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.
    - gmueckl 8y ago
      Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion. IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming. Compare all this to Unreal. By sticking to C++, they do not have to commit the same amount of resources to programming language related tooling.

Vogtinator 8y ago

Rust is still completely unusable as you can't use dynamic linking as there's no stable ABI.

adamnemecek 8y ago
You can use dynamic linking but you have to recompile.
fxfan 8y ago
"completely unusable" You forgot to tell Microsoft (biggest software seller on earth)and they decided to use it in actix
- pjmlp 8y ago
  And are proposing it alongside C# and Core Guidelines compliant C++ for new systems software.
  - adamnemecek 8y ago
    Do you have a link?
    - pjmlp 8y ago
      Sure. Check the presentation slides. https://github.com/Microsoft/MSRC-Security-Research/tree/master/presentations/2019_02_BlueHatIL https://github.com/Microsoft/MSRC-Security-Research/tree/mas...
sanxiyn 8y ago
Rust supports stable ABI with extern C. I agree it is highly suboptimal, but it works well enough that there are multiple production Redis modules entirely written in Rust, for example.
galooga 8y ago
rust is trash but the kind of person who puts stickers on a laptop thinks it's a good thing, so hey let's drop C++ for it.

gcc_programmer 8y ago

I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be honest, the tools available are enough to make you figure out any issue: gdb/core dumps/valgrind, when combined with good software practices and unit tests seem to work ok for the rest of us. The compilers now have sanitizers, and new versions of gcc actually tell you what your template errors are. It's 2019, not 2005 for C++. Smart pointers are now available: use them! Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions? Not everything a program uses is memory: we sometimes need sockets! In C++ using RAII works well, does the Rust Type System statically error/type check non-memory resources automatically, or is that out of scope?

sanxiyn 8y ago
I can. I (well, it's the team effort, so we) rewrote production system written in C++ with Rust. Even before the rewrite, C++ codebase was in modern C++17. Re: general resource management. It works exactly the same. Rust also does RAII. Rust also doesn't use exceptions for error handling. One easy to state advantage of Rust over C++ is that it checks your threading design.
arcticbull 8y ago
Rust memory management is just RAII, and there are no exceptions, just nice Result types and syntax that makes returning them and handling error cases simple and pleasant. If you want to handle closing a socket, it’s as easy as implementing the Drop trait on your type. Without an unsafe block there’s no way your destructor won’t be called. struct Socket(u16); impl Drop for Socket {...} To answer your question there’s no special casing around memory vs non-memory resources. Your socket is backed by a kernel ID which must exist in memory, of course, so by adding a Drop implementation you can then define the special treatment yourself. If threading considerations exist you can explore the Sync and Send marker traits too. It’s largely a much simpler language than C++, you just have to learn how to write it. A lot of the friction/confusion IMO is that it looks so similar to languages you use at first glance you just start writing the code you used to in a Rust-y way, instead of Rust, then are frustrated as to why it won’t build. In some ways it’d be clearer if it looked “foreign” like prolog — it’d be a lot less popular though haha.

bsder 8y ago

One thing that I don't see pointed out is that Rust is a nightmare if you are dependent upon mutable algorithms. I suspect that mesh generation is very much a mutable algorithm domain and probably a high impedance mismatch with Rust. For example, simple things like mapping a struct of three elements to a vector of three elements were, at one point, very difficult if not impossible in Rust.

nnq 8y ago

...hasn't Swift become a viable alternative in this space by now? I see it's getting used in ML a bit, and looks nicer than D and easier to learn than Rust.

nazka 8y ago
What's really missing in Swift it's all the multithread tools you can have with Rust like channels, MPMC... Anything from the "Fearless Concurrency". Personally I will love to see that happening for Swift to be able to really use it for the backend.
pjmlp 8y ago
Just like Objective-C, Swift is mostly a thing on Apple platforms.
adamnemecek 8y ago
Swift is somewhat higher level than Rust. You don't think much about allocations in Swift, whereas Rust is DSL for reasoning about allocations.

galooga 8y ago

but rust is supposed to make everything better? surely this is just conservative propaganda?

__s 8y ago

/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_the_mesh_generator_of_dust3d_from https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..

ThrowawayR2 8y ago
> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment "If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make this code "safe" regardless of language. " , elsewhere "I get that this project probably values developer efficiency over safety or correctness, and probably makes sense in this use case.", etc. Still smells kind of elitist to me.
- mlthoughts2018 8y ago
  Exactly. A bunch of link spam to reddit or quora doesn’t add up to evidence that the Rust community is reasonable or fair in its evaluation of alternative language choices or trade-offs against other languages.
  - bluejekyll 8y ago
    Are you suggesting that Rust is not as safe as it claims? Or that C++ is as safe as Rust? There’s a lot of research to disagree with either of those positions.
    - mlthoughts2018 8y ago
      No, not at all. Rust is a very good tool and is useful in many situations. I believe it offers better automatic memory safety. However, there are many cases when Rust is not a good tool for the job, and when specifically having greater manual control of memory or thread safety is a better choice. Additionally, in many applications you can build almost everything in a fully dynamically typed language, often interpreted as well, and only choose small sections of code to target for a specialized compiled implementation. In those cases, avoiding the overhead of a compiler and using rapid unit tests with high coverage as an alternative to compiler checks may often be a far safer and superior way to develop code, leading to adequately safe and performant code that is easier to maintain, faster to create, easier to explain, etc. All I’m saying is that Rust is another tool in the toolbox. It’s not intrinsically or unilaterally better than any other tool, and other tools can inhabit parts of trade-off space that make them better choices than Rust, even for applications that need memory safety or high performance. In my experience though, most interactions with Rust community leave me feeling like a vocal and significant fraction are trying to seriously claim that Rust is categorically and unilaterally a better choice across almost all possible use cases, let alone across a wide range of practical use cases.

ilovecaching 8y ago

Three problems with this: 1. You still have to fight with borrow checking in Rust as in C++, it’s just not automated. You have to consider moves and copies, borrowed references, etc. As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature. The point is that the borrow checker is a computer and doesn’t make mistakes the same way a human does, and that’s value added not detracted. 2. Having the benifit of actually having a package manager, Rust is much easier to download and use dependencies with. That said, I agree with the general premise of not using Rust if you have an immediate business need and it’s missing a core library. My issue is that it should be fairly apparent before you start a project what dependencies you need, so a rewrite back to C++ seems odd. Also, Rust is an open source ecosystem, and people using it should feel compelled to consider writing the missing pieces they need for the benifit of the community. It’s also odd to say that Rust doesn’t have what you need, it sounds like there are C libraries that already do what you want, and Rust can wrap C. 3. If something is written in C and you don’t have time to replace it, just wrap it in unsafe and make a safe interface over it. Rust is exceedingly good at interfacing with C, so any library you can use in C can potentially be used in Rust.

mrfredward 8y ago
>You still have to fight with borrow checking in Rust as in C++, it’s just not automated. It's not that easy. The borrow checker gives you memory safety and thread-safety. In C++, you always have to worry about memory safety, so here the ownership model and borrow checker is a pure win. However, in C++ you don't have to worry about thread safety in a single thread...there's no barrier to passing pointers around and mutating things from different places in your code. In rust, the borrowchecker disallows shared mutable state...that's a huge win if you want to parallelize your code later on, but it also means that things that are trivial in C++ take a lot of thought and effort in rust, especially if you're thinking in a C++ paradigm (as opposed to coming from a functional language).
- shepmaster 8y ago
  My counter argument is nicely summed up by The Problem With Single-threaded Shared Mutability (https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...)

JabavuAdams 8y ago

This is why I gave up on Haskell. Code is still (currently) written by humans. Sure the code was more terse, but I had to expend more time thinking about every tiny piece of that terse code. I've been programming for 36 years. Just as some people think out loud, I think by shaping and reshaping code. Top-down doesn't work for me, although I know there are other developers for whom it does. I like to build bottom-up by fooling around with little pieces. I have no experience with Rust, but fooling around in Haskell just took all the joy out of programming, for me, while adding frustration. EDIT> I would rather have better CASE tools / an AI pair-programmer than be straitjacketed into a top-down correct-first then code way of working.

sjcoles 8y ago
Even with a top down approach you can end up with insane type level machinations or group/category theory that only the best Haskell developer can decode. Sure it's elegant, but damn near indecipherable.
- deleted 8y ago
  [deleted]

alexnewman 8y ago

I was a fan of rust when it first started. i wrote some consensus algorithms and metrics packages in rust. i also hosted a rust podcast. I now believe Rust has failed. Mostly because of the arrogance of organizations like the rust community and the inability to form stronger relationships with companies like apple. I now think that people should focus on swift and soon it will have the same native code support and a borrow checker. I think we all learned a lot but it’s time to realize people still don’t understand why not go and swift. C programmers continue to prefer c and more and more people are shifting back from rust to c++. rust will never provide enough

mcguire 8y ago

"When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving." Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., because "nobody has got time for that." I periodically fired up valgrind and chased down assorted memory issues. So, yeah...

lixtra 8y ago
Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.
- kbenson 8y ago
  It seems to me that letting yourself work under the assumption something may be easy to fix later when you add the safety constraints back is just asking for major pains when it isn't easy. A wrong assumption at that level can render your entire algorithm unworkable if your plan was to make it safe in the end, since some patters just don't lend themselves to easy expression in rust. Then you're stuck with the choice, leave it unsafe and worry about it from them on, or rewrite it safely using an altered or entirely different algorithm. That doesn't seem like a gamble that's worth it to me. Even for exploratory code. Unless it's such a performance critical portion of the project that I'm willing to write it in a different language for speed, why bait myself so? If one of my goals for a project is to write somewhat functionally, I wouldn't start off with an exploratory approach using procedural techniques. I think we can all see what I'd probably end up with in the end, and it might work, but it probably wouldn't have some of the attributes I was hoping for.
- bluesroo 8y ago
  I've found that more often, it should be reworded as "unsafe fast, painfully maintain without the resources to ever fix later".

Dowwie 8y ago

One day, social anthropologists will read these Hacker News message forums to learn about tribal warfare among programmers. What will they say, considering their entire new world was based on Rust? Kidding. Stop fighting, people. You're all on the same team.

Verdex 8y ago
My theory is that there are two basic ways of understanding the world around you and solving problems. Statistically and structurally. Everyone can do statistical problem solving. At least everyone who can talk. What you do is that you start making sounds when you're an infant and then you receive positive or negative feedback. This continues until suddenly you know how to talk. Similarly, in industrial chicken raising you need to differentiate between male and female chicks right after they're born. However, there isn't any guide to determine the difference. Instead what you do is that you take one person who knows how to do it and pair them with someone who doesn't know how to do it. The person who doesn't know how to do it will guess at the sex of the chick and they will be corrected by the person who does know how to do it. After enough time you have two people who know how to do it. Sounding familiar yet? Most people learn programming languages in a statistical fashion. They try a bunch of stuff and get positive or negative results (compile fails, runtime errors, etc). However, just like determining whether a chick is a male or female in the chicken raising industry, nobody can really give you the specification of how to program. All they can do is tell you that you are doing it wrong or doing it right for any given scenario. Now of course there are problems with the statistical method (also benefits, but we're interested in failure right now). 1) You can't say why you're right [in order to do that you have to sit down an analyze what you've been doing in a structural fashion]. 2) The only teaching method you know involves telling people they're wrong when your gut tells you they're wrong. 3) You'll have a terrible intuition for any situation that only causes a failure after a period of time or some of the time (think undefined behavior in C). If you have only learned programming statistically and haven't sat down and reflected on what the structure of what you're doing actually is, then when you are faced with information that is contrary to what you know your natural reaction is going to be to listen to your gut (even if your gut is wrong) and provide the same negative response that you got when you were first learning. Additionally, the only "reasons" that you'll be able to give are paper thin metaphors and thought terminating cliches that don't stand up to even the smallest amount of examination. The end result? You get a bunch of programmers that freak out every time a new language comes out.

dvnguyen 8y ago

My hypothesis is a software growth, like a business or an economy, is fueled by debt. We create technical debts, both deliberately and accidentally, to write software faster. And when the software proves itself as a viable project, we could (ideally) start paying the debt. Rust forces users pay certain kinds of debt upfront that makes Rust attractive for rewriting, but I don't think it's that much attractive for greenfield projects. You'd want to fight your problems, not your problems plus Rust. On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite. Personally I don't think Rust is that hard to learn and some of my side projects are being written in Rust. But if I ever had a business with Rust as a main language, I'd be worry I could find enough Rust programmers. Fortunately the community is addressing its ergonomics and hopefully one day its approachability and learning curve will also gain more attention.

adamnemecek 8y ago
> On top of my head right now I couldn't think of any famous Rust projects which aren't a rewrite. Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes on.
deleted 8y ago
[deleted]

fooker 8y ago

Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong". I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.

steveklabnik 8y ago
> the only response we are seeing is "you're holding it wrong". We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're very interested in improving them; if you have good ideas about it, you'll get heard out.
- fooker 8y ago
  Can you point me to a document listing the changes from this effort?
  - steveklabnik 8y ago
    Probably the closest is https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html, which laid out the plans to do so. That being said, there wasn’t a single real document I can point you to: it was a label attached to a number of RFCs, and not really tracked as one thing. Some stuff that ended up landing under this banner was: Non-lexical lifetimes “Match ergonomics” Implied lifetime bounds The anonymous lifetime The question mark operator Async/await (this one is still in progress) The removal of “extern crate” ... and some other things I’m sure I’ve forgotten. I also said “last year” but that blog post is from 2017, and that’s because it took a long time for RFCs to be created, accepted, implemented, and stabilized; a lot of this stuff landed in the latter half of last year, though some before then too.

peatmoss 8y ago

As someone who never learned C++, I keep hearing about how today’s C++ is much better than the C++ of a few years ago. Can anyone recommend a resource for learning some C++ basics using today’s modern C++?