8 ms·

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 canar

by _448 4y ago

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.

trenchgun 4y ago
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?
- donatzsky 4y ago
  Why do you assume that all developers have studied CS?
- alltheworlds 4y ago
  sigh Do you really think this or are you just projecting elitism?
- antonvs 4y ago
  Most developers have never even heard of lambda calculus.
- zabzonk 4y ago
  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.
- Thorrez 4y ago
  I got a bachelor's in CS and never learned lambda calculus.
  - TillE 4y ago
    Same. Turing machines and FSA yes, lambda calculus no.
- eddsh1994 4y ago
  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
- qwertywert_ 4y ago
  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.
hansonkd 4y ago
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.
- petesergeant 4y ago
  > 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 );
  - iterateoften 4y ago
    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.
smingo 4y ago
Do you have an opinion on Carbon?
- DrBazza 4y ago
  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/ https://www.val-lang.dev/ There's even science behind it: https://www.jot.fm/issues/issue_2022_02/article2.pdf https://www.jot.fm/issues/issue_2022_02/article2.pdf
  - shaklee3 4y ago
    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.
pornel 4y ago
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.
- pjmlp 4y ago
  > 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.
- jononor 4y ago
  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.
  - 4y ago
nindalf 4y ago
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.
nhatcher 4y ago
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!
EVa5I7bHFq9mnYK 4y ago
grokkable, from the Martian word "to grok"
- thesuperbigfrog 4y ago
  from the Heinlein Sci-Fi classic "Stranger in a Strange Land": https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Grok https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Gro...
tialaramex 4y ago
> 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.
- zabzonk 4y ago
  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.
  - tialaramex 4y ago
    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.
    - zabzonk 4y ago
      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.
rapsey 4y ago
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.
- pjmlp 4y ago
  Are you sure about 0 when Rust is 40 years old? C++ in 1993 was also quite easy to learn.
  - rapsey 4y ago
    Have you read past the first sentence?
    - pjmlp 4y ago
      Surely, the other points don't address how Rust will look like when it reaches 40 years of language evolution.
- hawski 4y ago
  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?
jonstewart 4y ago
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*.
culebron21 4y ago
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.
queuebert 4y ago
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.
- xedrac 4y ago
  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.
eximius 4y ago
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.
duped 4y ago
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.

by _448 4y ago

trenchgun 4y ago

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?

donatzsky 4y ago
Why do you assume that all developers have studied CS?
alltheworlds 4y ago
sigh Do you really think this or are you just projecting elitism?
antonvs 4y ago
Most developers have never even heard of lambda calculus.
zabzonk 4y ago
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.
Thorrez 4y ago
I got a bachelor's in CS and never learned lambda calculus.
- TillE 4y ago
  Same. Turing machines and FSA yes, lambda calculus no.
eddsh1994 4y ago
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
qwertywert_ 4y ago
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.

hansonkd 4y ago

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.

petesergeant 4y ago
> 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 );
- iterateoften 4y ago
  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.

smingo 4y ago

Do you have an opinion on Carbon?

DrBazza 4y ago
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/ https://www.val-lang.dev/ There's even science behind it: https://www.jot.fm/issues/issue_2022_02/article2.pdf https://www.jot.fm/issues/issue_2022_02/article2.pdf
- shaklee3 4y ago
  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.

pornel 4y ago

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.

pjmlp 4y ago
> 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.
jononor 4y ago
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.
- 4y ago

nindalf 4y ago

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.

nhatcher 4y ago

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!

EVa5I7bHFq9mnYK 4y ago

grokkable, from the Martian word "to grok"

thesuperbigfrog 4y ago
from the Heinlein Sci-Fi classic "Stranger in a Strange Land": https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Grok https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Gro...

tialaramex 4y ago

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

zabzonk 4y ago
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.
- tialaramex 4y ago
  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.
  - zabzonk 4y ago
    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.

rapsey 4y ago

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.

pjmlp 4y ago
Are you sure about 0 when Rust is 40 years old? C++ in 1993 was also quite easy to learn.
- rapsey 4y ago
  Have you read past the first sentence?
  - pjmlp 4y ago
    Surely, the other points don't address how Rust will look like when it reaches 40 years of language evolution.
hawski 4y ago
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?

jonstewart 4y ago

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

culebron21 4y ago

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.

queuebert 4y ago

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.

xedrac 4y ago
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.

eximius 4y ago

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.

duped 4y ago

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.