16 ms·

> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental ov

> The downside that the author points out seem to be often neglected. Constant interruption and battling with the type system during development, when mental overhead is a problem. This assertion is just wrong. The author makes it quite clear that he doesn't know the language and is still taking his first steps ( "I am still a Rust learner, not a veteran" ), he implies that has problems with correct memory management and best practices while using other languages (core dumps heart attacks), and claims that one of the most important aspects of Rust is that "it's memory safe". Of course, memory safety is achieved through compiler checks. However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. If someone tries to write broken C or C++ using Rust and Rust's compiler starts to throw error messages pointing out the errors the programmer is making by trying to write broken C or C++ in Rust then obviously Rust is not the problem. It is im fact the solution, and a solution that's being ignored. Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust's compiler because, as he puts it, the compiler will stop you from doing unsafe stuff again and again. Isn't that the whole point? Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++?

tsimionescu 8y ago
> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust compiler because, as he puts it, the compiler will stop you from doing unsafe studf again and again. Isn't that the whole point? Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++? I think the biggest problem with advanced type systems and complex compiler checks is that they are only desirable when you know the code you're writing is the the right one. A lot of the time, you're exploring a solution and don't care about edge cases, since you're not sure you've even found the right happy path. At this stage, you don't really care if your code is handling all required inputs, if it doesn't have leaks etc. - you just want to run it and see whether it at least sometimes produces the right output. At this stage, you're often fighting the compiler. Once you know that you're on a good path, then you start caring about safety and all the other bits, and the compiler starts becoming a trusted friend. It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. I'd bet that would change many people's perspectives, like the author of this article.
- viraptor 8y ago
  > It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc kind of does that. It assumes the input code is valid at the moment. But if you want to experiment first, you have other language pairs you could use. Python + typed Cython, or Ruby + Crystal, or other options...
- larzang 8y ago
  I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.
  - reificator 8y ago
    > I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. I want to agree with you on this statement, but I don't think your anecdote supports it. > In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments. To me it just sounds like the second junior has a stronger understanding of the language/type system. Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course) Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.
coldtea 8y ago
>However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (Rust is fine, you're just not good enough in it yet to use it properly, that's why you're discouraged). Well, sometimes the language is not fine, and its ergonomics can be all wrong. In C it was the type looseness, bad standard library, and presence of many foot guns. In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming. I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before. If they can't, something's wrong with your language's ergonomics.
- gameswithgo 8y ago
  your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.
  - coldtea 8y ago
    I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
    - gameswithgo 8y ago
      i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection
blub 8y ago
That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. It's also moved heavily in the direction of some FP concepts which have zero overlap with C and arguably little to do with C++. The big assumption Rust is based on is that people will recognise the benefits of memory safety and be willing to pay the price for it. Many outside the early adopter group won't be, that's how the mainstream works.
- baq 8y ago
  i'd say game developers aren't really the target audience, because they expect to move fast and not necessarily correct, just correct enough most of the time. other developers don't have issues with the compiler being more picky; compile times are more of a problem in adoption than language strictness.
- viraptor 8y ago
  > the friction is coming from the fact that Rust can't be changed any more The basic language as such doesn't change much, but what the compiler infers and accepts gets extended with almost every release. rustc from 2 years ago is a lot more strict than rustc now. And lots of lifetime annotations you had to do before, you can omit today. The experience is much nicer and the friction definitely goes down.
  - duneroadrunner 8y ago
    Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority. At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some point automated translation between the two languages will be a thing. At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures. But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
slavik81 8y ago
> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust's compiler because, as he puts it, the compiler will stop you from doing unsafe stuff again and again. Isn't that the whole point? Rust ensures that all valid rust programs are safe, but this does not mean that programs that are difficult to express in rust are unsafe. Consider how future improvements to rust may make some previously difficult to express patterns easier. I think non-lexical lifetimes would be one such example. You could imagine that someone who learned on a future version of rust might be similarly annoyed at compiler errors when working with an old version of rust that's more limited in what things can be expressed and understood as safe.
kazinator 8y ago
> . It is im fact the solution, and a solution that's being ignored. If the coder's C++, that is written in flow without being distracted by borrow-checkers and whatnot, is in fact correct code, then no, there is no solution that is being ignored; what's being ignored is a "problem in search of a solution". > Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++? That's a pretty good executive summary of the Rust cheerleading. In fact, what you describe is sometimes possible. For illustration, let's confine our attention to use-after-free bugs and memory leaks. If we make the free function do nothing, and stick in a garbage collector, then in fact you can write (some of) "your same old memory allocation and access bugs" yet they are mitigated.

tsimionescu 8y ago

> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust compiler because, as he puts it, the compiler will stop you from doing unsafe studf again and again. Isn't that the whole point? Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++? I think the biggest problem with advanced type systems and complex compiler checks is that they are only desirable when you know the code you're writing is the the right one. A lot of the time, you're exploring a solution and don't care about edge cases, since you're not sure you've even found the right happy path. At this stage, you don't really care if your code is handling all required inputs, if it doesn't have leaks etc. - you just want to run it and see whether it at least sometimes produces the right output. At this stage, you're often fighting the compiler. Once you know that you're on a good path, then you start caring about safety and all the other bits, and the compiler starts becoming a trusted friend. It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. I'd bet that would change many people's perspectives, like the author of this article.

viraptor 8y ago
> It would be really interesting to have a system that supported both modes, e.g. starting from Rust but setting a flag to turn borrow checker errors into warnings or something similar. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc kind of does that. It assumes the input code is valid at the moment. But if you want to experiment first, you have other language pairs you could use. Python + typed Cython, or Ruby + Crystal, or other options...
larzang 8y ago
I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments.
- reificator 8y ago
  > I actually find strong typing speeds up green-field development rather than hampering it, because it cuts down on the little avoidable things that inevitably creep in when you're trying to architect and evaluate and code all at the same time. The kinds of things that make you smack yourself in the face for an hour wasted by the most trivial mistakes. I want to agree with you on this statement, but I don't think your anecdote supports it. > In addition to my own personal experience this has been incredibly well illustrated to me because I'm overseeing two junior JS devs right now where one starts any new code with "any" types and tries to make Flow happy later and the other starts with real types. The former has a LOT more "this isn't working and I have no idea why, help" moments. To me it just sounds like the second junior has a stronger understanding of the language/type system. Some people come into junior positions because they've learned enough to pass a CS course. Some come into junior positions because they've spent their whole life programming in some way or another and want to get some professional experience on their resume. (And everything inbetween of course) Now, trying to push the Any dev toward specifying types upfront and watching the results might give you better evidence, and better performance to boot.

coldtea 8y ago

>However, the author is still someone who does not know how to use a programming language and is still bound to not only the mental model of another programming language but also bad practices that lead to problems. Well, that's the same attitude ("the language is fine, you just don't know how to use it, that's why you have bugs") that led us to 30+ years of shitty unsafe C code. Now it's applied to the other side (Rust is fine, you're just not good enough in it yet to use it properly, that's why you're discouraged). Well, sometimes the language is not fine, and its ergonomics can be all wrong. In C it was the type looseness, bad standard library, and presence of many foot guns. In Rust it's the overt explicitness of the borrow checker, and the friction it adds to one's programming. I don't care if the author is a Rust expert or total newb. Someone who can write a 3D modeler in C++ is someone who should be able to use any new Algol-derived language with ease in short time, regardless if they hasn't seen a line of code in that language before. If they can't, something's wrong with your language's ergonomics.

gameswithgo 8y ago
your final assertion implies that any new language that is a significant paradigm shift from c++ must be flawed.
- coldtea 8y ago
  I do qualify that I speak about languages that are still "Algol-derived". Rust is not some significant paradigm shift (like e.g. Scheme vs C vs Prolog vs Haskell, etc). It's the same concepts and programming styles as C, C++ etc, plus fighting the borrow checker.
  - gameswithgo 8y ago
    i think the borrow checker may indeed be a rather large paradigm shift, and im super interested to know if you can get used to it and be as productive as you are in c++ or if it is innately harder. to me it is still hard to work woth but i habe 30 years of being ised to C or garbage collection

blub 8y ago

That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. It's also moved heavily in the direction of some FP concepts which have zero overlap with C and arguably little to do with C++. The big assumption Rust is based on is that people will recognise the benefits of memory safety and be willing to pay the price for it. Many outside the early adopter group won't be, that's how the mainstream works.

baq 8y ago
i'd say game developers aren't really the target audience, because they expect to move fast and not necessarily correct, just correct enough most of the time. other developers don't have issues with the compiler being more picky; compile times are more of a problem in adoption than language strictness.
viraptor 8y ago
> the friction is coming from the fact that Rust can't be changed any more The basic language as such doesn't change much, but what the compiler infers and accepts gets extended with almost every release. rustc from 2 years ago is a lot more strict than rustc now. And lots of lifetime annotations you had to do before, you can omit today. The experience is much nicer and the friction definitely goes down.
- duneroadrunner 8y ago
  Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority. At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some point automated translation between the two languages will be a thing. At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures. But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

slavik81 8y ago

> Heck, the author praises Rust and it's memory safety, but then proceeds to criticise Rust's compiler because, as he puts it, the compiler will stop you from doing unsafe stuff again and again. Isn't that the whole point? Rust ensures that all valid rust programs are safe, but this does not mean that programs that are difficult to express in rust are unsafe. Consider how future improvements to rust may make some previously difficult to express patterns easier. I think non-lexical lifetimes would be one such example. You could imagine that someone who learned on a future version of rust might be similarly annoyed at compiler errors when working with an old version of rust that's more limited in what things can be expressed and understood as safe.

kazinator 8y ago

> . It is im fact the solution, and a solution that's being ignored. If the coder's C++, that is written in flow without being distracted by borrow-checkers and whatnot, is in fact correct code, then no, there is no solution that is being ignored; what's being ignored is a "problem in search of a solution". > Or is anyone expecting that your memory corruption problems will magically cease because you write your same old memory allocation and access bugs in Rust instead of C or C++? That's a pretty good executive summary of the Rust cheerleading. In fact, what you describe is sometimes possible. For illustration, let's confine our attention to use-after-free bugs and memory leaks. If we make the free function do nothing, and stick in a garbage collector, then in fact you can write (some of) "your same old memory allocation and access bugs" yet they are mitigated.