Hacker News Reader

Comment by Barrin92 | Hacker News Reader

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.

View on HN

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

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

> you are making a mistake that in C++ would have bitten you down the line.

Taking some C++ code from an explorative phase that "usually works kinda ok" to something seaworthy requires, in my experience, a huge amount of work (which usually neglects a few issues that will bite you later regardless). I'm not so sure the (probably) faster exploration in C++ compensates for this compared to more "strict" languages like Rust.

Of course, if the functional requirement is only "usually works kinda ok", then you don't really need something like Rust.

I found that strict compile time checks speed up my exploratory phase. That's because the type system provide an even tighter feedback loop than a REPL, and effectively cuts down the search space.

Other people seem to have experienced the opposite, though. I have no idea why.

It might depend on the problem space. I dunno. But I suspect it depends a lot on the type system and type inferencer of the language you use.

It is easier to write a true statement than it is to prove the statement is true, and getting a compiler to agree to compile quite literally requires proving a statement is true. This can be more or less difficult based on the language. I’ve read a lot of war stories, particularly in java, about having to do a lot of crazy convoluted code to get the compiler to realize that yes actually these 2 objects are interchangeable from an API/Interface point of view. I don’t know, but I suspect this may be a lot less common in languanges using hindley-milner type system, since that lends itself to very good type inferencing.

To me, the question is whether the time spent dealing with compiler errors is due to fixing real problems that the compiler is pointing out, or whether that work is mostly reworking a correct program to satisfy the compiler when it cannot yet see that the program is correct.

I don't think humans have anything major in their toolkit for reasoning about memory management / aliasing that the Rust compiler doesn't; when non-trivial code cannot be expressed in terms of single-ownership at any given point, code loses correctness-at-a-glance. There are cases where a safe Rust abstraction is built on unsafe code, including most of Rust's collections; the API contract of every stdlib collection is: the collection owns its elements. Interestingly, such a contract can generally be implemented safely, but would have different performance characteristics; e.g. doubly-linked List could use indexes into a Vec. This example mirrors a pattern seen in languages that discourage mutation: break the rules internally for performance optimizations, but maintain the invariants at API boundaries to contain the cognitive overhead. Even when Rust's rules need to be broken, they are useful to contain complexity.

I worked professionally in Haskell for a long time and I cannot disagree with you more. This is always the promise of strict functional languages but in a business setting where the very nature of what you build has to be arbitrarily mutable at the whim of competing interests between stakeholders, engineers, customers, etc., it just doesn’t work.

You end up with the same spaghetti code messes, unexpected runtime errors, indecipherable crashes, etc. no matter what degree of strict verification tooling you use. The introduction of lazy evaluation, difficult to debug tail recursion implications on memory consumption, elevating IO into the type system, burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell... it becomes the same shit code mess as any other paradigm.

Interesting. I would be interested to know more details about what you worked on and with whom. This hasn't been my experience in any of the four jobs I've used Haskell at.

I don't deny that Haskell leads to spaghetti code messes, unexpected runtime errors, and indecipherable crashes, but the Java that I've previously worked with and the Python I currently work with suffer from those to a degree greater by an order of magnitude.

It was first for a bank, later for a data analytics start-up, and then also for an education technology company. I had many skilled functional programmers on my team too, including a few people who had done work on GHC itself.

I’ve also see code messes in many languages. It’s a business culture problem, has nothing to do with the language or paradigm.

I’ll greatly dispute with about Python though. It has been a language that facilitates notably cleaner and more extensible implementations in my experience. Seen messes in Python too, but absolutely no way it’s “an order of magnitude” worse. That’s simply ridiculous. The only way that’s happening is if the programmers are exceptionally bad to the extent that it would not matter which language they used.

Very interesting. I suspect we may even have worked for the same bank! I'd love to discover how we came to such opposing conclusions.

To give you a Python example, it encourages stuff like:

    def send_email(recipients, contents):
        if type(recipients) == str:
            send_one_email(recipients, contents)
        else:
            for recipient in recipients:
                send_one_email(recipient, contents)

That is a flavour of convenience that people commonly implement in Python. People like it because it allows both

    send_email("tome", contents)

and

    send_email(["tome", "mlthoughts2018"], contents)

and saves them from typing two square brackets. The problem is when you call

    send_email(u"tome", contents)

It tries to email "t", "o", "m", and "e". This kind of stuff is endemic in Python. Yes, this did happen in practice in a company I worked for (a company that was responsible for trading hundreds of millions of dollars of securities every day). Call the programmers exceptionally bad if you like, but they were among the brightest minds graduating in my country. It was Python that allowed them to be sloppy.

I disagree very much. The Pythonic way would be to do something like map(send_email, list_of_addresses), and have send_email raise an exception if not passed precisely a single string, and presumable raise exceptions when you validate that the email address is of an acceptable format, etc.

It would not be Pythonic to make the function superficially handle different arities of argument through explicit handling on the list type with isinstance, precisely because you’d need to handle different meanings of different types that implement the Iterator Protocol. That’s not something Python generally encourages, it’s just a mistaken implementation. And particularly not making careless assumptions when basing branches on isinstance behavior (for example, you could always encounter custom classes that have overridden __instancecheck__ or __subclasshook__ special methods.

It's certainly a poor use of Python's flexibility, but I've seen that kind of thing written at two completely different companies by completely different, yet smart, people so I suspect it's prevalent. Haskell does a much better job of nudging smart people to write good code. Gabriel Gonzalez explained it better than I could: http://www.haskellforall.com/2016/04/worst-practices-should-...

This isn't really spaghetti code, though, it's a syntactic sugar optimization gone wrong due to the Python 2 str/unicode split.

It's in the same league as people overloading operators in C++ to do silly things.

While some people like to harp on that, I don't think those instances are prevalent enough to actually cause that many bugs. YMMV.

> in a business setting where the very nature of what you build has to be arbitrarily mutable—

I just don't use Haskell there. I personally use OCaml for my data in, data out problems (compilers, generators…), but for inherently interactive and mutable stuff I just do imperative programming. Of course the type system (and the performance characteristics of the runtime!) must be suited to the problem domain.

> burying details deep in type class patterns, relying on dozens of special case compiler directives to enhance Haskell...

Looks like someone went overboard. I think you (your team?) should have been more conservative with the compiler directives, and less abstraction loving with the type classes.

> “Looks like someone went overboard.”

All these things are basically bare minimum table stakes to do anything in the language at all, particularly enabling dozens of compiler directives for language feature extensions. That is Haskell 101 practically, which is actually one of the hugest problems with the language.

Saying this is “overboard” in Haskell is out of touch with the practical realities of using the language.

Couldn't agree more. It was why my transition from Javascript (Node) to Go was very freeing - I had been so used to being constantly paranoid about my data types from Python and Javascript that even the most modest types of Go made a huge relief.

Likewise, with Rust it is a relief after Go. In Go interfaces are a massive part of the language and they can only be pointers, which means much of your programming experience holds mental overhead needed to frequently answer "is this variable safe? Can I access it, or might it be nil?".

There's definitely overhead in learning how to use the borrow checker, but I feel that's the same as any basic language features in any language. Once learned, I largely don't think of them, and I don't fear using variables or what is concurrently safe anymore.

I can definitely see where the author was coming from in terms of new code. I've been of the opinion that it's probably better to greenfield new systems alongside a GC'd runtime(which makes Go a pretty good fit, but also D, Nim, etc. - and for the very experimental stages where the type layout is minimally understood - Python, Lua, JS, etc.), and to take on external dependencies to get a result working - and then rewrite parts with manual memory and custom libraries where the spec needs tightening.

The main downside to this is that you're rewriting stuff, but the goal of the rewrite should be to express what is essentially the same functionality in more detail.

Where I think the author might have erred is in switching between three different manual memory languages in the hopes of faster development. The algorithms needed for a 3D tool have a pretty high base complexity, making it hard to bootstrap the codebase - and I suspect that C++ will ultimately frustrate him just as much as Rust and C did before.

Ah, but in this case you have already done the spec, otherwise the type system couldn't have checked it.

With a more loose way of going about things, you don't have to write the spec. Spec'ing is hard, sometimes harder than actually solving the problem.

I feel like someone is going to point out that spec'ing is a lifesaver in a certain situation, and I would agree. But perhaps not all situations.

That is an oversimplification, very often you know something that cannot be expressed in the types, so escape hatch (cast/unsafe) are useful. That said, if you can wrap around these 'hack' in a 'sane' API, then it's OK if you canno/didn't the result is quite ugly..

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

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++?

> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust compiler because, as he puts it, the compiler will stop you from doing unsafe studf 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++?

I think the biggest problem with advanced type systems and complex compiler checks is that they are only desirable when you know the code you're writing is the the right one. A lot of the time, you're exploring a solution and don't care about edge cases, since you're not sure you've even found the right happy path. At this stage, you don't really care if your code is handling all required inputs, if it doesn't have leaks etc. - you just want to run it and see whether it at least sometimes produces the right output. At this stage, you're often fighting the compiler.

Once you know that you're on a good path, then you start caring about safety and all the other bits, and the compiler starts becoming a trusted friend.

It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. I'd bet that would change many people's perspectives, like the author of this article.

> It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar.

https://github.com/thepowersgang/mrustc kind of does that. It assumes the input code is valid at the moment.

But if you want to experiment first, you have other language pairs you could use. Python + typed Cython, or Ruby + Crystal, or other options...

I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes.

In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.

> I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes.

I want to agree with you on this statement, but I don't think your anecdote supports it.

> In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.

To me it just sounds like the second junior has a stronger understanding of the language/type system.

Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course)

Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.

I don't have a problem with strong types, I agree with you. Dynamic types are usually too much hassle even for prototypes. I was talking more about stuff like Rust's borrow checker or dependent type systems.

> you just want to run it and see whether it at least sometimes produces the right output

Then use a dynamic language like ruby or python and enjoy not only data type freedom, but also features like easy introspection and code manipulation at runtime. Protyping and experimentation in a REPL is much faster, easier, and memory safe. If you are just experimenting, why are you wasting time and effort on e.g. C++'s complex type system? If you don't care about memory leaks, why waste any effort on memory management when the garbage collector can handle that for you?

> starting from Rust but setting a flag to turn borrow checker errors into warnings

Experience suggests the "we'll do it right in the next version" argument leads to "prototypes" being shipped as the "next" (only) version.

The difficulties imposed by Rust is the goal. Actually writing correct and safe code is inherently a difficult problem. Rust is trying to force programmers into actually addressing that problem. Writing similarly correct and safe C++ is also time consuming and difficult. The difference is C++ lets the programmer shift that work and expense onto the user in the form of time-wasting crashes and expensive security vulnerabilities.

Also I think that with enough .clone(), raw pointers and `unsafe` you can avoid almost all borrow checkers errors.

I never said anything about a release - I'm not even thinking about code you would commit. I'm talking about the kind of coding where you're exploring a new feature on your own machine - essentially doodling in an IDE instead of on paper. It makes no sense to me to make such code 'correct' - I don't even know if its useful to any extent, why would I care about its correctness?

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

Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.

Now it's applied to the other side (Rust is fine, you're just not good enough in it yet to use it properly, that's why you're discouraged).

Well, sometimes the language is not fine, and its ergonomics can be all wrong.

In C it was the type looseness, bad standard library, and presence of many foot guns.

In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming.

I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before.

If they can't, something's wrong with your language's ergonomics.

your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.

I do qualify that I speak about languages that are still "Algol-derived".

Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc).

It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.

i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection

As someone from a JS background, I am far more productive in Rust than C++. C++ makes it really easy to accidentally break something that then takes ages to debug. And using libraries is a massive pain.

However, if you have already learnt to be productive in C++, then I suspect Rust would end up being slightly slower to write the initial code, but not much. And it'd make up for it in ease of refactoring.

Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style.

Rust is both algol-derived, and ocaml-derived. And arguably the borrow checker creates a new paradigm entirely.

>The borrow checker creates a new paradigm entirely

I don't think this can be emphasized enough. You can get deceivingly far in rust with an OOP style, only to come to the disheartening conclusion that it's impossible to do what you want with the architecture you spent months of work setting up.

For example, how would you architect a simple single threaded emulator? The CPU is an object, RAM is an object, easy enough. Okay, the CPU needs mutable access to RAM at all times, so we'll make the CPU own the RAM, sure why not? Okay now we want to implement a graphics device that can mutably access RAM, so we just...put the ram out on it's own and make it a Rc<RefCell<T>>?!? Now it takes three lines of code to unwrap all the smart pointers to write a single byte of memory?!? And it's slower because we have to pay for runtime borrow checking!

I went down exactly this road. I still use rust and love many things about it, but I've come to the conclusion that writing typical single threaded object oriented code in rust only looks like it works; it's an awful idea in practice.

I think the reason C++ people have so much trouble with rust is the syntax makes it easy to do the things you've always done, but the mysterious borrowchecker tells you no later on.

It is hard to think about program architecture. Most languages don't make you think about it at all, they just let you jam code together however you want and give you the tools to make it work.

That was the biggest shock I had moving to Rust: I couldn't just do what I wanted, I had to figure out how to do what Rust wanted. But I also wanted to learn how to design systems better, so the fact that Rust makes me think deeper about it is an advantage for me. In an OO language, I'd just lazily cobble things together. The code would work, but I would learn nothing.

And some people would rather do things that way. It is very hard to break habits, and Rust basically forces you to do that.

It's hard to implement unsafe patterns in safe language. It's hard like using ASM with Java, because Java is platform independent language, while ASM is platform dependent language. This impedance mismatch causes problems, which can solved by wrappers.

If we are talking about emulator, why not just make clear communication between CPU, RAM, and graphic device? Memory can be split into rows (e.g. by split_at()), so graphic device can take ownership of a single scan line at a time, leaving majority of the memory unlocked. We cannot avoid problem, but we can make scale of the problem much smaller by splitting memory into pages, so CPU can take ownership of pages, it works with right now, while graphical device can work with it own pages.

I can't understand how using split_at() would work...if the CPU and the GPU both have a reference to the RAM, we're still using an Rc<RefCell<>>. If the slice gets passed into the CPU and GPU's run() functions, then how does this magical memory manager know what to pass ahead of time?

>It's hard to implement unsafe patterns in safe language.

I agree with this 100%. And I think that for certain problem domains, rust provides more safety than you actually want.

Split memory into pages. Then create two types: OwnedMem, and SharedMem. OwnedMem will own page(s), so access to memory will require no Arc. SharedMem will implement safe protocol to access memory from different threads using Arc or atomic operations. SharedMem must also implement .clone(), so both CPU and GPU will be able to hold it.

> And I think that for certain problem domains, rust provides more safety than you actually want.

If writing of unsafe Rust by hands is hard for you, then write code in plain C, then convert it into unsafe Rust using crust.

Just define your memory as `Rc<[Cell<u8>]>` (or something wider, depending on architecture) and you're fine, right?

>Actually, a lot of the issues that C/C++ programmers have when they are new to Rust seem to be precisely because idiomatic Rust code (which can help to avoid borrow checker issues) is often in a more functional Scheme/OCaml style.

Well, those are not the issues that concern me, or that most (in blogs/HN posts/comments/etc I've read) consider the hard parts. It's the borrow checker.

Right. But if you use a data-oriented FP approach, then you will often avoid borrow checker issues entirely. It is people trying to apply OOP patterns with lots of mutable state that constantly run into borrow checker issues.

The borrow checker might seem like the problem, but the solution is to learn to code in a new style.

You can easily implement borrowing in C++ classes.

I worked on a large C++ code base (some 15 years ago, before Rust existed) which did this kind of thing: it had references enforcing single ownership that was handed on assignment or passing.

Borrowing was of course done in the usual way, by passing down references (most often const ones).

Rust has lambdas, ADTs, pattern-matching and typeclasses(although not as powerful without kinds). These things alone makes a significant paradigm shift than programming in algol style languages. You can just use ARC<T> for every heap-allocated value and rust will still offer a significant advantage compared to C/C++.

C++20 has all those things as well, except for pattern-matching expected to arrive by C++23. :)

So if it wasn't for the copy-paste compatibility with unsafe C code, there is already quite a few modern features available in the language.

s/fighting the borrow checker/enforcing rules of data ownership/

> In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming.

Most, and perhaps all of the "friction" that the borrow checker adds to exploratory programming can be fixed with comparative ease by adding a few well-placed `.clone()` calls (for immutable data) and/or changing some type declarations to `Rc<RefCell<…>>` - at a minor cost to performance, in both cases. One might think that Rust needs to do more to support this use case, but given the performance implications, this is one example of how explicit can be far better than implicit. Regardless, it's absolutely the case that you can write "ALGOL" in Rust, just as you can write FORTRAN in any language. The code might not be at peak performance, it might even leak memory in rare cases, but it will do what you expect it to do otherwise.

> I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before.

This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts.

Rust is not hard to learn. However, it contains new things that require you to put in the time to learn them. None of those things are as hard as learning, say, recursion or assignment was when you did it the first time. However, unlike switching between other mainstream "algol-derived" languages, there are actual new things you have to learn. If you go into it just pretending it's a cosmetically different variant of C++, you are going to bang your head on every sharp corner until you quit in frustration.

And having those new concepts is the price of progress. The current programming paradigms are not sustainable in a world where basically every line of code you write is going to end up as a part of the attack surface of some system that will, eventually, get attacked.

A junior did an interview with us for a C++ position. At the end he recognized that he had a very superficial knowledge and ask to do the programming test in Java because “programming is programming” (using imperative languages). And then we have developers using C as FORTRAN, C++ as C, Rust as C++... and maybe this will be passable if you are a solo developer but not if you are in a team.

Then add knowledge of the ecosystem :)

> This statement is absurd. It implies that you believe that there are only cosmetic differences between languages, that no language can ever introduce any useful new concepts.

Well, the fact that you've missed the whole "Algol-derived language" is more absurd to me. Rust, in the end, is C++-streamlined plus fighting with the borrow checker.

Not some huge new paradigm shift in how we construct programs (as would be eg. going from C to Lisp or Idris) -- just making the lifetime aspect of memory management explicit and having the coder handle it (in lieu of e.g. a GC).

In an ideal world, Rust's lifetime management would be automatically derived by the compiler (in several cases, when it's simple, it already is).

Which is why I don't consider it some new paradigm of how to think about programs or how to structure programs (like OO or FP or logical programming are).

> Not some huge new paradigm shift in how we construct programs

I think Rust is exactly that. It makes memory safety a first-class concern for the language. Thinking about it as "fighting the borrow-checker" is like trying to program procedurally in Java, only using classes as holders of static functions, and feeling like you're constantly fighting against objects.

> In an ideal world, Rust's lifetime management would be automatically derived by the compiler (in several cases, when it's simple, it already is).

This is exactly the type of work that's gone into the language over the last few years. It's actually quite rare with non-lexical lifetimes (and the advancements before it) that you need to explicitly call out the lifetimes anymore.

I think the language is moving in the direction you want.

> Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.

You've picked a very poor example to repeat that tired old addage. You're using an example of someone who admits struggling with memory management issues who has just started learning a programming language which he doesn't master, and after he grew tired of having the compiler warn him that he was writing broken code he decided to keep writing broken code but this time in a language which doesn't warn him about how broke his code is.

How exactly is this case anything other than someone not knowing how to use a programming language insisting on writing broken code?

I mean, the rationale of switching to another language was quitr clearly how the programmer grew tired of the compiler warning him he was making a series of mistakes, and he prefered keeping making the same mistakes without being bothered about pesky memory access problems.

> in a language which doesn't warn him about how broke his code is.

Can you make a citation from the codebase to back up this claim?

The classes in the various <blah>widget.h headers have members that are plain pointers; that might be one place to start looking.

>Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code.

I have yet to see anyone jump to Rust on first try and fell in love or could immediately use it in production with no problem. There is a huge learning curve involves.

More than often, ( Or pretty much in every case ) They gave up. It was way too complex, they hated it, it was the first time they actually had to "fight" the compiler just to get shxt done.

And then somehow after 3 / 6 / 12 / 24 months later. On 2nd try it clicked.

It wasn't just Rust 1.0 or Rust 1.2 being harder, and the newest version being easier. It is just, dare I say Human Nature? Or you have been learning Rust in your background thread for few months without you even realising it. And once it clicked, everything you hate about it seems to be God Send to programming and software development.

For a lot of people they may never click, after all Borrow Checked is complex and hard.

Oh man this is me with so many things. I'll hear about some new-to-me concept, start reading up on it but get stumped by an avalanche of new information and drop it. Months later I'll get the same bee in my bonnet, but suddenly the same articles I found impenetrable parse cleanly.

That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting.

If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. It's also moved heavily in the direction of some FP concepts which have zero overlap with C and arguably little to do with C++.

The big assumption Rust is based on is that people will recognise the benefits of memory safety and be willing to pay the price for it. Many outside the early adopter group won't be, that's how the mainstream works.

i'd say game developers aren't really the target audience, because they expect to move fast and not necessarily correct, just correct enough most of the time. other developers don't have issues with the compiler being more picky; compile times are more of a problem in adoption than language strictness.

> the friction is coming from the fact that Rust can't be changed any more

The basic language as such doesn't change much, but what the compiler infers and accepts gets extended with almost every release. rustc from 2 years ago is a lot more strict than rustc now. And lots of lifetime annotations you had to do before, you can omit today.

The experience is much nicer and the friction definitely goes down.

Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority.

At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some point automated translation between the two languages will be a thing.

At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures.

But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

C/C++ developers can't use Rust without learning new concepts. That's not a failure. If there were no new concepts, then there wouldn't be any point in the langauge in the first place.

Contrariwise there is huge demand for a language with a trimmed-down set of concepts from C++ and a much improved syntax.

D, Nim, Go.

I am putting my money and hopes on Zig.

> If there were no new concepts, then there wouldn't be any point in the langauge in the first place.

Not so; the same concepts can be clarified and captured in a better set of requirements, leading to better implementations of the concepts.

There can be a point in fewer concepts that are simpler.

> the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to.

What is your proposal, specifically?

It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a magic wand and release an incompatible Rust 2.0 with memory safety and no new concepts to learn over C++, I'd do it. But it's easy to just say you want a new language. It's a lot harder to actually design such a thing.

I generally think that if you want memory safety, you must either have a garbage collector or the mutability rules and borrow check. There is no other option.

Do you think it was obvious that such mutability rules and borrow checks were sufficient before languages like rust were invented?

What about a more impractical approach like e.g. ATS?

Speaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?

Arc is a kind of automatic memory management that's included when people talk about GC in general.

Reference counting is a form of garbage collection.

Yes but this is done at compile-time, not runtime, isn't it?

EDIT: Upon reading some stuff, apparently I am mistaken, and it's got runtime overhead. Silly me.

You're not totally wrong; that's the "A" in ARC: Automatic. It automatically inserts code at compile time, but that code has a runtime effect.

My only proposal is that the Rust community spends more time coding and less time criticising other languages and praising Rust.

Making proposals about the ergonomics of Rust is way overdue, but I will note that jumping through even more hoops to get correct code is not progress, nor the huge victory that the Rust community hails it to be. Humans use compilers to do work for them, not vice versa.

GC for example is brilliant, Swift is also quite nice. Even if neither solution is applicable, they are both excellent examples on how a user-friendly solution can look like - almost zero user effort.

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

Rust ensures that all valid rust programs are safe, but this does not mean that programs that are difficult to express in rust are unsafe.

Consider how future improvements to rust may make some previously difficult to express patterns easier. I think non-lexical lifetimes would be one such example. You could imagine that someone who learned on a future version of rust might be similarly annoyed at compiler errors when working with an old version of rust that's more limited in what things can be expressed and understood as safe.

> . It is im fact the solution, and a solution that's being ignored.

If the coder's C++, that is written in flow without being distracted by borrow-checkers and whatnot, is in fact correct code, then no, there is no solution that is being ignored; what's being ignored is a "problem in search of a solution".

> 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++?

That's a pretty good executive summary of the Rust cheerleading.

In fact, what you describe is sometimes possible. For illustration, let's confine our attention to use-after-free bugs and memory leaks. If we make the free function do nothing, and stick in a garbage collector, then in fact you can write (some of) "your same old memory allocation and access bugs" yet they are mitigated.

I feel the opposite. Strong compile-time checks make it easier to modify a system, and especially make it easier for people unfamiliar with a codebase to contribute. Being explicit what the static properties of a system are makes them easier, not harder, to modify.

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

Hot reloading is the critical feature, and dynamic languages usually have better support for it. (Lisp is a good example.)

Hot reloading doesn’t provide safety guarantees.

Maybe, but hot reloading is very very useful. It is mostly a development time only feature anyway.

I believe we have seen Casey Muratory doing hot code reloading in C++, in his Handmade Hero stream. Compile the dll, reload & test the dll, without exiting the game runtime he's developing.

The Yi editor, written in Haskel, I believe does hot code reloading as well.

The XMonad window manager can be recompiled and reload while keeping your windows up (the configuration file is actually Haskell code).

---

Yes, hot code reloading is bloody useful. It is also perfectly compatible with static typing. I see no good reason for statically typed languages to have worse support for it.

It's only incompatible with Link Time Optimization and changes to static dispatch or structure, but anything that could have exposed as a COM object could be used.

Unloading/reloading modules is perfectly possible, though in my perception relatively less common on Unix/Linux, while slightly more common in Windows land (e.g. DLL plugins, resource/translation containers etc.)

I am probably more of a beginner when it comes to compiled languages. What surprised me most about Rust was that after understanding it, I liked it more than Python. I intended to learn it as a speedier more controlled alternative. A sharp tool to throw at slow code to make it go away.

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!

You can try to use Elixir for scripting instead. It feels "right", after the experience with OCaml, Rust, and similar languages.

I have started to see a worrying trend were developers focus more on how easy it is to develop X rather than how good of a finished product is X.

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.

This. I believe the value proposition of Rust is that it decreases the cost of developing high quality software, much as the value proposition of PHP is that it decreases the cost of medium-quality software. It is not a magic bullet, but requires a nontrivial learning curve. If the goal is safe, performant code, then I think there's a good argument it's worth it. If that's not the goal, then other languages might be better choices.

There are plenty of ways to write a program where, eg. a mutable and immutable reference exist at the same time and there is no memory unsafety. You have to learn to write programs in the way that rustc can prove is safe.

I agree, but let's remember how young rust is, how little experience people have with it and its paradigms and how much they are used to code with c/c++.

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.

I’ve had the opposite experience. Type driven development makes writing code easier, with less errors, and also makes refactoring significantly easier. For those of us where C++ is the optimal choice Rust is a major step forward in terms of better abstraction, safety, and yet maintains the efficiency requirements we need.

Its just temporary pain. Once you learn to use types properly, you stop having to constantly think about typing. I assume Rust pointer ownership is much the same way.

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.

There could be a --i-am-a-stuntman-and-i-spit-in-the-face-of-danger flag, that would disable some checks for compilation to be fast enough. It could be used when building known good packages or during design iteration. It would be an escape hatch.

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.

You're assuming those checks are a real bottleneck for compile times. Rust only does borrow checking at the function level, so it's easy to parallelize and not all that slow. Most of the compile time is spent on code gen, if I recall correctly.

IIUC, for typical programs, most of Rust compilation time is spent waiting for LLVM to spit out results.

There's a plan to use https://github.com/CraneStation/cranelift for debug builds instead of LLVM, which would make them faster at the cost of supporting fewer targets, and producing worse code.

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

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

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.

Rust's contribution is memory safety without a GC, so as a new approach it's somewhat exciting. But for most programmers before Rust and today, memory safety has been a solved problem not worth thinking about because most programmers use a GC language.

I think the assumption that static typing means things take more time requires justification. Usually I see the assertion given from people who naturally take longer getting things to pass compilation just because they're not used to using it. When I use dynamically typed languages I find footguns in undefineds and empty strings where others wouldn't. I also have to write tests - which themselves may have bugs - for things that static analysis could do on its own. Why use expensive dev time for this instead of cheap CPU time?

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

That's true. Different projects require different quality. The projects I'm working on are tolerable to bugs. I just need to know that bug happened (from logs or user complaints) and I need to fix a bug in a timely manner. I don't need to produce bug-free code. I don't need to produce fastest possible code either, servers are seriously underutilized and there's a lot of CPU and memory. I'm using Java because that's what I know well. I like Rust idea, I'm tinkering with it because I'm kind of perfectionist and I like Rust approach, but I won't apply it to my current work in foreseeable future. Even switching to Kotlin from Java was a hard call, because so many people don't want to learn anything new and I can't really blame them.

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

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

That’s not necessarily a fair point to compare. Perhaps it just feels like that because C++ has been around for a long time. If you write production code without being a C++ master, you also have different struggles before getting it right.

> capacity to change

Good luck making changes to a 100kloc Python codebase.

You could perhaps start by adding type annotation. They are not perfect, but they help.

Too little too late.

If you have good manners, Python codebases can easily grow over 100kloc mark. Static type annotations, using descriptive variable and class names, type checks on user input(esp. libraries) makes growth safe and simple.

That’s a good observation, thing is, Rust just makes the manners mandatory.

No problem. I do it every day.

Alright, now dive into a new codebase and report back.

I do something similar daily, and it works fine, as we have a strong test suite.

You can't disassociate dynamically typed languages from (strong) test suites, so one needs to qualify:

> Good luck making changes to a 100kloc Python codebase without test suite

versus

> Good luck making changes to a 100kloc Python codebase with a good test suite

In context, the first case is no different from "Good lucking making changes to a 100kloc Rust spaghetti-coded codebase", and one can't meaningfully judge a something based on a poor use of it.

> In context, the first case is no different from "Good lucking making changes to a 100kloc Rust spaghetti-coded codebase", and one can't meaningfully judge a something based on a poor use of it.

It's not the same. Type system provides certain guarantees. Also it's much harder to write spaghetti code in Rust.

did that on 50k code base with the help of runtime automatic type annotators (e.g.https://github.com/Instagram/MonkeyType) it's absolutely doable, it took a few days total.

Static checking burdens the developer with thinking more, etc. -- for sure.

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

> In otherwords: the unable are often snobs.

Oh the irony.

You'll find no value judgement in my comment.

There are many axes of intelligence, as well as of human value in general. I only said that comfort-with-abstraction is one axis on which people vary -- and I'd say that's exactly what the previous comment relies upon.

All it says is "this is needlessly hard", the only reply can really be: yes, for you.

I was offering an explanation of why that is; or else are we really saying that this "hardness" is universal?

One of the more important characteristics of a developer is pragmatism which has zero covariance with comfort-with-abstraction. And so, why not value those who have that more?

That is, to be better at abstraction isnt to be a better developer. It is only to be better at one sort of development. Equally, to have more pragmatism is to be better at a different sort.

There's no snobbishness in my comment, only in a person who reads into it a value judgement about this specific form of intelligence.

Why read that into it?

> Static checking burdens the developer with thinking more, etc. -- for sure.

I'm not sure I agree. Most type languages as implemented in common programming languages are bad at describing abstraction. This means that if you're programming in one of these languages, you are forced to reduce your level of abstraction (which is sometimes touted as an advantage).

And just because someone's smart enough to find working out how to satisfy the type checker an enjoyable challenge, doesn't mean they're dumb enough to think that just because it's fun it is always a good use of their time.

If you want to build the best code, you want it to be fast, correct, and maintainable.

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.

Rust doesn't make much sense for this kind of project in the first place. You use it for things that need to be memory correct, and proveably so. Very useful for handling uncontrolled data.

Do you use a text editor that highlights errors inline or do you depend on errors in the terminal? Maybe your frustration stems from a lack of tooling.

This was my impression as well when I tried Rust - always fighting the compiler. None of this happens with D. You just code away and keep being productive without the annoyances of C++. In fact C++11 and 17 are less and less annoying.

I believe you’ve not been on the receiving end of a 17 page compiler error while trying to compile a template heavy app, because you forgot to put an &.

The important part is to realize _why_ you’re fighting the compiler as it’s trying to make _you_ write better code and improve.

If you find non issues being reported by the compiler please report it and make it better for all of us too!

> as it’s trying to make _you_ write better code and improve.

It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both.

Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining linked list with hash map. Rust implementation is more than 1000 lines of code, many of them are unsafe: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li...

I never wrote production code in Rust. But based on my limited experience, the language is fine for projects that have few data structures, or they’re simple so you can stick to library containers, and a lot of code processing them. For many practical problems it’s quite the opposite.

> Even without trees, consider a simple LRU cache structure. Trivial to implement in most languages by combining linked list with hash map. Rust implementation is more than 1000 lines of code, many of them are unsafe: ...

in this context, criticizing using unsafe in rust and comparing that to C++ is comparing apples to oranges. GC languages aren't even worth mentioning here.

> It’s not necessarily an improvement. When an algorithm processes complex data structures organized in graph or tree, no amount of better code allows to easily implement that in Rust. It’s either slow, or unsafe and hard to implement, or both.

here's the thing: all of the above are true in other languages, C/C++ included, it's just that no compiler besides rust will warn you that recursive data structures are hard - it doesn't matter if implementing them is easy, proving they're implemented correctly never is. rust tries to help you prove you did the right thing and it needs assurances (unsafe) where it just can't do that. C++ is all unsafe.

> criticizing using unsafe in rust and comparing that to C++

In that comment I was mostly criticizing the amount of code. That code doesn’t need to be written in C++. std::list has stable iterators so you can put list iterators to the hash map. This way LRU structure becomes a trivially simple wrapper over std::list and std::unordered_map containers.

Note how Rust developers implemented custom linked list on top of raw pointers, doing manual memory management with Box::into_raw(Box::new(Node::new(k, v)))

C++ implementation doesn’t need a single new/delete, hence much safer than unsafe rust. LRU cache is simple, not too hard to implement correctly in C++ just because it’s very few lines of code.

> it's just that no compiler besides rust will warn you that recursive data structures are hard

In GC languages like C# or Java it’s both easy and safe.

In C++ they can be challenging to implement correctly, but because it’s all unsafe, I get huge amount of help from all levels of the stack. OS debugger, C runtime, C++ standard library, compilers, they all evolved for decades trying to improve life of developers like me writing unsafe programs which use raw pointers. You can implement a recursive data structure without a single new/delete, relying on standard collections for memory management. It doesn’t guarantee pointer safety just like unsafe Rust doesn’t, but at least no need to worry about memory leaks.

> proving they're implemented correctly never is

Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors.

Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them. Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for.

Your argument doesn’t make much sense. You can use unsafe and raw pointer to do EVERYTHING you can do in C/C++ and it will be just as safe as you write it in C/C+. And then, you can (ab)use the type system to make sure you or your team cannot use it in the wrong way.

why would i use rust in the first place if i was disabling the borrow checker? isn't that the main selling point?

because of the ecosystem? because it's easier to hire rust programmers than C/C++ programmers, or get more open source contributions from rust vs C/C++? unlikely with a learning curve or community like that.

Rust only disables these checks very selectively.

The idea is good, MS did same in C# since the first version in 2002. Allows to do pointer arithmetic when you really need to, for performance or native interop.

What I don’t like about Rust is they use unsafe to workaround language limitations.

In C# I have only used unsafe code couple times over the course of 20 years. The standard library doesn’t use unsafe code either, at least in modern .NET all these collections are 100% safe code. The main, safe subset of the language is good enough for the majority of practical applications.

In Rust there’s tons of unsafe code in standard library, substantial amount of unsafe code in third-party libraries, and if your software is complex enough, your own code will likely contain usafe as well. This causes safety issues: https://medium.com/@shnatsel/how-rusts-standard-library-was-...

One of the reasons the standard library has a lot of unsafe is that the standard library is small, but one of the criteria for being in the standard library is “uses a lot of unsafe.” We’d rather these things get massive visibility.

In all my years with Rust, the only unsafe I’ve needed in any of my applications is when doing FFI, and my toy OS. YMMV.

On the other hand, Rust certainly could use a lot less unsafe in the standard library than it currently does. It just doesn't want to.

> and it will be just as safe as you write it in C

C++ standard library containers have guarantees about iterators and pointers invalidation, e.g. std::list never invalidates any of these, unordered_map invalidates iterators when rehashed and never invalidates pointers to either keys or values. This allows building unsafe data structures on top of standard collections, and then compose custom unsafe data structures on top of each other.

This makes C++ both safer (at least from memory leaks) and easier to use compared to unsafe rust.

> Let's be clear: Rust is still far away from formal verification; the borrow checker won't save you from logical errors.

completely agree.

> Second, data structures like graphs, trees, hashmaps are well understood and have a lot of algorithms built on top of them.

well understood, yes, by authors of textbooks and papers. your average programmer may have understood them once, before he made it to the enterprise and started passing buckets of bits between http endpoints for a living.

> Algorithms with a lot of research behind them, and complexity analysis. While complexity analysis doesn't always equal performance, if I can't use these universal tools in your language, I'll probably think of it as a toy language which stops me from getting stuff done, which is still what most of us are paid for.

you can write a recursive data structure in Rust in the same way you'd write one in C++ - use unsafe pointers, even the asterisk is the same. nothing is stopping anyone from doing that, in fact there are lots of examples on crates.io and in the stdlib.

Being able to use more D would be nice! But the binding issues remain the same there. There recently was talk about having the D compiler emit C++ headers for exports from D modules automatically. This would be an instant killer feature for me.

dpp is en effort that allows to include C++ headers, also there is ongoing effort to link with C++.

https://github.com/atilaneves/dpp

Yes, dpp has issues with C++ constructs according to its readme unless that changed recently. I am talking about the inverse: have dmd generate a C++ header automatically for extern(C++) declarations during compilation. This was discussed quite recently.

I agree D has much better onboarding for C++ programmers, but that's because it's similar, not because it is particularly easy to learn.

Fighting which stops eventually. I program Rust for nearly a year now and I found that there is a point where it gets quite smooth. The many mental guarantees that the code gives you can help you a lot to stop worrying about a whole class of things. I realized just how much this is the case when I wrote something in Python again and separation of which code affects what and which code is doomed to fail from the start became much harder.

Rust initially has been a lot about fighting the borrow checker, but once you get the hang of it it happens quite often that you write pages of a complex functionality including tests – you hit build and it just works.

I am certain that Rust prevents entire classes of problems I filed bug reports for, even with extremely experienced developers. I understand that the nagging voice of the compiler or cargo clippy is not just for everyone, tho.

I'm 100% with you.

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.

You can still write hacky temp code in Rust, although it does take some experience to get familiar with the ways you can do this without hitting borrow checker errors and etc (well, short of reaching for unsafe, which is generally not a good way to do this).

That said, for getting code written fast, Rust for me has been better than C++ for a while now, even though for most of that I was better at C++ than Rust. The reason for this was largely Cargo, which eliminates the pain points of dependency and build management that plague C++.

Reply on news.ycombinator.com