3 ms·

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some

by Thaxll 6y ago

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand. Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, there is no new keyword, std lib is the same, almost no changes ( beside modules ). When you look at Rust they're adding thing much faster and it feels like C++ at times, the mental overhead to keep up with that is not trivial.

FridgeSeal 6y ago
I will take a longer on-boarding in return for better long-term code any day of the week. I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach. Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion. Also the error handling is far inferior to the more principled approach taken by Rust/Haskell. > ...I can tell you right away that the Rust code will never be properly understand. I think this is an unfair characterisation: if I did this with my c#-writing coworkers, I think they’d certainly get a cursory understanding of Go quicker, but it wouldn’t take that much longer to get a grip on Rust and they’d write better and more correct code in Rust.
- throwaway89456 6y ago
  The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time. > Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. It's all a trade-off at the end of the day.
  - skohan 6y ago
    > There are no reasons why one should not produce a good design in a any language. Certain languages give you better tools than others in terms of reaching a good design. Go for instance puts you in a bit of a "jail" in terms of complexity which prevents you from going too far off the rails. Rust uses a strict compiler to categorically prevent whole classes of issues. So yes in some sense bad code is a "people problem" but the right tools can go a long way to mitigate it. > Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. I think this is where Rust's type system can often be a double-edged sword. I have run into more than a few libraries which try to make things "simple" to use by leveraging traits solve problems in a somewhat magical way, but in my experience this often makes it very difficult to trace what's actually going on. I find that Rust code is not all that self documenting, and it relies heavily on documentation in order to be understandable. And quite a few libraries are strong on per-item, per-function documentation but there's a gap in terms of high-level docs explaining the intended use of the library.
- skohan 6y ago
  > the “developer speed above all else” rabbit hole with Python I've become convinced that any language without a strong type system will eventually lead to a codebase which collapses under its own weight. Lately I've been working on a bit of data analysis in Jupyter, and even in that limited setting I find it hilariously slow and error-prone working with python. I would rate developer speed in terms of the time it takes to imagine and implement a correct solution. The correct part is key, because solving issues at runtime so so much slower than doing it at compile time. The only place where Python has an advantage is maybe in terms of how long it takes to type the code. > it wouldn’t take that much longer to get a grip on Rust This just hasn't been my experience at all. I've been programming professionally for over a decade, and I've dabbled with probably over dozen programming languages, and done real work in several: C/C++, Java, Obj-C, JS, Ruby, Swift, Python and Rust. I would say that Rust is an extreme outlier in terms of learning curve. It really took months to get to the point where I really got to that comfort point where I can just type Rust code with confidence that it's going to compile without looking a lot of things up, and even then I run into situations where I have to ask for help, and I feel like I am just scratching the surface with some more esoteric aspects of the language. In most languages it has been possible to reach that point in weeks. I say this as someone who actually loves programming in Rust and currently reaches for it often as my "main language" of choice, but it is a complex language which is not easy to learn, and this is a real point to consider in terms of using Rust in a team setting.

by Thaxll 6y ago

FridgeSeal 6y ago

I will take a longer on-boarding in return for better long-term code any day of the week. I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach. Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion. Also the error handling is far inferior to the more principled approach taken by Rust/Haskell. > ...I can tell you right away that the Rust code will never be properly understand. I think this is an unfair characterisation: if I did this with my c#-writing coworkers, I think they’d certainly get a cursory understanding of Go quicker, but it wouldn’t take that much longer to get a grip on Rust and they’d write better and more correct code in Rust.

throwaway89456 6y ago
The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time. > Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. It's all a trade-off at the end of the day.
- skohan 6y ago
  > There are no reasons why one should not produce a good design in a any language. Certain languages give you better tools than others in terms of reaching a good design. Go for instance puts you in a bit of a "jail" in terms of complexity which prevents you from going too far off the rails. Rust uses a strict compiler to categorically prevent whole classes of issues. So yes in some sense bad code is a "people problem" but the right tools can go a long way to mitigate it. > Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. I think this is where Rust's type system can often be a double-edged sword. I have run into more than a few libraries which try to make things "simple" to use by leveraging traits solve problems in a somewhat magical way, but in my experience this often makes it very difficult to trace what's actually going on. I find that Rust code is not all that self documenting, and it relies heavily on documentation in order to be understandable. And quite a few libraries are strong on per-item, per-function documentation but there's a gap in terms of high-level docs explaining the intended use of the library.
skohan 6y ago
> the “developer speed above all else” rabbit hole with Python I've become convinced that any language without a strong type system will eventually lead to a codebase which collapses under its own weight. Lately I've been working on a bit of data analysis in Jupyter, and even in that limited setting I find it hilariously slow and error-prone working with python. I would rate developer speed in terms of the time it takes to imagine and implement a correct solution. The correct part is key, because solving issues at runtime so so much slower than doing it at compile time. The only place where Python has an advantage is maybe in terms of how long it takes to type the code. > it wouldn’t take that much longer to get a grip on Rust This just hasn't been my experience at all. I've been programming professionally for over a decade, and I've dabbled with probably over dozen programming languages, and done real work in several: C/C++, Java, Obj-C, JS, Ruby, Swift, Python and Rust. I would say that Rust is an extreme outlier in terms of learning curve. It really took months to get to the point where I really got to that comfort point where I can just type Rust code with confidence that it's going to compile without looking a lot of things up, and even then I run into situations where I have to ask for help, and I feel like I am just scratching the surface with some more esoteric aspects of the language. In most languages it has been possible to reach that point in weeks. I say this as someone who actually loves programming in Rust and currently reaches for it often as my "main language" of choice, but it is a complex language which is not easy to learn, and this is a real point to consider in terms of using Rust in a team setting.