5 ms·

The amount of complexity that Rust adds is not worth in most scenarios in my opinion. I can think of Rust as something for OS with critical safety or so. Besid

The amount of complexity that Rust adds is not worth in most scenarios in my opinion. I can think of Rust as something for OS with critical safety or so. Besides that, in real life you end up having C in most of your software, so I am not sure how Rust behaves compared to well-written C++ with all warnings and linters on and using smart pointers. But my hypothesis is that they do not stay very far apart in safety. There are many ways to achieve safety, and the most promising, IMHO, is the path that Hylo programming language is taking. It sticks to Generic programming and mutable value semantics. The language base draws from Swift and it has very strong people behind that know what they are doing. For example David Abrahams and Sean Parent. This is an implementation in a language of many of the ideas from "Better Code" from Sean Parent. It has a very solid foundation. Besides being a solid foundation for generic programming, value semantics, and concurrency, what I like the most is how much it simplifies the model by not escaping references all around and preventing unnecessary copies. This removes the (IMHO) mess that is to have to manage reference escaping constantly in Rust, reason why many patterns such as Linked lists are not even possible. And Lists are not just an academic exercise, as I was told sometimes by Rust proponents. Linked structures (Inmutable linked structures actually) are important in scenarios such as TelCo backend where you need replication, fast moving of data and history versioning, rollbacks and so on.

no_wizard 3y ago
All this may be true (I'm not the strongest C++ developer in the world, relatively limited exposure), however the Rust memory management via the type system feels natural once you wrap your head around it. That idea is really good. I always hated dealing with `delete`, `free` and `malloc`. Being able to offload all that busy work to the type system is just nice. There are definitely ergonomic improvements that could be made around this. All the rest? I'll leave that to someone else to talk through, as I'm no expert here.
- germandiago 3y ago
  > however the Rust memory management via the type system feels natural once you wrap your head around it It disallows many valid patterns. That is why I recommend to take a look at Hylo programming language (before called Val lang) to see what I think it is a very good example of how to make a language safe without making the learning curve so steep and without a need for a GC.
  - no_wizard 3y ago
    The way Rust does it may disallow valid patterns, but it is not inherent to the idea
- bluGill 3y ago
  I.write c++ all the time, and I go months between needing new or delete. Unique_ptr is a wonderful thing. Not quite as powerful as rust's borrow checker, but it saves me a lot of thinking.
lelanthran 3y ago
> The amount of complexity that Rust adds is not worth in most scenarios in my opinion. I can think of Rust as something for OS with critical safety or so. It's difficult to have this discussion in any sane way when Rust (or C) comes up. I tried Rust, but I have projects to deliver on strict timelines and I have yet to find a client who is prepared to pay me for the (what I found to be) very large onramp time to gain deep Rust expertise.[1] The argument of "just get gud" whenever you point out the deep learning curve of Rust is pointless; I have noticed that Rust experts only come when your employer is rich enough to pay the team to not deliver while they learn it: Basically only FAANGs and startups flush with VC money. [1] When I have a small project I reach for C. When I need something bigger for which C is not suitable, I don't reach for C++, or Rust, I rather take the tiny performance hit and move to Go. On extremely large projects, where I work with others, C# and Java seem to hit the sweet spot.[2] [2] Although, C# and Java are also getting a bit too complicated for my tastes too. Seems to me that every language follows C++ evolution towards complexity, because the people stewarding the language are experts in that language and/or in programming language theory.[3] They are comfortable with the changes they propose because they have no need to upskill (they are already at that skill level). [3] I propose that a language designed by your average corporate developer who has 15 years of experience but no CS degree will have much higher adoption than languages designed by PL purists.
- mighmi 3y ago
  What makes you choose Go over C#/Java for medium projects? And why not go for the large projects?
  - lelanthran 3y ago
    > What makes you choose Go over C#/Java for medium projects? Because I said: >> C# and Java are also getting a bit too complicated for my tastes too. I abhor complications. > And why not go for the large projects? Because I said: >> where I work with others, C# and Java seem to hit the sweet spot Yeah yeah, I know it sounds like I am whining (Maybe I am :-), but at least I am complaining about all of them. Java and C# do appear to have been battle-tested for very large projects that aren't microservices. Go? I dunno. I've only ever seen very large projects in Go using microservices. I like its simplicity. My main complaint is that programming languages have too much minutiae to track that I really shouldn't have to be tracking. Take, for example, asynchronous builtins: Why are all the explanations wrapped in jargon that only an expert in the language would grok immediately? Promises? Futures? You gotta explain those, with examples, before you can explain what to do with a value from an async call. Go look at the popular introductions to async (say, on MDN for js, or Microsoft for C#, etc) and count how many times they have to explain something because of their leaky abstraction implementation rather than explaining the concept. How about simply saying "calling async functions only schedules the function for later execution, it doesn't execute it". That naturally leads into "So you need to check if it is finished using an identifier to identify which scheduled call you want to check"... Which itself naturally leads to "The identifier you need was given to you when you scheduled the call"... Which leads to "Using that identifier from `id = foo();`, you wait for the result like this: `result = id.wait()`". You can even add "You can return that id, or pass it around so some other code can do `id.wait()`". Now they don't explain it this way, because their implementation(s) is more of a leaky abstraction exposing irrelevant information about the compiler, than of a straightforward implementation of the concept. They are unable to separate the concept from their implementation. The common implementation of async is so counterintuitive that they have to explain their particular implementation instead of the concept, because it has almost nothing to do with the concept. If they just explained the concept, programmers would still be confused because the implementation needs things like colored functions just to work poorly. The concept of scheduled functions (which may return once, or may yield multiple times before returning), which is a simple path to understanding asynchronous calls, is completely divorced from the implementation which will produce errors like "cannot call asynchronous function from a top level"[1] or "cannot call await in a function not declared as async".[2] So, yeah, I'm kinda upset at how programming has evolved over the years (I wrote my first program in 1986, so had a good seat for the later part of this particular movie), from "simple and straightforward", to "complex for complexities sake". [1] Why? Because their abstraction is an abstraction of their implementation, and not an abstraction of asynchronous calls. [2] Se [1] above.
sacado2 3y ago
> well-written C++ with all warnings and linters on and using smart pointers. But my hypothesis is that they do not stay very far apart in safety. Can C++ compilers + linters reliably detect all misuses of unique_ptr? Because that sounds like a halting-problem kind of problem, and as soon as you can't guarantee memory-safety, you're definitely not in the same ballpark in terms of safety. I mean, memory-unsafety is the number one vulnerability cause in software. C++ has many qualities, but safety certainly isn't one of them.
- germandiago 3y ago
  > Can C++ compilers + linters reliably detect all misuses of unique_ptr? Because that sounds like a halting-problem kind of problem, and as soon as you can't guarantee memory-safety, you're definitely not in the same ballpark in terms of safety. Is C and assembly the same level of memory safety? Probably yes... but no, it is not in practice. And C and C++? Yes, in theory, in practice... C++ is safer. How about Rust? In theory Rust is safer. In practice, you are going to use C libraries here and there, so... in practice not as safe as advertised. Well-written C++ with -Wall -Werror, -Weverything, -Wextra... that is very safe, including detecting even dangling stuff to some extent (gcc-13). If you stick to `shared_ptr` and `unique_ptr` no matter how much you complain about it: Rust with its C shims and C++ with all linters and a good environment are practically at similar levels of safety. This is the practical, real thing that happens. I do use C++ for every day use for around 14 years professionally and 20 years in total. You are all in the terrain of theory, but how much Rust and C++ have you really written? Of course, the CVEs data about memory safety, well, those are true. And they are a real problem. But with a reasonably good use of C++ those would be much, much, much lower than they have been so far.

no_wizard 3y ago

All this may be true (I'm not the strongest C++ developer in the world, relatively limited exposure), however the Rust memory management via the type system feels natural once you wrap your head around it. That idea is really good. I always hated dealing with `delete`, `free` and `malloc`. Being able to offload all that busy work to the type system is just nice. There are definitely ergonomic improvements that could be made around this. All the rest? I'll leave that to someone else to talk through, as I'm no expert here.

germandiago 3y ago
> however the Rust memory management via the type system feels natural once you wrap your head around it It disallows many valid patterns. That is why I recommend to take a look at Hylo programming language (before called Val lang) to see what I think it is a very good example of how to make a language safe without making the learning curve so steep and without a need for a GC.
- no_wizard 3y ago
  The way Rust does it may disallow valid patterns, but it is not inherent to the idea
bluGill 3y ago
I.write c++ all the time, and I go months between needing new or delete. Unique_ptr is a wonderful thing. Not quite as powerful as rust's borrow checker, but it saves me a lot of thinking.

lelanthran 3y ago

> The amount of complexity that Rust adds is not worth in most scenarios in my opinion. I can think of Rust as something for OS with critical safety or so. It's difficult to have this discussion in any sane way when Rust (or C) comes up. I tried Rust, but I have projects to deliver on strict timelines and I have yet to find a client who is prepared to pay me for the (what I found to be) very large onramp time to gain deep Rust expertise.[1] The argument of "just get gud" whenever you point out the deep learning curve of Rust is pointless; I have noticed that Rust experts only come when your employer is rich enough to pay the team to not deliver while they learn it: Basically only FAANGs and startups flush with VC money. [1] When I have a small project I reach for C. When I need something bigger for which C is not suitable, I don't reach for C++, or Rust, I rather take the tiny performance hit and move to Go. On extremely large projects, where I work with others, C# and Java seem to hit the sweet spot.[2] [2] Although, C# and Java are also getting a bit too complicated for my tastes too. Seems to me that every language follows C++ evolution towards complexity, because the people stewarding the language are experts in that language and/or in programming language theory.[3] They are comfortable with the changes they propose because they have no need to upskill (they are already at that skill level). [3] I propose that a language designed by your average corporate developer who has 15 years of experience but no CS degree will have much higher adoption than languages designed by PL purists.

mighmi 3y ago
What makes you choose Go over C#/Java for medium projects? And why not go for the large projects?
- lelanthran 3y ago
  > What makes you choose Go over C#/Java for medium projects? Because I said: >> C# and Java are also getting a bit too complicated for my tastes too. I abhor complications. > And why not go for the large projects? Because I said: >> where I work with others, C# and Java seem to hit the sweet spot Yeah yeah, I know it sounds like I am whining (Maybe I am :-), but at least I am complaining about all of them. Java and C# do appear to have been battle-tested for very large projects that aren't microservices. Go? I dunno. I've only ever seen very large projects in Go using microservices. I like its simplicity. My main complaint is that programming languages have too much minutiae to track that I really shouldn't have to be tracking. Take, for example, asynchronous builtins: Why are all the explanations wrapped in jargon that only an expert in the language would grok immediately? Promises? Futures? You gotta explain those, with examples, before you can explain what to do with a value from an async call. Go look at the popular introductions to async (say, on MDN for js, or Microsoft for C#, etc) and count how many times they have to explain something because of their leaky abstraction implementation rather than explaining the concept. How about simply saying "calling async functions only schedules the function for later execution, it doesn't execute it". That naturally leads into "So you need to check if it is finished using an identifier to identify which scheduled call you want to check"... Which itself naturally leads to "The identifier you need was given to you when you scheduled the call"... Which leads to "Using that identifier from `id = foo();`, you wait for the result like this: `result = id.wait()`". You can even add "You can return that id, or pass it around so some other code can do `id.wait()`". Now they don't explain it this way, because their implementation(s) is more of a leaky abstraction exposing irrelevant information about the compiler, than of a straightforward implementation of the concept. They are unable to separate the concept from their implementation. The common implementation of async is so counterintuitive that they have to explain their particular implementation instead of the concept, because it has almost nothing to do with the concept. If they just explained the concept, programmers would still be confused because the implementation needs things like colored functions just to work poorly. The concept of scheduled functions (which may return once, or may yield multiple times before returning), which is a simple path to understanding asynchronous calls, is completely divorced from the implementation which will produce errors like "cannot call asynchronous function from a top level"[1] or "cannot call await in a function not declared as async".[2] So, yeah, I'm kinda upset at how programming has evolved over the years (I wrote my first program in 1986, so had a good seat for the later part of this particular movie), from "simple and straightforward", to "complex for complexities sake". [1] Why? Because their abstraction is an abstraction of their implementation, and not an abstraction of asynchronous calls. [2] Se [1] above.

sacado2 3y ago

> well-written C++ with all warnings and linters on and using smart pointers. But my hypothesis is that they do not stay very far apart in safety. Can C++ compilers + linters reliably detect all misuses of unique_ptr? Because that sounds like a halting-problem kind of problem, and as soon as you can't guarantee memory-safety, you're definitely not in the same ballpark in terms of safety. I mean, memory-unsafety is the number one vulnerability cause in software. C++ has many qualities, but safety certainly isn't one of them.

germandiago 3y ago
> Can C++ compilers + linters reliably detect all misuses of unique_ptr? Because that sounds like a halting-problem kind of problem, and as soon as you can't guarantee memory-safety, you're definitely not in the same ballpark in terms of safety. Is C and assembly the same level of memory safety? Probably yes... but no, it is not in practice. And C and C++? Yes, in theory, in practice... C++ is safer. How about Rust? In theory Rust is safer. In practice, you are going to use C libraries here and there, so... in practice not as safe as advertised. Well-written C++ with -Wall -Werror, -Weverything, -Wextra... that is very safe, including detecting even dangling stuff to some extent (gcc-13). If you stick to `shared_ptr` and `unique_ptr` no matter how much you complain about it: Rust with its C shims and C++ with all linters and a good environment are practically at similar levels of safety. This is the practical, real thing that happens. I do use C++ for every day use for around 14 years professionally and 20 years in total. You are all in the terrain of theory, but how much Rust and C++ have you really written? Of course, the CVEs data about memory safety, well, those are true. And they are a real problem. But with a reasonably good use of C++ those would be much, much, much lower than they have been so far.