Why I rewrote the mesh generator of Dust3D from Rust to C++ (opens in new tab)

As a im a (mostly) C++ programmer, despite the fact that i liked the language, i feel that the balance between what the language was giving me, and the productivity, was not worth it when compared to C++.

I feel much more productive in C++, the language is still faster, with a low memory footprint in the majority of cases, and with modern C++, smart pointers, move, a correct understanding of the ownership model .. the bad sides of it, the ones Rust did a better job shelving us from, from my point of view are not worth paying for the lack of productivity i felt in Rust as compared to C++.

I know this is an unpopular opinion here in HN, but I decided to take a different approach .. instead of "one language to rule them all" i tend to use C++ for what's good at, and Swift for more application centered goals , because its nicer than C++ and Rust (in my opinion), release you from the burden of managing memory all around while being very fast at the same time.

Swift for me is "the better Java" we were looking for, Rust does not seem appealing in this arena (and the same goes for C++ here), while you pay for what you use in Rust in terms of productivity, even compared to C++.

The other thing that makes C++ a better option in my opinion, is the ammount of libraries and codebase you have access to, not only in C++, but in C. Very important codebases are either C or C++, even the newer ones like Tensorflow or V8, Chrome, LLVM, etc ...

I understand the importance of what Rust provides, I like its goal, but your comment sounded like the OP was either stupid or lazy / incompetent by using your anedoctical evidence. (While in the same anedoctical example you are the hidden figure who are sensitive about security while still using C++, as the 'lazy guy', enabling -Wall, using Valgrind, etc)

When I entered in the comments section here, I was just expecting the sort of comments in the spirit of "how could you even do that?"

PS: Im not the kind of guy who tends to disable -Wall -Werror to have more productivity and i would not favor C ++ in exchange for Rust, if i feel the balance were better among what i pay in terms of productivity were fair in exchange for more safety as compared to what I have now with C++.

Until, you natively start thinking and writing code with idioms that the borrow checker is tuned for, there will be friction.

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.bell-labs.com/usr/dmr/www/chist.html

C static analysis tools, being ignored since 1979, because "nobody has got time for that."

There is a lot of C infrastructure, almost anything can work with C too...

He-he

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.

Dunno about Rust specifically, but I have written a little Haskell, and a significant amount of OCaml. I found that the type system reduces my cognitive overhead, compared to looser languages like Python or Lua. The compiler is disciplined, so I don't have to be.

In practice, with few exceptions, when the type system is refusing to compile something I just screwed up, and I'd better fix my mistake right away. I'd wager that with few exceptions, when Rust is refusing to compile something, you are making a mistake that in C++ would have bitten you down the line.

What you call "fighting the type system", I call "fixing bugs".

This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management and best practices while using other languages (core dumps heart attacks), and claims that one of the most important aspects of Rust is that "it's memory safe".

Of course, memory safety is achieved through compiler checks.

However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. If someone tries to write broken C or C++ using Rust and Rust's compiler starts to throw error messages pointing out the errors the programmer is making by trying to write broken C or C++ in Rust then obviously Rust is not the problem. It is im fact the solution, and a solution that's being ignored.

Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust's compiler because, as he puts it, the compiler will stop you from doing unsafe stuff again and again. Isn't that the whole point? Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++?

Types serve as explicit documentation for facts about the system that would otherwise have to be reconstructed by every reader. Type checking ensures that any change to one part of a system still interfaces consistently with all the other parts.

Writing in a dynamic language can be faster, since you can skip writing down information that you would have to be explicit about in a static language, but once that information has been purged from your mental cache, IMO that's when the system acquires the immutability of marble.

(The other nice thing about dynamic languages is certain patterns are often syntactically much cleaner.)

But once I got the hang of it progtamming Python became less and less attractive. The most interesting thing about rust is, how fast you can get up to speed with understanding what somebody elses code does.

The thing however is: if you try to write Rust like Python or C, you’re not in for a good time. It took me 3 months to stop using ingrained OOP patterns I really thought I needed because this was the way how I did things back in Python.

The moment I started to become interested into how to structure code in Rust, was the moment it made click for me. Seems it is much easier to program WITH the compiler than against it — who would have known!

It makes sense for developers to want development to be easier and for businesses to want it to be faster but it feels lazy and cheap to actively avoid tools that would help us produce better programs with much stronger guarantees in the name of ease of development.

It's not like rust's checks are arbitrary. If you wanted Rust's safety and guarantees in C++, then you would still have to do all the things the rust compiler is doing for you.

How course it's hard for them right now.

Guess what, it was harder when they started c/c++ decades ago. There was less tooling, best practices were even less clear, all code bases looked different and the language ergonomics were way worse than today.

Give it some time. Some time for the language to mature of course. But more than that, some time for the dev to actually reach fluency, not only it the language and ecosystem, but on the general philosophy of this way of producing software. It's even harder given many have to unlearn years of experience and patterns that made them productive, and adopt, discover, or even even new ones to replace them.

We have hugely high expectations towards rust because of the amazing work the core team has already made in so little time.

I see the same reaction toward the last 2 flight crashes. People are shocked this can happen. I'm just amazed it doesn't happen more often. The institutions have generally done a fantastic job.

Now to say we should not fix what's broken in both cases.

But let's be fair to the incredible result we already got.

The author was doing unsafe stuff and the compiler complaining. Once he gets in the swing of things, doing it right will become his natural flow. Verbosity of a language is a valid complaint that never goes away no matter how idiomatic your code writing gets but as written I'm not sure this was the author's complaint.

Of course the problem is: would people just add the flag to their configuration and never disable it? I think they would not. Because people mostly use defaults. That's why instead of -Wall -Wextra -pedantic with possible -Wereor for development, most places I worked in ignore most default warnings and just occasionally run some kind of static analysis. Even though many times the analysis often results with things that would be detected with additional warning flags.

And yeah I hate it and I wish that warnings would mostly be treated as errors or silenced when applicable. Then there are always separate efforts to "clean the warnings". But afterwards new code just introduces new warnings, because people are trained to ignore them.

I assume that Rust developers don't want my scenario to happen at all, but I feel that with defaults reversed it wouldn't.

But maybe it's to great a risk? Of course as always it's a game of trade offs.

I think this is more post-hoc justification than anything else. There seem to be an awful lot of developers concerned about memory safety since rust started becoming trendy and I don't think many of them were coding in ada before rust existed.

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

Most of the time I'm writing code isn't for the first implementation of a green-field feature and, really, most programming problems aren't that hard in terms of logic flow. If I refactor and the type system and static checking don't complain, I can be reasonably sure it's going to work. And I've seen too many 'temporary hacks' that became forgotten and leaked to review or production.

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

I agree with your overall dominant metric. But I come to a different conclusion of what language/libraries bring me there.

To me a type safe language, is a refuge, a comfort zone -- away from the wilderness, unpredictableness and punishing complexity of troubleshooting -- associated with untyped languages.

Good luck making changes to a 100kloc Python codebase.

The cost is requiring a developer with stronger cognitive abstracting skills. Those people tend to be academics (its almost a definition of a good academic) and also, perhaps, less pragmatic.

The ease of programming is not merely a matter of knowledge or experience, base cognitive skills play a very significant part which are largely an at-birth and developmental factor (cf. The Neuroscience of Intelligence (Cambridge Fundamentals of Neuroscience in Psychology)).

Probably languages requiring a proficiency at dealing with highly abstract relationships as part of the activity of programming are never going to be mainstream. Most people find that too difficult to do easily, and so too tasking to program.

That isn't the general case however. Some people find it easy enough, and so do not see this tradeoff. For these people, the clear benefits in creating a statically "correct" program outweigh the minor difficulty in creating it.

For the able, this "difficulty" is perceived as fun, and as frustrating by those who aren't. When something is beyond our basic capacity we tend to see it as "needlessly difficult" and not worthy of our time/attention (and of course, for us, it is).

In otherwords: the unable are often snobs.

eg. "Acting is stupid", "Rust is crap", "Painting is pointless" etc. -- all amount to, "i struggle to do that".

If you want to build the best company, you might not care so much about these.

But then, not all of us are running businesses. And building your company on top of the best code isn't even a bad idea.

There is often a debate in the D community how the defaults could have been better: pure, @safe, const by default, no GC by default etc.

But not every bit of code need to be perfect. Code must prove its usefulness first and foremost, before the need to be reliable, safe, fast and beautiful even enter the picture.

I'd go as far as to say, thinking of a nascent project as something perfect and beautiful likely leads to over-idealization and will delay the time to completion many-folds.

Ability to write ugly code is - for me - a feature.

I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I understood why it couldn't tell. Usually, when I hit it, it is because I forgot a case and am grateful for it. I know of at least one optimization I've made that I would never have bothered with without the borrow checker. It would have been too much bother for me to reason about everything. Even if I did, it would have been even worse to maintain.

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

This sounds like a great idea, but not everyone has the time and resources to port libraries from one language to another. It should be trivial to wrap C libraries, but errors do show up, and a once one day task now takes a week to iron out. If you have 4 or 5 libraries that are missing, you've now lost a month of development work that could have been spent adding new features.

Additionally, not everyone wants to maintain open source projects. There's a huge amount of responsibility that comes with being a maintainer, and the OSS community isn't always a friendly, fun place. Rachel has some great examples in her blog [1].

[1]: https://rachelbythebay.com/w/2018/10/09/moat/

This is so misleading. Sure you still have to think about borrowing in C++ but in C++ you only have to convince yourself that you got it right. You don't have to convince a dumb child that barely understands variable scopes.

The benefit is of course that the dumb child is 100% reliable so if you can convince him then you are 100% sure you got it right...

But please can we stop pretending that it isn't a massive pain in the arse to convince the borrow checker that your code is ok.

Also as someone else pointed out, if you are only writing single threaded code the mutable borrowing rules are needlessly restrictive.

I like Rust but it really irks me when people pretend it is as easy as C++. It isn't. It is much harder - it's just that when you're done you have (probably) a better result.

Modern C++ is "good enough" where you'll potentially end up with some unsafe code but unless you're writing an SSL library it'll be OK.

Hello. :-) I started writing C++ around 1992, and was lead programmer on various C++ production systems from 2002 until 2011. I worked with valgrind, unit tests, and boost/std::tr1 C++, but not C++14 or 17.

For the past three years, I've been writing production systems in Rust. Here are some things I've observed:

- If your C++ code relies heavily on complicated webs of objects that all mutate each other (as found in many game and GUI designs), you'll have a bad time translating that code to Rust. If your C++ code tends to be more functional, idempotent, or transaction-based, and if it has clear ownership of objects, then translating to Rust will be much easier. For example, Rust seems to work better with ECS-based games and React-like GUIs.

- Rust is significantly weaker than C++ for designs which use integer template parameters (e.g., "vec<3>") or partial template specialization.

- Modern C++ allows you get ownership 99% correct, if you throw enough tools at it. Rust gets ownership 100% correct by default. If you're dealing with situations where that 1% matters (complex threading, or decoding hostile data), then it's a much bigger difference than you might think.

- Not counting Rust IDEs (which are only borderline OK by static language standards), Rust tooling is great. Dependency management is solid, linting is good, automatic formatting is good, etc.

- I've been working with nightly and experimental builds of Rust async code, and I think that Rust will soon give C++ a real run for its money in this space. Multithreaded async executors (where you mix "green" threads with OS threads) rely very heavily on precise tracking of who's allowed to mutate what, which Rust is excellent at.

> Finally, if a Rust veteran could let me know: how does Rust deal with general resource management in the presence of exceptions?

Rust does not have exceptions. Instead, it uses `Result<T,E>` and the `?` operator to propagate errors. Ownership and RAII are 100% idiomatic and fully checked by the same systems as memory management.

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.

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.

Wut? Piston, actix, Amazon Firecracker, Alacritty, Xi, the list goes on.

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.

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.

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.

You forgot to tell Microsoft (biggest software seller on earth)and they decided to use it in actix