Hacker News Reader

Comment by _448 | Hacker News Reader

Very thorough write-up, and an objective comparison.

I would like to mention my subjective concerns for Rust. I hope the Rust community can think me as a canary who is from the C++ world. I am desperately looking for an alternative to C++, and I am a mid-weight C++ programmer. And here is what Rust could face down the line (remember, in early days C++ too was a grockable language and hence its popularity):

0. Rust's C++ problem: Learning curve. From the get go if there is murmur that Rust has a learning curve then think what will happen when Rust reaches the maturity of C++.

1. Rust's NPM problem: supply-chain. If I decide to use npm, and use the npm toolchain to download a project then to my horror it downloads god knows what. Lots of dependency hierarchies, some of them have not even reached 1.0. This raises the concern for supply-chain attacks. Rust with the aim of "boosting developer productivity" just decided to follow the path of all those who are susceptible to supply-chain attacks.

2. Rust's Haskell problem. Haskell is a very beautiful language. Even then it has not reached the level of adoption of other popular languages. It has nothing to do with the language, but some in the community who have a tendency to project a coolness level by saying something like "A monad is just a monoid in the category of endofunctors". What that ultimately does is alienate lot of software developers. Early Rust evangelist tried very hard to project Rust as having a very welcoming community, but if acronyms and terms from category theory and lambda calculus, that are alien to most developers, are thrown around without taking into consideration the larger development community then I fear that Rust will go the Haskell or OCaml way i.e it will become a niche language with small community.

Just 2cents from an average everyday software developer.

View on HN

I appreciate your comments, but I think the things you worry about aren’t that bad in case of Rust.

Not every language evolution is a cautionary tale. Java, C#, PHP, JS have grown a lot and are fine.

Rust’s learning curve is not from accidental overgrowth of complexity (e.g. it has two+ string types not because of legacy, but because it needs different kinds of ownership). Rust has editions that make its evolution less constrained by backward compatibility, “how are we going to teach this?” is a mandatory question for every language change, and Rust has exceptionally helpful compiler errors.

Rust has some tooling for managing supply chain risks - vetting dependencies, vulnerability scanning, vendoring, etc. C++ doesn’t have any special security model or other solution that Rust lacks to make dependencies safe, only pain and annoyance that makes people avoid using dependencies. So it’s unclear what Rust could do better here.

Rust projects tend to split themselves into multiple small crates, so “lots of dependencies” in Cargo isn’t as heavy and reckless as same number of C++-sized deps.

Rust has already broken out of being a niche language.

Naming things is hard. Rust has some less common features and needs to refer to them by some name. Sometimes it borrows terms from other languages (like enum instead of a sum type), but sometimes there isn’t a common word for everything. But jargon isn’t the same as elitism. I do worry Rust will grow and have Eternal September eventually, but so far it’s welcoming for beginners, even if it needs to explain awful acronyms.

> Java, C#, PHP, JS have grown a lot and are fine.

Kind of, Java 20 and C# 11 have lots of interesting material for job interviews and pub quizzes that I bet random joe/jane developers will fail at.

I am mindly aware of them, because alongside C++, they have been my main tools for the past 30 years (rounding to the oldes one), and I surely would fail as well.

Small crates is not a benefit wrt. The wrong 3 lines of code in crate is all it takes to be owned, regardless of whether the crate is 100 lines or 100k lines. Large number of crates and developers is a negative, because one needs to trust or review all of them.

I don't really understand this line of thinking. The C++ method of "avoiding" this problem is to shove things into mega-libraries like Boost, or copying and pasting code. If you need the functionality, would you rather review 5 focused libraries, or Boost?

Copying and pasting code is equally do-able in both languages.

Boost -- it has a development process and has a proven track record. Those five focused libraries, times 30 other deps becomes 150 different developers to possibly vet. Anytime any of them can pass on the project to someone less scrupulous.

You should also keep in mind that a lot of Rust library developers release many individual crates from within the same project, inflating the crate count somewhat.

> Not every language evolution is a cautionary tale. Java, C#, PHP, JS have grown a lot and are fine.

I find it very weird that anyone would think that any programming language is even remotely fine. Everything is a mess, there are terrible compromises to be made everywhere between expressivity, readability, build-time performance, run-time performance, safety, language community, etc etc. A language will be "fine" the day there's no compromise to be made anymore and it outclasses everything else before it on every metric relevant to shipping good software fast to end user while enjoying the process.

I think you're confusing "fine" with "perfect."

Fine is a synonym for "satisfactory" or "acceptable."

"Fine" in programming specifically, usually translates to "I can use it to solve my problem without the flaws in it inhibiting me from doing that" or "I can forget that I'm using the tool and just focus on solving the problem."

Many things in the world are "fine" by this definition. That doesn't necessarily mean they're all good, let alone perfect — but they're fine.

Can you give an example for #2? I picked up Rust this year and never found that to be the case. In fact Rusts type system is extremely clear to me and was pretty straight forward coming from a Python world. I don't think I ever encountered anybody quoting Category theory at me.

I used Haskell for a few years and the main problem with it is that to do anything you need to use Monads, Functors and a lot of complex types. It's a requirement to even write the most basic program. "strange" functional stuff proliferates haskell like `foldl` and `foldr` and a extremely discouraging Lazy computation model that makes it almost impossible to know what the compiler will do unless you have a near perfect comprehension of all the language.

Rust to me is as simple as writing annotated Python or Typescript, with the only addition that a beginner needs to know is that there is a new option that those two languages don't have which is pass by reference or pass by value. The lifetime stuff was really easy to get, "pass a value into a function, can't use it anymore."

The Rust compiler gives extraordinarily useful error messages. I don't know if haskell improved but you can end up with some very strange stuff to figure out.

The only real hiccup I had when learning Rust was that going from `sync` to `async` code had a bit of a learning curve. It was simple for basic stuff, but the problem were that Future's have their own Lifetime that depends on every piece of data used in the computation between `await` calls. This means all your data needs to be Sync + Send if you want to use Async.

> the only addition that a beginner needs to know is that there is a new option that those two languages don't have which is pass by reference or pass by value

I think anyone who's done anything beyond beginner JavaScript is going to understand the difference between pass by value and pass by reference, even if they don't call them that?

    function foo1( val : string ) { val = "hi" }
    function foo2( val : [string] ) { val[0] = "hi" }

    const bar : [string] = ["yo"];
    foo1( bar[0] );
    console.log( bar );
    foo2( bar );
    console.log( bar );

The big difference when I use Rust is that in Rust every variable you accept in a function requires you to make that choice. Whereas JS it’s kind of chosen for you. In your example you had to go out of your way to do it. So just a bit more mental overhead for implementing libraries. But not a huge deal.

It is not just the abstract knowledge of the difference, but the fact that "let b = a" makes a undefined and, especially, some comfort with a Rust-ic way of dealing with this. My 2c.

  > I think anyone who's done anything beyond beginner JavaScript is going to understand the difference between pass by value and pass by reference, even if they don't call them that?

Pass-by-reference is a concept that is unfamiliar to many (most?) modern JS/TS developers, as the common idiom is that you "return" a new object or value at the end of your function.

If you want to update a value in an existing object, you pass it by value and return a clone of it with the updated values

Performance doesn't matter, you can do the most pants-on-head-stupid thing you can imagine, or have your frontend page/component be re-rendering 20 times on every state change, and it makes no perceptible difference. (This has been my experience)

It wasn't until I learned C that I realized you might even program in this fashion (somewhat to my horror) where passing variables to functions could mutate them

> It wasn't until I learned C that I realized you might even program in this fashion (somewhat to my horror) where passing variables to functions could mutate them

If you pass an array to a function in JavaScript, then any changes you make to it will mutate the version the caller has.

Some Rust programmers, when faced with performing operations on a sum type (like Result) or container, tend to reach for point-free map-filter-reduce code stuffed with higher-order functions, lambdas, trait generics, and return type inference, requiring looking up the documentation or implementation of multiple helper microfunctions, and asking the compiler for the inferred return type. My preference is usually to write imperative code matching over objects or looping over iterators, except in cases like "minimum of list" where the loss of clarity of a loop exceeds the loss of clarity of a reduce() method call.

Separately, to express code which creates multiple non-const references into a single object (trivial in any other imperative or OOP language), you need compromises like verbose Cell, overhead RefCell, ugly and footgun-filled UnsafeCell and raw pointers, unsafe confusing (and currently unsound, see https://github.com/rust-lang/rust/issues/63818) Pin, or experimental ghost cells (https://plv.mpi-sws.org/rustbelt/ghostcell/paper.pdf, not sure the current implementations).

YMMV but I personally have never faced either problem having written tens of thousands of lines of Rust at this point. But to be honest I never worked on a large team of Rust engineers.

One of the benefits of Rust is that it gives you an option to switch to imperative style if thats what you choose which isn't the case for Haskell or purely functional languages.

Tacit programming was never a problem as the IDE does a pretty phenomenal job of telling you the types anyway. If the IDE can't figure out the type, the compiler won't either.

non-const references in a single object can simply be solved by making the whole object mutable, which is essentially what Python et al. do for you anyways.

I never had to use any unsafe code or pointers. Not sure if that way of thinking is carried over from C and C++ engineers. The only time I think I use Cell or the like is if I have a global static variable that I need to fill in at runtime. But that is more of a code-smell for most or at best a more advanced programming design that beginners don't need to worry about.

The best way to solve the last problem is to understand your data model from the start and make what objects need to be mutable mutable.

To be fair, this kind of thing even happens in JavaScript. Some use functional programming with immutable datastructures, higher order functions, super generic code, using some niche FP library with its own idiosyncrasies - when simple and imperative would do just great.

> Some Rust programmers, when faced with performing operations on a sum type (like Result) or container, tend to reach for point-free map-filter-reduce code stuffed with higher-order functions, lambdas, trait generics, and return type inference, requiring looking up the documentation or implementation of multiple helper microfunctions, and asking the compiler for the inferred return type. My preference is usually to write imperative code matching over objects or looping over iterators, except in cases like "minimum of list" where the loss of clarity of a loop exceeds the loss of clarity of a reduce() method call.

More and more, I find this is just a general problem and not a rust specific one. Any language with enough syntax flexibility will have a group of programmers that try to treat the language like lisp or haskell. (I recently ran into exactly this with a typescript lib I've been working with).

C++ is no stranger to this problem, it's famously the reason Java doesn't have operator overloads.

What I'm also finding is that complex style of programming is annoying to find in the company code base, but is rarely one that catches on in the ecosystem as a whole.

I know for myself, I overdid it at times as I was learning the trade offs.

Where I've currently settled is simple map/filter operations to tweak things into a more readable state are better than the more procedural approach. Also keep to simpler combinators (e.g. no `map_or` / `map_or_else`). If things become too complicated, be procedural. If there are side effects, be procedural.

Another way I have for framing it is the code layout (files, functions, blank lines, newlines, indentation) should be used to highlight the business logic. Early returns, `?`, post-fix combinators, etc should be used to reduce boilerplate that detracts from the business logic.

> If there are side effects, be procedural.

Yep! That's why Iterator::for_each https://doc.rust-lang.org/stable/std/iter/trait.Iterator.htm... is more often than not a code smell [0]; it exists mostly for the sake of writing side effects in functional style.

So something like

    something.map(|x| ..).for_each(|x| do_something(x));

Should probably be written

    let iter = something.map(|x| ..);

    for x in iter {
        do_something(x);
    }

It's still okay to use Iterator::map and other iterator combinators, but using for instead of for_each here is probably easier to read.

[0] One exception is in the documentation "In some cases for_each may also be faster than a loop, because it will use internal iteration on adapters like Chain."

Can you give an example of that? Do you mean something like, using .map() and .map_err() on Result?

I can't imagine myself not using those methods; they make programming much more enjoyable, and should be considered elementary as of 2023.

(Note: about .map_err() specifically, error conversion is kind of important in Rust; it's usually performed automatically by the question mark operator but sometimes you need to do it explicitly, and doing so without .map_err() usually obscures the intent of the program for no gain in simplicity.)

> Separately, to express code which creates multiple non-const references into a single object (trivial in any other imperative or OOP language),

So multiple mutable references to the same data? I'm personally happy that's harder to do in Rust, as it enables anti-patterns like God Objects [1] and spooky action at a distance [2].

I don't like the "you're doing it wrong" response when people point out flaws, and that's not what I'm trying to say here. You can write perfectly fine code with remote mutation. This is just one example where the things that Rust chooses to make harder are also the things I have a harder time understanding.

I'll also agree that remote mutation is still necessary for some important use cases (e.g. testing, memoization). Then you have the `Cell` / `RefCell` escape hatches. Rust is pragmatic about such things.

> you need compromises like verbose Cell, overhead RefCell, ugly and footgun-filled UnsafeCell ...

The actual need for these constructs tends to be rare in my experience.

We have tens of thousands of lines of Rust in our codebase and ~five instances of these wrappers. They're really not hard to avoid. And actually, looking through the results here, I've found a few cases we actually _shouldn't_ be using `RefCell`.

> unsafe confusing (and currently unsound ...) Pin

This is a fair point. `Pin` always felt to me like a compromise to get async out the door. The best thing I can say is it's proof that the Rust team is willing to not let the perfect stand in the way of the useful.

But I'll concede it still is difficult to understand and complicates the async picture. This is definitely an example where Rust's underlying philosophy makes things that should be easy harder.

1. https://en.wikipedia.org/wiki/God_object 2. https://en.wikipedia.org/wiki/Action_at_a_distance_(computer...

> 0. Rust's C++ problem: Learning curve.

For Safe Rust this feels pretty OK to me. You're much closer to the Java world where not understanding properly leads only to unnecessary performance overhead, than the C++ world where it's maybe going to catch fire for seemingly no reason if you misunderstood.

A Rust beginner is just as likely to make sub-optimal choices as a C++ beginner, but it's far less likely that to their astonishment their program explodes messily. Suppose I have a Bunch of Clowns, I want the six funniest Clowns, in both languages the beginner is likely to try to sort all the Clowns by how funny they are. But actually in both languages we can and (optimally) should tell the algorithm we only care about six, it needn't sort the 7th and subsequent Clowns at all.

But in Rust if the funniness of a Clown is a floating point type, the programmer is obliged to explain what they actually mean to happen here†. Floating point types can be NaN and we can't "just" sort NaNs as if somehow not-a-number is comparable when the whole point is that it isn't! In C++ the standard actually does say, deep in the ISO Document, that you can't sort NaNs, but you won't be warned about that it just silently makes your C++ program Ill-Formed.

† "It's OK, Clown funniness is never NaN" is a reasonable thing to believe but Rust will make you write that assumption into your program code.

well, ok but isn't it more likely that we want the clowns sorted in funniest order? and if we actually unlikely event do need a collection of the top six, we can write a collection to do that.

Suppose I have a million clowns. Even if I want the funniest six in funniest order the optimal way to do that is to ask first to partition just the six funniest, and then sort those six finally. Sorting the other 999_994 clowns is pointless for this task, and will waste the vast majority of our run time.

so, as i said, possibly write a specialised container to do that. but you are still going to need to read the million clowns, so maybe (i haven't investigated this) the best approach is to read the clowns, which you have to do anyway, and then see if they can be inserted into an array of the currently highest funniest (though i would never see clowns as being funny). i don't remember saying anything about sorting to solve this specific problem, only in the general case - perhaps i did not make this clear.

0. Learning curve is not even remotely close to C++ and all it's gotchas. And it will never be so. What has to be explained in every one of these threads, Rust is becoming EASIER to use with time not more. New releases make the std nicer and they remove language limitations.

1. Plenty of tools to keep track of your dependencies. It is also entirely possible to go it your own way and keep dependencies very low. You just have to implement more things yourself. Dependencies don't just insert themselves into your code on their own.

2. I don't even understand what you mean. Rust has a ton of very good resources to learn from coming from all knowledge levels. You can also use Rust at an entirely C level and only use as many advanced abstractions as you are comfortable with.

Are you sure about 0 when Rust is 40 years old?

C++ in 1993 was also quite easy to learn.

Have you read past the first sentence?

Surely, the other points don't address how Rust will look like when it reaches 40 years of language evolution.

I recall that each revision of C++ is there to make the std nicer and remove language limitations. The problem is always backwards compatibility. What makes Rust different?

Another 2cents from another average everyday software developer that has been lucky enough to work with Rust professionally for the last two years:

Learning curve. Yes there is one. I dare to say lower than C++ though. Getting up snd running with Rust to do build clis, small web servers, python extensions, wasm for the web is not any more difficult than with C++. I think there is a lot to say for incremental learning with Rust. You can forget all about lifetimes (almost). You do need to deal with the borrow checker my in my experience developers get it. I think the Rust community has done a great deal of fantastic work on this "step learning curve". It will never be pythons, but if you are comparing to C++ then then... Hey, I think it might be easier!

As a Rust learner (for 1 year already), I can confirm that these are legitimate worries. Learning curve can turn many away, and supply chain can be attacked as well (I haven't met any mentions of security checks of crate updates to prevent them). #2 is, I think, part of #0: when you learn the language you meet a good deal of new terms -- though not acronyms -- they're significant, but you're not yet able to gasp all of them, it takes some time.

But I haven't seen outright hostility in the community.

BTW, we had a discussion about monads in Rust forum, and I pointed at this same self-referential definition.

0 is real and people discount it a bit too much, 2 is kind of imagined. Every language has its jargon that is alien (for example in C++ RAII, SFINAE, "rule of 5" "move constructor" etc). Rust does borrow some language from other ecosystems but I don't think it's fair to say it's a problem or used to "project a coolness level." Jargon is used to describe specific technical details, it always sucks but it's also necessary. If you don't understand it then circle back to the 0th problem, which is the learning curve.

As for problem 1 (and I say this as a professional rust developer and shill), it's extremely serious and people in the ecosystem do not seem to care enough about solving it. You can steal login credentials and SSH keys by typosquatting today, and all a user needs to do is open an editor. I get why the solutions pitched are not implemented, but it's troubling that major companies are investing into the ecosystem and consuming from it but not securing it.

I can understand that category theory is alien to most developers, but lambda calculus? Isn't it similarly basic knowledge in CS as Turing machines, finite state automata etc?

Why do you assume that all developers have studied CS?

sigh

Do you really think this or are you just projecting elitism?

Most developers have never even heard of lambda calculus.

i wouldn't say that lambda calculus or turing machines have ever been part of my programming toolkit (i do know what they are), and i wouldn't expect say a new programming hire to know much at all about them. FSAs are a bit more useful, but you can get an awful lot of development work done without direct knowledge of them.

I got a bachelor's in CS and never learned lambda calculus.

Same. Turing machines and FSA yes, lambda calculus no.

Nope, I'd say 90% of developers globally would not know lambda calculus. And in non-functional languages when was the last time you had to consider the differences between Beta and Eta conversions/reductions when writing a Django SaaS? Or a Java Swing GUI?

Software engineering != Computer science

Lambda calculus is not a required class in my university in either CompEng or CompSci..

Formal theory of computation (finite state automata etc.) was also a higher level elective that depended on your concentration.

I’m a pretty good C++ developer and have been trying to use Rust for a new project.

The good:

* Cargo! It’s amazing, thank you.

* Portability. The build model is the same between different platforms; all the time I waste managing multiplatform builds with C++ instead goes to coding.

* Libraries. C++’s stdlib has gotten a lot better, but it still can’t parse json or make web requests or create zip files.

* Community. The vibe from docs and blogs and videos is good, cheerful and optimistic.

The bad:

* The borrow checker. Memory safety is great but there are plenty of memory-safe designs that the borrow checker complains about. With modern C++ and sound design techniques, memory safety is not something I worry about much in my C++ projects, and the static analyzer proves me out on that. In particular, a typical application design involves some variation of the Observer pattern (implementations can vary wildly), where views read/“observe” models owned by controllers. Why should I beat my head against the wall with a systems language? There should be an escape valve that doesn’t sacrifice memory safety.

* Documentation about the borrow checker and lifetimes. The Rust book tries to treat this in an approachable manner, but I just wind up more confused; I don’t think it can be treated casually and as such I’d like to have a very thorough and detailed description of what -exactly- is going on with these language elements. If Rust’s going to be a systems language, it’s going to need to get comfortable describing what’s happening precisely.

* dyn. I love templates, static polymorphism is great. But sometimes you need runtime polymorphism. Rust treats dyn like a second class citizen.

* Arc<Box<Foo>> ugliness. Heap-allocated reference counting is a useful thing sometimes. I know Rust doesn’t prefer it, but Rust’s FTFY attitude here is annoying.

* Where are the functors??!?!? Lambdas are great and all, but I can’t create unbound trait/struct functors and then invoke them on strict references later? This is a huge limitation in runtime flexibility for application development. Boost::function and boost::bind worked with VC6 twenty years ago! When I realized Rust didn’t have functors, I became much less interested in the language.

* No function overloading. This is just silly and onerous. Rust could create sensible restrictions to avoid ambiguities and C++’s ADL/type coercion complexity but there’s nothing ambiguous about having two functions with different arity sharing the same name. The hardest problem in CS is naming things, and Rust’s lack of function overloading makes it harder still.

In general, Rust seems a whole lot less expressive than C++, and the claims that these restrictions are sacrificed for memory safety are bogus. Nothing above involves pointers and reinterpret casting and void*.

I'm by no means an expert, but I don't see a lot of your "bad" points, they mostly seem like gripes about not being able to use Rust exactly as you are used to in C++ as opposed to pitfalls of learning the Rust way and doing it with Rust patterns, which would be true any time you move from one language to another.

This is a pretty common complaint from people who have used C++ forever and don't want to give up their design patterns when learning a new language. "Not expressive" is self-serving way to say alternatively "I can't write my OO soup" or "I don't care about safety in my C++ code", which are both evidenced in the OP's comment.

I care about safety in my C++ code, thanks. What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix.

I've certainly seen truly awful C++ codebases, full of undefined behavior and stack and heap corruption. It's possible to write very bad unsafe C++ code; it's also possible to write safe C++ code without much difficulty.

As far as design patterns: fair point that design patterns and idioms may be different in Rust but... what are they??? Fundamentally, in an application, some parts are going to read some data while another part owns it. How does that work in Rust? I haven't seen good answers yet. With procedural information processing utilities those concerns don't come into play as much, but I'd love to read about the architecture of well-functioning Rust GUI app.

> What I'm saying is that all of the boogeyman stories about terrible C++ code generally don't apply to modern C++ if you work within its idioms -- memory corruption bugs are few and far between, and easy to find and fix.

I think people are increasingly frustrated by this refrain, because there's empirical evidence that suggests otherwise. Now, it's entirely possible that you are starting greenfield projects with only super senior engineers in domains where a few safety critical bugs just don't matter, and in that case the learning curve required for memory safety just isn't worth it. That's a business decision you can make, and I wouldn't judge for a second. There are always trade-offs in engineering. However, "I don't write bugs" just isn't credible in 2023. I'm sorry if this seems uncharitable, and I appreciate that you're making a more qualified claim, but safety is not a "boogeyman."

> I'd love to read about the architecture of well-functioning Rust GUI app.

GUI is certainly a still developing area in Rust and has a long way to go. It's easily the weakest part of the ecosystem. That being said, it's still totally possible to build GUIs in Rust. The most common architectural pattern would be the Elm architecture, which avoids many of the issues of ownership that more traditional OO patterns introduce. I've also had a lot of success recently using immediate mode libraries, although obviously this won't work for every application.

> Libraries. C++’s stdlib has gotten a lot better, but it still can’t parse json or make web requests or create zip files.

... but rust cannot do this three things either from just the stdlib? I don't see anything related to requests, json, or zip files in here: https://doc.rust-lang.org/std/#modules

otherwise if you can install libraries, json, zip and web requests are just one vcpkg / conan dependency away in C++ too - and if you want to limit the amount of dependencies you can just use boost which in 2022 does support json and web requests, and can compress / decompress gzip (not zip though :/)

I've said many times that C++'s tooling is a dumpster fire of epic proportions. No-one that wants to use the language should have to spend a non-trivial amount of time a) downloading a build system in addition to the compiler and linker, and b) reading the docs of the build system they've chosen.

It's the compsci version of Hawking's quote 'for every equation I include in this book, I'll lose half the readers' (or words to that effect). For every extra line of setup, you lose some of your potential audience.

Just setting up C++ tooling requires non-beginner level skills.

Concur. I love C++ and I hate this aspect of it so much.

> setting up C++ tooling requires non-beginner level skills.

I've taught C++ beginners to use a C++ compiler, linker and make with no problems, and earned quite a bit of money while doing so.

You are right. I have spent a lot of time tinkering with build systems on sizeable projects to be sure I do not want to do it myself.

But why would any beginner do not do the same thing that Rust offer: use one written by someone else? It does not have to be special or even open. Beginner needs one that they can learn from other people around them. Most of corporate ones are not even documented. People onboard by watching over a shoulder how it works xD.

> * The borrow checker. Memory safety is great but there are plenty of memory-safe designs that the borrow checker complains about. With modern C++ and sound design techniques, memory safety is not something I worry about much in my C++ projects, and the static analyzer proves me out on that. In particular, a typical application design involves some variation of the Observer pattern (implementations can vary wildly),

Don't you still have Iterator invalidation to keep track of and I thought I saw posts regretting using `std::string_view` because it is easy to reference deleted memory.

Anecdote: I maintain a template language library for Rust. I saw the potential for it to speed up if I used more borrowed data (like `&str`, Rust's version of `std::string_view`). I gave it a try and once it compiled, it just worked without crashes. I reflected back on if this was in C++ and the conclusion I came to was that maintainable code is a much higher priority than performance and that any future change in a similar C++ code base would require global analysis to make sure it was safe, making the performance gains not worth the lack of maintainability. In Rust, its been trivial.

> Where are the functors??!?!? Lambdas are great and all, but I can’t create unbound trait/struct functors and then invoke them on strict references later? This is a huge limitation in runtime flexibility for application development. Boost::function and boost::bind worked with VC6 twenty years ago! When I realized Rust didn’t have functors, I became much less interested in the language.

The fact that you can't `impl Fn` bothered me for a long time. It was one of the many examples of where Rust felt unfinished.

Recently, I've seen an inverted pattern for this, define a trait and `impl MyTrait for Fn`. I've found I much prefer this pattern over the cases where I would have used a functor. Granted, there are more ad-hoc cases where functors would be better.

> No function overloading. This is just silly and onerous. Rust could create sensible restrictions to avoid ambiguities and C++’s ADL/type coercion complexity but there’s nothing ambiguous about having two functions with different arity sharing the same name. The hardest problem in CS is naming things, and Rust’s lack of function overloading makes it harder still.

I thought I'd miss this but it hasn't been as bad as I expected.

> Don't you still have Iterator invalidation to keep track of and I thought I saw posts regretting using `std::string_view` because it is easy to reference deleted memory.

I don't run into iterator invalidation that much in practice. I'm not often erasing elements from collections. There are all sorts of things like std::string_view where you could reference bad memory if you don't manage lifetimes, but I... just... come up with designs where lifetimes are managed properly? It's probably habit and very intuitive for me, hardly conscious of it.

Also, this is where the static analyzer is fantastic. If you have good unit test coverage, it will let you know you've screwed up and pinpoint where.

I don't mind the borrow checker as a default, but it would be nice for an escape hatch that wasn't an unsafe{} block. Perhaps one with runtime checks? Predictable conditions are virtually free with branch prediction.

> Recently, I've seen an inverted pattern for this, define a trait and `impl MyTrait for Fn`. I've found I much prefer this pattern over the cases where I would have used a functor. Granted, there are more ad-hoc cases where functors would be better.

Can you give an example or provide a citation to this? I'd love to read more.

> Can you give an example or provide a citation to this?

It would look something like this:

    trait MyOperation {
        fn run(&mut self, a: T, b: U, c: V) -> R;
    }
    impl<F> MyOperation for F where F: FnMut(T, U, V) -> R {
        fn run(&mut self, a: T, b: U, c: V) -> R { self(a, b, c) }
    }

    fn my_api<F: MyOperation>(f: F) { ... f.run(a, b, c) ... }

    struct MyFunctor { ... }
    impl MyOperation for MyFunctor { ... }
    my_api(MyFunctor { ... });

That is, when defining `my_api` and you would like to accept both lambdas and functors, instead of using a `Fn` trait bound directly, use a more specific trait which has a blanket impl for lambdas.

> Can you give an example or provide a citation to this? I'd love to read more.

`nom`'s `Parser` trait is implemented for functions. You can mix and match parser functions and parser types, including the built-in types that are returned when you call the post-fix combinators on the `Parser` trait.

https://docs.rs/nom/latest/nom/

Fair points. I especially agree about `dyn` being second class, and `Arc<Mutex<` being verbose.

Not exactly sure what you mean about functors though. Maybe an example would help.

No function overloading was definitely a good decision. You can emulate variadic functions by implementing traits for tuples.

I agree it's a little verbose, but in those cases I usually make my own type aliases:

type ArcWrap<T> = Arc<Mutex<Whatever<T>>>

> In particular, a typical application design involves some variation of the Observer pattern (implementations can vary wildly), where views read/“observe” models owned by controllers. Why should I beat my head against the wall with a systems language? There should be an escape valve that doesn’t sacrifice memory safety.

The escape valve here that doesn't sacrifice memory safety is reference counting and perhaps interior mutability. (And this point certainly does involve pointers, if not void*.)

> I can’t create unbound trait/struct functors and then invoke them on strict references later?

You can't implement the `Fn` traits for your own types, but this shouldn't have any impact on what you can express, should it? If you're going to pass in references at the call site you can do that just as well with lambdas (or if you really want to use your own type, with a hand-rolled trait to replace `Fn`).

I don't disagree with your overall sentiments, however

>Arc<Box<Foo>> ugliness

Box is not needed, Arc<Foo> should already be heap allocated.

I would add that I/O in Haskell is pretty sub-optimal, so that hinders its adoption.

But I feel you in that I'm an average-ish developer, and I write Rust with a constant fear that I'm "doing it the dumb/noob/wrong way". For example, maybe I just want to write a print method for an object, but I know the Right Way is to impl Display, so I do that so I won't be ridiculed.

When you say I/O in Haskell is sub-optimal, are you referring to performance, or the fact that it can be cumbersome? I personally love that Haskell's type system tells you whether a function has any side effects, which of course includes I/O.

Mostly objective, but slightly misleading. I'd be interested in counting how many times a developer runs `cargo build` compared to `make` and `cargo check` compared to `I don't think there is a c++ equivalent`.

I imagine the total time spent compiling Rust to be much, much lower.

Adding things to Rust needn’t increase the complexity. One of the features that should arrive in a year or so is the ability to use async functions everywhere, even in traits. Right now there’s additional complexity and difficulty for beginners to know that “ok, async only in free functions and import the crate async-trait if necessary”. Future learners of Rust will simply use async wherever.

This is one example but there are other threads of work where what they’re adding brings more consistency across the language, making it easier to learn.

Do you have an opinion on Carbon?

Well, for languages that are now touting interop with C++, and the emergence of a mainstream memory safe language like Rust, Carbon seems like a retrograde step to me.

Val is probably the next language that fleeing C++ developers should get behind.

https://www.val-lang.dev/

There's even science behind it: https://www.jot.fm/issues/issue_2022_02/article2.pdf

from what I understand carbon doesn't have any working c++ interop. it's in slides at the moment and will take a long time to develop.

grokkable, from the Martian word "to grok"

from the Heinlein Sci-Fi classic "Stranger in a Strange Land":

https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Gro...

Reply on news.ycombinator.com