8 ms·

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best langu

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) You have to spend more time upfront to compile and fix all warnings, but in my experience so far, fixing these at the right time (i.e. before compilation) is better than fixing them after someone writes a Github issue. I can't say it eliminates all bugs, but my trust level to my Rust code is around 10x more than my Python code for the same problem. (And I'm writing Python since 2002.)

m25n 4y ago
I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.
- iex_xei 4y ago
  That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.
  - wvh 4y ago
    Sounds like Go. Just write code, then see if any obvious interfaces pop up and if you need them.
    - iex_xei 4y ago
      I wrote servers in Go as well, and I like the language. After Rust, I believe at some point, I enjoy to solve the "problems" Rust brings, not that it's rationally better than Go.
raxxorraxor 4y ago
To be honest that doesn't seem too convincing for a new language. It actually reminds me of the early dogmatism of Java which today is often seen as too restrictive. Rust makes an argument about safety but only for a select few types of errors and the cost seem rather high.
- iex_xei 4y ago
  It brought a discipline to my memory/variable management and functional problem solving, as Haskell brought a discipline in my typeful thinking some time ago. I don't claim it's "the best language for all use cases" but I'm glad I'm learning it.
synergy20 4y ago
using c++17/c++20 with g++'s sanitizers(e.g. undefined behavior) and static analyzers, along with clangd the LSP, they too caught most if not all coding errors at editing time and compiling time. In recent two years once my c++ program compiles warning free, it seems bug-free at the same time.
- spoiler 4y ago
  In my experience this is untrue... I've worked with C++ on and off (albeit, sometimes reluctantly, so maybe I'm projecting some misery) and a lot of errors in C++ can not be caught until it starts pasting the templates. Sometimes it also fails when linking. Sure, you can always go through the whole build/compile process, but for serious C++ projects that's impractical (even with stuff like (s)ccache) because of how long it takes. And I'm a code quality tooling/intellisense freak to the point it can be annoying for others, and I've never seen a truckload of tooling come even close to simply running "cargo check" I've only experienced waiting ~10 minutes at most (on decent dev machine) and it frustrated me to no end, but even more serious projects sometimes take hours. Maybe concepts help with this? And the "jUsT dOnT uSe HaLf tHe LaNgUaGe" argument holds as much as a leaky bucket, because it's hard to agree on what the good parts are in a large team, unless its strictly enforced and audited somehow
  - synergy20 4y ago
    I tried rust on and off, since I do not need it for work I never had time to fully dive into it. The news about rust on the web just seems too good to be true, are there any "cons" against modern c++? yes the cargo and tools etc are great, but I can set up a full c++ build env quickly too, not as good but enough for daily coding.
    - spoiler 4y ago
      A big con is that the ecosystem is young still. You can generally find stuff for almost anything at this point (even enterprisey stuff like OData client generators), but they're not "established" the same way their C++ equivalents would be. GUI and Game dev spaces in Rust are very inovativne and in how they solve some problems, and I'm fairly enthusiastic about both spaces, but I'd be reluctant to recommend them for production, because they're still immature/developing compared to anything in C++
hirrolot 4y ago
> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role is being an async library author (me).
- logicchains 4y ago
  People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anything other than the absolute minimum possible latency, I'd prefer to write Go, and I say that as someone who thinks Go's lack of generics was an absolutely terrible idea.
  - crabbygrabby 4y ago
    Go now has generics. The performance of using them is hit or miss it seems. Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.
    - logicchains 4y ago
      >you can adopt easier patterns to async Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.
      - crabbygrabby 4y ago
Aardwolf 4y ago
IMHO the time for doing analysis like this is before submitting code, not before compiling it. Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere because you change the type something temporarily. It'd be nice to only do the work of cleaning up such issues in the final version of your change. These checks are enabled by default in many environments, build tools or scripts for them etc..., it's not trivial to disable it or requires full recompile. So I wish a language or build environment would use the concept of "development time" vs "submitting time" for different sets of warnings-as-errors.
- epage 4y ago
  Earlier in Rust, I saw people recommending `#![deny(warnings)]` (always turn warnings into errors) but I think the community has shifted since then because I feel like I don't see that as much and instead see people disabling warnings in CI. Speaking of warnings, something I appreciate about Rust is you only see warnings for your own code and not for your dependencies so you can crank up the warnings to whatever level you want without being blocked by dependencies (minus macros). Granted, there could be times where looking at high risk warnings for dependencies could be important.
- sph 4y ago
  This is one recent change in Zig which really annoys me: unused variables are now errors. Languages that complain every time there's a unused variable become useless during experimentation and quick hacking. They turn my hyperfocus into a death from a thousand paper cuts. I hate it with a passion. Please respect my mental flow, if I'm trying some ideas out, it's just rude to stop me in my tracks to tell me I forgot to comment out a variable. Who cares. I will fight anyone who thinks this is a good idea.
  - noisy_boy 4y ago
    I have to agree with you. Zig already has a Debug build mode, they can just warn if you are running Debug build.
WuxiFingerHold 4y ago
> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself You can write perfectly fine solutions in a GC language without lying to yourself. > my trust level to my Rust code is around 10x more than my Python code for the same problem Python as a dynamically typed language is not the mark. Rust has a great static type system, but other GC languages offer that as well.
bergenty 4y ago
>unlearning scope As a programmer that hasn’t worked with Rust, what does that mean.
- iex_xei 4y ago
  e.g. You can use a variable twice when calling a function in most languages without thinking twice. I had to unlearn this :)
michaelcampbell 4y ago
> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) A quick and easy solution is still a solution, which is what most bosses want.
- iex_xei 4y ago
  That's true, though in my experience those quick solutions lead to more quick solutions, and in total that leads to a mess in the long run. But if that long run will never come, it may be better not to bother. These are all sensible choices.

m25n 4y ago

I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.

iex_xei 4y ago
That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.
- wvh 4y ago
  Sounds like Go. Just write code, then see if any obvious interfaces pop up and if you need them.
  - iex_xei 4y ago
    I wrote servers in Go as well, and I like the language. After Rust, I believe at some point, I enjoy to solve the "problems" Rust brings, not that it's rationally better than Go.

raxxorraxor 4y ago

To be honest that doesn't seem too convincing for a new language. It actually reminds me of the early dogmatism of Java which today is often seen as too restrictive. Rust makes an argument about safety but only for a select few types of errors and the cost seem rather high.

iex_xei 4y ago
It brought a discipline to my memory/variable management and functional problem solving, as Haskell brought a discipline in my typeful thinking some time ago. I don't claim it's "the best language for all use cases" but I'm glad I'm learning it.

synergy20 4y ago

using c++17/c++20 with g++'s sanitizers(e.g. undefined behavior) and static analyzers, along with clangd the LSP, they too caught most if not all coding errors at editing time and compiling time. In recent two years once my c++ program compiles warning free, it seems bug-free at the same time.

spoiler 4y ago
In my experience this is untrue... I've worked with C++ on and off (albeit, sometimes reluctantly, so maybe I'm projecting some misery) and a lot of errors in C++ can not be caught until it starts pasting the templates. Sometimes it also fails when linking. Sure, you can always go through the whole build/compile process, but for serious C++ projects that's impractical (even with stuff like (s)ccache) because of how long it takes. And I'm a code quality tooling/intellisense freak to the point it can be annoying for others, and I've never seen a truckload of tooling come even close to simply running "cargo check" I've only experienced waiting ~10 minutes at most (on decent dev machine) and it frustrated me to no end, but even more serious projects sometimes take hours. Maybe concepts help with this? And the "jUsT dOnT uSe HaLf tHe LaNgUaGe" argument holds as much as a leaky bucket, because it's hard to agree on what the good parts are in a large team, unless its strictly enforced and audited somehow
- synergy20 4y ago
  I tried rust on and off, since I do not need it for work I never had time to fully dive into it. The news about rust on the web just seems too good to be true, are there any "cons" against modern c++? yes the cargo and tools etc are great, but I can set up a full c++ build env quickly too, not as good but enough for daily coding.
  - spoiler 4y ago
    A big con is that the ecosystem is young still. You can generally find stuff for almost anything at this point (even enterprisey stuff like OData client generators), but they're not "established" the same way their C++ equivalents would be. GUI and Game dev spaces in Rust are very inovativne and in how they solve some problems, and I'm fairly enthusiastic about both spaces, but I'd be reluctant to recommend them for production, because they're still immature/developing compared to anything in C++

hirrolot 4y ago

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role is being an async library author (me).

logicchains 4y ago
People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anything other than the absolute minimum possible latency, I'd prefer to write Go, and I say that as someone who thinks Go's lack of generics was an absolutely terrible idea.
- crabbygrabby 4y ago
  Go now has generics. The performance of using them is hit or miss it seems. Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.
  - logicchains 4y ago
    >you can adopt easier patterns to async Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.
    - crabbygrabby 4y ago

Aardwolf 4y ago

IMHO the time for doing analysis like this is before submitting code, not before compiling it. Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere because you change the type something temporarily. It'd be nice to only do the work of cleaning up such issues in the final version of your change. These checks are enabled by default in many environments, build tools or scripts for them etc..., it's not trivial to disable it or requires full recompile. So I wish a language or build environment would use the concept of "development time" vs "submitting time" for different sets of warnings-as-errors.

epage 4y ago
Earlier in Rust, I saw people recommending `#![deny(warnings)]` (always turn warnings into errors) but I think the community has shifted since then because I feel like I don't see that as much and instead see people disabling warnings in CI. Speaking of warnings, something I appreciate about Rust is you only see warnings for your own code and not for your dependencies so you can crank up the warnings to whatever level you want without being blocked by dependencies (minus macros). Granted, there could be times where looking at high risk warnings for dependencies could be important.
sph 4y ago
This is one recent change in Zig which really annoys me: unused variables are now errors. Languages that complain every time there's a unused variable become useless during experimentation and quick hacking. They turn my hyperfocus into a death from a thousand paper cuts. I hate it with a passion. Please respect my mental flow, if I'm trying some ideas out, it's just rude to stop me in my tracks to tell me I forgot to comment out a variable. Who cares. I will fight anyone who thinks this is a good idea.
- noisy_boy 4y ago
  I have to agree with you. Zig already has a Debug build mode, they can just warn if you are running Debug build.

WuxiFingerHold 4y ago

> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself You can write perfectly fine solutions in a GC language without lying to yourself. > my trust level to my Rust code is around 10x more than my Python code for the same problem Python as a dynamically typed language is not the mark. Rust has a great static type system, but other GC languages offer that as well.

bergenty 4y ago

>unlearning scope As a programmer that hasn’t worked with Rust, what does that mean.

iex_xei 4y ago
e.g. You can use a variable twice when calling a function in most languages without thinking twice. I had to unlearn this :)

michaelcampbell 4y ago

> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) A quick and easy solution is still a solution, which is what most bosses want.

iex_xei 4y ago
That's true, though in my experience those quick solutions lead to more quick solutions, and in total that leads to a mess in the long run. But if that long run will never come, it may be better not to bother. These are all sensible choices.