18 ms·

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

baby 4y ago
I’d say no. Been doing Rust for 3 years now and I have decided that I will never again accept a job offer that makes me write C++ or Java.
timClicks 4y ago
No, it really is wonderful once you make it. Which resources have you used to learn?
- marcusramberg 4y ago
  Sounds like survivor bias :)
- HacklesRaised 4y ago
  I did ok with Rustlings and I read the 'The Book', I'd say I am largely struggling with async and lifetimes. I have spent most of my career in C, C++, Objective-C and have recently tried Zig, which I enjoyed, possibly because of it's brevity, and I read through the Jakt programming language docs, which was much more familiar to me but I think if you only used Rust with ARC it would be a simple language to adopt so that's not really a fair comparison. I think what I really need is a project rather than learning resources, with time being our greatest enemy, I need motivation to get over the hump so to speak. (Like I said, I might not be smart enough, or I might just be profoundly lazy). Thanks for your reply.
  - wiz21c 4y ago
    I've been leraning rust with a pet project of mine (an Apple2 emulator). That was a bit too complex for a start as I had threads and a bit of architecture to structure my code correctly. But in the end, I know understand how rust does threads and memory allocation and I'm now much less intimated by the type system. I still don't get the lifetimes. Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure). It took me about the equivalent of 30 full days to get there. Although I'm an experienced programmer (C++,assembly,Java,python,R), the last 15 years have been python 99%. Had I continued with C++ all those years, I'm sure I'd understand rust much better. So, just keep going and really listen to the borrow checker. The thing is really smart and sometimes, after a lot of pain, you understand that your own mental model was wrong :-)
    - unrealhoang 4y ago
      > Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure). Mainly because logger is a static value, if you really want to change your logger at runtime, then you have to pay a little bit for synchronization (i.e. locking with mutex), other than that, it's not that hard.
  - dgb23 4y ago
    There are some very practice oriented books for rust: zero to production, rust in action. And a third one that I didn’t read, it is game programming focused and seems pretty good. Something with “handmade”.
    - mindri0t 4y ago
      I believe the game programming one you are thinking of is “hands on rust” by Herbert Wolverson. I haven’t read all of it, the parts I have read are quite good but I’m not big into games so I switched over to rust in action.
    - timClicks 4y ago
      That's actually one of the reasons that I asked. I am the author of Rust in Action and wondered if the person having trouble had investigated one of the more practical resources.
lelanthran 4y ago
It's a language designed by people who's favourite language is not even pronounceable. Did you think that such a group of people, who place their love for the language above practical things like readability, would come up with a new language that cared about the user-experience[1]? As we see all the time WRT to programming languages, readability is more important than the more abstract stuff. > I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. That sounds like a different way of saying "the global number of CVEs will be reduced by reducing the number of applications written". After all, if you "disable" the programmers who write systems programs, they aren't going to get magically replaced by programmers who don't write systems programs. You're just gonna have fewer programmers. [1] A language is an interface between a user and their problem. If this is not highest priority of a language design, the language may never take off in any meaningful sense. See Monads.
- bruce343434 4y ago
  > It's a language designed by people who's favourite language is not even pronounceable. Elaborate?
- HacklesRaised 4y ago
  My CVE comment was very much tongue in cheek.
  - lelanthran 4y ago
    > My CVE comment was very much tongue in cheek. I got that, but the point is still very much relevant. If places switched to Rust from C++ (or Go, or C), they'd write less software because there will never be as many people who understand Rust as there are people who understand Go. If it was at all easy to pick up there'd be a fewer stories from people who tried learning it and abandoned the effort. I cannot think of any person who reported abandoning Go because it was too hard to learn.
- bitmapper 4y ago
  I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language. Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you. In my opinion, the only truly hard to read languages are languages that require you to keep large amounts of context in memory while reading a specific part of the codebase, be it due to lack of support for abstractions for proper encapsulation, messy overloading, insane inheritance hierarchies, or something else. EDIT: Readability also requires you have a codebase that's well written, and even that's subjective.
conradludgate 4y ago
Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start
- HacklesRaised 4y ago
  That's a really helpful perspective. Thanks.
- pcthrowaway 4y ago
  > Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler How would you compare it to Typescript? Having become a recent convert, I feel the same way going back to Javascript now
  - Xevi 4y ago
    I'm not the same person that you responded to, but I feel much less secure in TS than in C# due to the fact that typing is not a requirement, and that type definitions might differ from the actual library/framework code. It's still a big improvement over plain JS though.
  - the_duke 4y ago
    Typescript is great, but it is ultimately a gradually typed language that is built around compiling to Javascript, and that has extensive interaction with untyped Javascript code. You often end up with obscure issues that a good type system should prevent. Maybe because the third party typings for a package are faulty or incomplete, maybe because the compiler just gave up on a complex expression and fell back to any, or because the developer just gave up and used `as any`. Typescript is also really constrained by keeping JS compatibility. A prime example is the lack of real sumtypes. Instead you have to use objects with a string tag and do if/switch on that tag to disambiguate the concrete type, which is incredibly awkward when compared to proper compiler sum type support. I'd much rather use Typescript than Javascript, but it's far from perfect.
gspr 4y ago
I think I'm quite fad-resistant (others would use less positive words to describe the same attribute). I still find Rust truly excellent, and the most joy I've had programming since Haskell (while at the same time being a lot more mainstream and pragmatic choice for collaborative projects than Haskell).
- HacklesRaised 4y ago
  My wife calls my stubborness 'Cultural Stamina', I think it's an excellent phrase that always raises a smile. I really enjoyed Haskell when I tried it years ago (2004) and I definitely agree that Rust is much more apropos to the mainstream.
  - gspr 4y ago
    > Cultural Stamina Love it!
jstx1 4y ago
No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the past year, you ignore all the people who have tried Rust before that and didn't like it. As an extreme example, let's say I created a language in 2020, the entire software community tried it and they absolutely hated it and unanimously rejected it as the worst language ever but it still has 2 users (my mom and I) who want to keep using it - that languages would score 100% Most Loved on stackoverflow's survey even though it was hated by the overwhelming majority of people who tried it. With this formulation you create the strange effect that if people hate a language enough to stop using it, the language's most loved metric goes up after a year.
- wheelerof4te 4y ago
  This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.
  - roblabla 4y ago
    > Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit. I also never find that Rust limits or controls me in my day to day work. There are some things you cannot do easily, sure, but those things tend to not matter in application code. Linked lists are hard, graphs are hard, but when writing an app, I just use an existing dependency like petgraph or std::collections::LinkedList instead of reimplementing those datastructures. And if you need to write those things, it's not like it's impossible, you just need to drop down to unsafe rust, and ideally figure out some safe way to expose that API. Really, the biggest disadvantage of Rust is that its learning curve makes onboarding newcomers much harder if they don't have experience in the language. For Python/Go/JS/Ruby you don't really have this problem, even if a potential recruit doesn't have experience in the language, they will probably be able to pick it up as they go without too much trouble. But in Rust, it can take a fairly significant amount of time to get up to speed and stop fighting the compiler, in the order of several months.
pas 4y ago
Rust is young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.) ... I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it. To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-leven limitations hit in (JVM or JS). However I don't interpret that as a sign of oh we need to go back to assembly, but more like, okay, we need to accept that our tools and the problems we use them on are not in harmony (yet).
- purkka 4y ago
  Totally agree. Scala and TypeScript are both usually wonderful to write. Though I might argue that one of Scala's biggest issues in my eyes, performance, is mostly _not_ a JVM limitation. For example, a Scala for-loop calls functions on each iteration, and immutable containers need to be garbage collected for each modification. Both of these could be compiled away in many common cases (like C++ or Rust do, but Scala's compiler doesn't, unless they've changed that in the last couple of years).
  - kaba0 4y ago
    I don't have too deep knowledge of Scala compilers, but Scala 3 is a huge revamp so I wouldn't be surprised to see it change. Though both of the mentioned cases seems to be easy to "fix" by the JIT compiler -- the JVM is really good at inlining and short-lived objects are almost free.
    - crabbygrabby 4y ago
      Did scala 3 finally clean up the syntax. Scala is a difficult language because there are so many ways to do things. I ran away from it after dealing with it professionally off and on for a year. Which is a shame because I did a hobby project with it and it was super fun and liberating compared to old java.
      - deleted 4y ago
gernb 4y ago
I actually feel this way about C++ to some extent. I love that C++ has zero overhead abstractions. I hate that to use them requires programming in the most obtuse and indirect meta language. If you ever read, I think it was Modern C++? Where they point out the huge "trick" in C++ was someone figuring out you could make a compile time branch by declaring arrays of size 0 or some such nonsense. They then wrapped that feature in a template so you could then try to use it. At some point they formalized it so it's no longer based on arrays of size 0 but still, read any boost library and look at how unreadable it is. It might be nice to use, but it shouldn't be so hard to write! But, I think the fact that it is hard to write brings joy indirectly to many programmers. They get a dopamine hit for "solving the puzzle of finally getting their cryptic incantation to work". Maybe they write a bitset class. It takes 500-1000 lines of code. Or maybe they make a lighter weight fixed size array and again it's 1000+ lines of template code. They forget that the goal of coding is shipping, not having fun solving the incantation puzzle. It doesn't seem like it take 1000+ lines to do these things.
- zaphar 4y ago
  An application developer spending hours refining a method/class/function to it's most optimized form is usually not worth the time. It's only going to be used in the application so the ROI is much lower. The author of a library with wide usage spending hours refining a method/class/function to it's most optimzied form may actually be worth the time because that effort is amortized over hundreds or even thousands of applications. The ROI is much higher in that case. Determining when it's correct to make that tradeoff is an important part of the job. Boost probably makes the correct tradeoff. But your average C++ application dev might need to make a completely different one.
drogus 4y ago
No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc<Mutex>` and call it a day. In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request, you compute the output, you return it. Any shared state is typically behind a shared pointer (like `Arc`). I feel like this article is written from a perspective of a library author that always starts with going for zero allocations generic API. In production apps you very rarely do that, usually it's plenty fast anyway.
- dgb23 4y ago
  If you default to Arc everywhere, aren’t you essentially just implementing a slow GC? This type of thing comes up of often when people try the language. They re-implement some part of a program, originally written in a fast GC language, and then wonder why it’s slower. I feel like the power of the language comes through in specific workloads, or when you take the additional time to avoid naive code. That’s why it is so verbose and rich, it gives you more control. And this is something that advocates often clearly state.
  - therockhead 4y ago
    > If you default to Arc everywhere, aren’t you essentially just implementing a slow GC? Like I posted earlier, you don't do this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.
  - drogus 4y ago
    As @therockhead replied already: you won't put every single variable behind `Arc`. It will only be for shared state: queues, handlers that you need to move between threads/tasks etc.
- therockhead 4y ago
  > In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request Was going to post the same comment. Most of my hobbyist Rust programming has been via the Actix Webframework and I only run into the most trivial of borrow checker issues. I guess my projects are not complex or interesting enough :).
heurisko 4y ago
I am interested in Rust because of its safeguards around multithreaded programming. This is is my main motivation to learn it. What I've found good about rust is its modern toolchain and documentation.
- schleck8 4y ago
  The documentation to get started is outstanding with Rust
  - crabbygrabby 4y ago
    The advanced documentation is also incredible and crystalized a lot of cs concepts for me. There is no impedance mismatch between the beginner docs and the advanced ones, they reference extra learning materials... Super greatful for everyone on the documentation team.
- WuxiFingerHold 4y ago
  The hardest multithreading related bugs are deadlocks, which Rust doesn't prevent. So this "fearless concurrency" mantra is not entirely true.
whazor 4y ago
Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far to be doing this in Rust, whereas I would not want to try this in C++. The code I am writing is much simpler than the existing C++ code.
- blub 4y ago
  Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.
  - tcfhgj 4y ago
    I have been way more productive with Rust than with C++. For instance, I haven't yet had to debug weirdly muting memory, deal with the immense nuanced possibilities of doing the same thing (there's a reason for CPP core guidelines), stuff like the rule of five, writing cross platform cmake files that include various libraries, ... Not proof for a general statement, but another example from a Rust adaptor
    - deleted 4y ago
      [deleted]
  - crabbygrabby 4y ago
    Rust removes a lot of the debugging and performance tuning, that happens later in production. Is it easier/faster while you are learning. Nope. When you understand it, sure it could be. This depends on the person. Just like how someone might be faster or slower at a specific framework within the same language. Imo I write programs faster than other languages because the compiler helps me out. Your mileage may vary.
- 4y ago
Dowwie 4y ago
It's not a matter of smarts but grit. Modern society cultivates short attention spans, impatience, and a need for instant gratification. It's really uncomfortable, and costly, for many to spend hundreds of hours cultivating a new skillset. So, many give up shortly after starting to pursue it. However, those who persist and achieve capabilities come to value what those capabilities offer over alternatives.
- sai_c 4y ago
  If you ask an embedded developer (as in bare metal, no OS), who is also into electronics, instant gratification and especially instant feedback, is what actually makes you choose this path of interest in the first place. It's a matter of style and character how you cultivate new skills, and Rust wants you to cultivate them in a certain, some people are just not made for. YMMV.
  - Shikadi 4y ago
    I'm an embedded developer, and for me it's the opposite. Not saying everyone is like me, just saying not everyone is like you. I find regular software development to provide more instant gratification, I like the result of systems interacting with each other physically. Something about that just feels really cool to me. So much that I spent a few years as an FPGA developer, designing hardware and writing drivers for it, and also writing C on a soft core microcontroller running on an FPGA, touching registers that configure things, messing with i2c busses, I just find it all really amazing, in the same way I find car engines spinning at 6000+rpm and managing timings is incredible. Regular software development has faster results and gratification, at least from my perspective. And to be clear, I'm not saying you're wrong, or that your perspective is any less valid than mine
crabbygrabby 4y ago
Read the rust book and practice for two weeks, you'll get the hang of it. It's just not a language you can pick up 80% of it in a day. Like BASIC or Go or something
marcosdumay 4y ago
Rust is really great for a large subset of problems where there are really no good alternative. (Low level problems, where the next best alternative is C or C++. And if C++ looks better than C, it's probably not low level enough.) But if you deviate from those, into higher level programs, a language with garbage collection will always be much more productive than Rust. So we have a set of people doing the things that Rust does best, and celebrating that they have a great language, and a set of people trying to fit the square language into a round hole, and complaining that it doesn't fit at all. Added to that, there is a wide space of problems where high-level languages do not have appropriate support, but you can always hack your way in with a low level one. Those are the worst, because there is just no good option, there's just one that you can beat into working.
llllllllllll9 4y ago
rust == https://en.wikipedia.org/wiki/New_Math https://en.wikipedia.org/wiki/New_Math

baby 4y ago

I’d say no. Been doing Rust for 3 years now and I have decided that I will never again accept a job offer that makes me write C++ or Java.

timClicks 4y ago

No, it really is wonderful once you make it. Which resources have you used to learn?

marcusramberg 4y ago
Sounds like survivor bias :)
HacklesRaised 4y ago
I did ok with Rustlings and I read the 'The Book', I'd say I am largely struggling with async and lifetimes. I have spent most of my career in C, C++, Objective-C and have recently tried Zig, which I enjoyed, possibly because of it's brevity, and I read through the Jakt programming language docs, which was much more familiar to me but I think if you only used Rust with ARC it would be a simple language to adopt so that's not really a fair comparison. I think what I really need is a project rather than learning resources, with time being our greatest enemy, I need motivation to get over the hump so to speak. (Like I said, I might not be smart enough, or I might just be profoundly lazy). Thanks for your reply.
- wiz21c 4y ago
  I've been leraning rust with a pet project of mine (an Apple2 emulator). That was a bit too complex for a start as I had threads and a bit of architecture to structure my code correctly. But in the end, I know understand how rust does threads and memory allocation and I'm now much less intimated by the type system. I still don't get the lifetimes. Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure). It took me about the equivalent of 30 full days to get there. Although I'm an experienced programmer (C++,assembly,Java,python,R), the last 15 years have been python 99%. Had I continued with C++ all those years, I'm sure I'd understand rust much better. So, just keep going and really listen to the borrow checker. The thing is really smart and sometimes, after a lot of pain, you understand that your own mental model was wrong :-)
  - unrealhoang 4y ago
    > Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure). Mainly because logger is a static value, if you really want to change your logger at runtime, then you have to pay a little bit for synchronization (i.e. locking with mutex), other than that, it's not that hard.
- dgb23 4y ago
  There are some very practice oriented books for rust: zero to production, rust in action. And a third one that I didn’t read, it is game programming focused and seems pretty good. Something with “handmade”.
  - mindri0t 4y ago
    I believe the game programming one you are thinking of is “hands on rust” by Herbert Wolverson. I haven’t read all of it, the parts I have read are quite good but I’m not big into games so I switched over to rust in action.
  - timClicks 4y ago
    That's actually one of the reasons that I asked. I am the author of Rust in Action and wondered if the person having trouble had investigated one of the more practical resources.

lelanthran 4y ago

It's a language designed by people who's favourite language is not even pronounceable. Did you think that such a group of people, who place their love for the language above practical things like readability, would come up with a new language that cared about the user-experience[1]? As we see all the time WRT to programming languages, readability is more important than the more abstract stuff. > I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. That sounds like a different way of saying "the global number of CVEs will be reduced by reducing the number of applications written". After all, if you "disable" the programmers who write systems programs, they aren't going to get magically replaced by programmers who don't write systems programs. You're just gonna have fewer programmers. [1] A language is an interface between a user and their problem. If this is not highest priority of a language design, the language may never take off in any meaningful sense. See Monads.

bruce343434 4y ago
> It's a language designed by people who's favourite language is not even pronounceable. Elaborate?
HacklesRaised 4y ago
My CVE comment was very much tongue in cheek.
- lelanthran 4y ago
  > My CVE comment was very much tongue in cheek. I got that, but the point is still very much relevant. If places switched to Rust from C++ (or Go, or C), they'd write less software because there will never be as many people who understand Rust as there are people who understand Go. If it was at all easy to pick up there'd be a fewer stories from people who tried learning it and abandoned the effort. I cannot think of any person who reported abandoning Go because it was too hard to learn.
bitmapper 4y ago
I personally don't like Rust (I like to have a garbage collector for what I do), but I don't think it's a hard to read language. Readability is an incredibly subjective thing. For example, APL might look like an absolute mess to most people but to the people who know it, it's incredibly easy to read. All "readability" means in this context is that it's familiar to you. In my opinion, the only truly hard to read languages are languages that require you to keep large amounts of context in memory while reading a specific part of the codebase, be it due to lack of support for abstractions for proper encapsulation, messy overloading, insane inheritance hierarchies, or something else. EDIT: Readability also requires you have a codebase that's well written, and even that's subjective.

conradludgate 4y ago

Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start

HacklesRaised 4y ago
That's a really helpful perspective. Thanks.
pcthrowaway 4y ago
> Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler How would you compare it to Typescript? Having become a recent convert, I feel the same way going back to Javascript now
- Xevi 4y ago
  I'm not the same person that you responded to, but I feel much less secure in TS than in C# due to the fact that typing is not a requirement, and that type definitions might differ from the actual library/framework code. It's still a big improvement over plain JS though.
- the_duke 4y ago
  Typescript is great, but it is ultimately a gradually typed language that is built around compiling to Javascript, and that has extensive interaction with untyped Javascript code. You often end up with obscure issues that a good type system should prevent. Maybe because the third party typings for a package are faulty or incomplete, maybe because the compiler just gave up on a complex expression and fell back to any, or because the developer just gave up and used `as any`. Typescript is also really constrained by keeping JS compatibility. A prime example is the lack of real sumtypes. Instead you have to use objects with a string tag and do if/switch on that tag to disambiguate the concrete type, which is incredibly awkward when compared to proper compiler sum type support. I'd much rather use Typescript than Javascript, but it's far from perfect.

gspr 4y ago

I think I'm quite fad-resistant (others would use less positive words to describe the same attribute). I still find Rust truly excellent, and the most joy I've had programming since Haskell (while at the same time being a lot more mainstream and pragmatic choice for collaborative projects than Haskell).

HacklesRaised 4y ago
My wife calls my stubborness 'Cultural Stamina', I think it's an excellent phrase that always raises a smile. I really enjoyed Haskell when I tried it years ago (2004) and I definitely agree that Rust is much more apropos to the mainstream.
- gspr 4y ago
  > Cultural Stamina Love it!

jstx1 4y ago

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the past year, you ignore all the people who have tried Rust before that and didn't like it. As an extreme example, let's say I created a language in 2020, the entire software community tried it and they absolutely hated it and unanimously rejected it as the worst language ever but it still has 2 users (my mom and I) who want to keep using it - that languages would score 100% Most Loved on stackoverflow's survey even though it was hated by the overwhelming majority of people who tried it. With this formulation you create the strange effect that if people hate a language enough to stop using it, the language's most loved metric goes up after a year.

wheelerof4te 4y ago
This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.
- roblabla 4y ago
  > Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to require a lot less maintenance down the line (less bugs, easier refactoring), and so it ends up canceling out a bit. I also never find that Rust limits or controls me in my day to day work. There are some things you cannot do easily, sure, but those things tend to not matter in application code. Linked lists are hard, graphs are hard, but when writing an app, I just use an existing dependency like petgraph or std::collections::LinkedList instead of reimplementing those datastructures. And if you need to write those things, it's not like it's impossible, you just need to drop down to unsafe rust, and ideally figure out some safe way to expose that API. Really, the biggest disadvantage of Rust is that its learning curve makes onboarding newcomers much harder if they don't have experience in the language. For Python/Go/JS/Ruby you don't really have this problem, even if a potential recruit doesn't have experience in the language, they will probably be able to pick it up as they go without too much trouble. But in Rust, it can take a fairly significant amount of time to get up to speed and stop fighting the compiler, in the order of several months.

pas 4y ago

Rust is young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.) ... I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it. To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-leven limitations hit in (JVM or JS). However I don't interpret that as a sign of oh we need to go back to assembly, but more like, okay, we need to accept that our tools and the problems we use them on are not in harmony (yet).

purkka 4y ago
Totally agree. Scala and TypeScript are both usually wonderful to write. Though I might argue that one of Scala's biggest issues in my eyes, performance, is mostly _not_ a JVM limitation. For example, a Scala for-loop calls functions on each iteration, and immutable containers need to be garbage collected for each modification. Both of these could be compiled away in many common cases (like C++ or Rust do, but Scala's compiler doesn't, unless they've changed that in the last couple of years).
- kaba0 4y ago
  I don't have too deep knowledge of Scala compilers, but Scala 3 is a huge revamp so I wouldn't be surprised to see it change. Though both of the mentioned cases seems to be easy to "fix" by the JIT compiler -- the JVM is really good at inlining and short-lived objects are almost free.
  - crabbygrabby 4y ago
    Did scala 3 finally clean up the syntax. Scala is a difficult language because there are so many ways to do things. I ran away from it after dealing with it professionally off and on for a year. Which is a shame because I did a hobby project with it and it was super fun and liberating compared to old java.
    - deleted 4y ago

gernb 4y ago

I actually feel this way about C++ to some extent. I love that C++ has zero overhead abstractions. I hate that to use them requires programming in the most obtuse and indirect meta language. If you ever read, I think it was Modern C++? Where they point out the huge "trick" in C++ was someone figuring out you could make a compile time branch by declaring arrays of size 0 or some such nonsense. They then wrapped that feature in a template so you could then try to use it. At some point they formalized it so it's no longer based on arrays of size 0 but still, read any boost library and look at how unreadable it is. It might be nice to use, but it shouldn't be so hard to write! But, I think the fact that it is hard to write brings joy indirectly to many programmers. They get a dopamine hit for "solving the puzzle of finally getting their cryptic incantation to work". Maybe they write a bitset class. It takes 500-1000 lines of code. Or maybe they make a lighter weight fixed size array and again it's 1000+ lines of template code. They forget that the goal of coding is shipping, not having fun solving the incantation puzzle. It doesn't seem like it take 1000+ lines to do these things.

zaphar 4y ago
An application developer spending hours refining a method/class/function to it's most optimized form is usually not worth the time. It's only going to be used in the application so the ROI is much lower. The author of a library with wide usage spending hours refining a method/class/function to it's most optimzied form may actually be worth the time because that effort is amortized over hundreds or even thousands of applications. The ROI is much higher in that case. Determining when it's correct to make that tradeoff is an important part of the job. Boost probably makes the correct tradeoff. But your average C++ application dev might need to make a completely different one.

drogus 4y ago

No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc<Mutex>` and call it a day. In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request, you compute the output, you return it. Any shared state is typically behind a shared pointer (like `Arc`). I feel like this article is written from a perspective of a library author that always starts with going for zero allocations generic API. In production apps you very rarely do that, usually it's plenty fast anyway.

dgb23 4y ago
If you default to Arc everywhere, aren’t you essentially just implementing a slow GC? This type of thing comes up of often when people try the language. They re-implement some part of a program, originally written in a fast GC language, and then wonder why it’s slower. I feel like the power of the language comes through in specific workloads, or when you take the additional time to avoid naive code. That’s why it is so verbose and rich, it gives you more control. And this is something that advocates often clearly state.
- therockhead 4y ago
  > If you default to Arc everywhere, aren’t you essentially just implementing a slow GC? Like I posted earlier, you don't do this everywhere, just some sporadic use where it makes life a lot easier. It doesn't have to be all or nothing.
- drogus 4y ago
  As @therockhead replied already: you won't put every single variable behind `Arc`. It will only be for shared state: queues, handlers that you need to move between threads/tasks etc.
therockhead 4y ago
> In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request Was going to post the same comment. Most of my hobbyist Rust programming has been via the Actix Webframework and I only run into the most trivial of borrow checker issues. I guess my projects are not complex or interesting enough :).

heurisko 4y ago

I am interested in Rust because of its safeguards around multithreaded programming. This is is my main motivation to learn it. What I've found good about rust is its modern toolchain and documentation.

schleck8 4y ago
The documentation to get started is outstanding with Rust
- crabbygrabby 4y ago
  The advanced documentation is also incredible and crystalized a lot of cs concepts for me. There is no impedance mismatch between the beginner docs and the advanced ones, they reference extra learning materials... Super greatful for everyone on the documentation team.
WuxiFingerHold 4y ago
The hardest multithreading related bugs are deadlocks, which Rust doesn't prevent. So this "fearless concurrency" mantra is not entirely true.

whazor 4y ago

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far to be doing this in Rust, whereas I would not want to try this in C++. The code I am writing is much simpler than the existing C++ code.

blub 4y ago
Where's the proof that Rust makes it easier and faster to create applications? In my experience it's harder and slower compared to other languages like Go and even C++, but you get memory-safety in return while keeping a very good runtime performance profile.
- tcfhgj 4y ago
  I have been way more productive with Rust than with C++. For instance, I haven't yet had to debug weirdly muting memory, deal with the immense nuanced possibilities of doing the same thing (there's a reason for CPP core guidelines), stuff like the rule of five, writing cross platform cmake files that include various libraries, ... Not proof for a general statement, but another example from a Rust adaptor
  - deleted 4y ago
    [deleted]
- crabbygrabby 4y ago
  Rust removes a lot of the debugging and performance tuning, that happens later in production. Is it easier/faster while you are learning. Nope. When you understand it, sure it could be. This depends on the person. Just like how someone might be faster or slower at a specific framework within the same language. Imo I write programs faster than other languages because the compiler helps me out. Your mileage may vary.
4y ago

Dowwie 4y ago

It's not a matter of smarts but grit. Modern society cultivates short attention spans, impatience, and a need for instant gratification. It's really uncomfortable, and costly, for many to spend hundreds of hours cultivating a new skillset. So, many give up shortly after starting to pursue it. However, those who persist and achieve capabilities come to value what those capabilities offer over alternatives.

sai_c 4y ago
If you ask an embedded developer (as in bare metal, no OS), who is also into electronics, instant gratification and especially instant feedback, is what actually makes you choose this path of interest in the first place. It's a matter of style and character how you cultivate new skills, and Rust wants you to cultivate them in a certain, some people are just not made for. YMMV.
- Shikadi 4y ago
  I'm an embedded developer, and for me it's the opposite. Not saying everyone is like me, just saying not everyone is like you. I find regular software development to provide more instant gratification, I like the result of systems interacting with each other physically. Something about that just feels really cool to me. So much that I spent a few years as an FPGA developer, designing hardware and writing drivers for it, and also writing C on a soft core microcontroller running on an FPGA, touching registers that configure things, messing with i2c busses, I just find it all really amazing, in the same way I find car engines spinning at 6000+rpm and managing timings is incredible. Regular software development has faster results and gratification, at least from my perspective. And to be clear, I'm not saying you're wrong, or that your perspective is any less valid than mine

crabbygrabby 4y ago

Read the rust book and practice for two weeks, you'll get the hang of it. It's just not a language you can pick up 80% of it in a day. Like BASIC or Go or something

marcosdumay 4y ago

Rust is really great for a large subset of problems where there are really no good alternative. (Low level problems, where the next best alternative is C or C++. And if C++ looks better than C, it's probably not low level enough.) But if you deviate from those, into higher level programs, a language with garbage collection will always be much more productive than Rust. So we have a set of people doing the things that Rust does best, and celebrating that they have a great language, and a set of people trying to fit the square language into a round hole, and complaining that it doesn't fit at all. Added to that, there is a wide space of problems where high-level languages do not have appropriate support, but you can always hack your way in with a low level one. Those are the worst, because there is just no good option, there's just one that you can beat into working.

llllllllllll9 4y ago

rust == https://en.wikipedia.org/wiki/New_Math https://en.wikipedia.org/wiki/New_Math