5 ms·

I think it is a special case because the Rust people is especially annoying in their evangelism. I remember a degree of pushback on FP, because the people that

I think it is a special case because the Rust people is especially annoying in their evangelism. I remember a degree of pushback on FP, because the people that were into things such as Haskell and Scala were a little annoying with their desire to add FP everywhere too. My takeaway is that annoying evangelists get a level pushback similar to how annoying they are.

vlovich123 2y ago
One could make the argument that the rust people had to become annoying evangelists because otherwise the default is still pushback from c/c++ folks that don’t want changes.
- hu3 2y ago
  It's more than that because rust evangelists often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). So it's not only about C/C++.
  - timschmidt 2y ago
    Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet. This is so unusual, it may be unique. And I think that leads to a lot of experimentation and application of the language to the sorts of problem which typically receive attention in memory safe languages, but not compiled languages. Rust, by definition, straddles both.
    - hu3 2y ago
      > Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet. This is so unusual, it may be unique. Is that sarcasm? If not, thanks for proving my point. From the top of my head, Go/.NET/Java are fast and safe choices. Also safe in the sense that you won't have a hard time hiring devs that are productive from the get go.
      - timschmidt 2y ago
        > often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). > proving my point. Was your point misunderstanding that garbage collection != memory safety? Having garbage collection doesn't make a language any better for web dev. Being memory safe does. If you do not understand the difference and needlessly associate the two, you are validating the work put in by the evangelists.
        hu3 2y ago
        > Was your point misunderstanding that garbage collection != memory safety? What?! You really think memory safety is binary? > Having garbage collection doesn't make a language any better for web dev. It does though. It's more ergonomic than fighting rust compiler and does add safety over manual memory management from the likes of C/C++. I just want to thank you for demonstrating so clearly how rust evangelists think.
        timschmidt 2y ago
        > What?! You really think memory safety is binary? Not sure why you'd assume that. The languages you offered are only as memory safe as their runtimes, which are usually implemented in something C flavored, and the compiler for same. Rust identifies memory unsafe areas instead with the unsafe tag. Functionally equivalent but I know which I like more. > It does though. It's more ergonomic and does adds safety over manual memory management. This is the misunderstanding. Rust manages to be wonderfully ergonomic without GC. The type system is really the only thing that makes it wordier than C++. And I've written large Rust applications with no manual memory management whatsoever. Occasionally I'll have to wrap something in an Arc Mutex because something needs to run in another thread. One or two variables in a whole application. Your complaints apply to other languages.
        surgical_fire 2y ago
        Thanks for proving my original point. I rest my case.
    - germandiago 2y ago
      Java, C#, Go... Not the only one. Maybe the fastest, yes. But... at what cost? Also, I think people seem to believe that memory safety is all safeties. Attacks come in many shapes and forms, from supply chain injection, to SQL injection, to unsanitized input, overflows, secret leaking... memory safety is one of the weak points of a chain, but not the only one.
      - timschmidt 2y ago
        > Java, C#, Go... All require runtimes. Which means they're not in the same class of language as C, C++, and Rust. > Also, I think people seem to believe that memory safety is all safeties. It's 70% of CVEs in C and C++. People focus on it because it's the biggest single category. Enums and Option types and the whole type system for that matter goes a long way toward addressing logic bugs in Rust as well.
        consteval 2y ago
        > All require runtimes. Which means they're not in the same class of language as C, C++, and Rust Right, which is why it makes no sense to say "no don't use C# for webdev!! Use Rust!" They're different classes of languages. If C# is good for that use case then use it. Also there are genuine benefits to having a runtime.
        timschmidt 2y ago
        > it makes no sense to say "no don't use C# for webdev!! Use Rust!" Well, first of all, I don't see anywhere where anyone said that. Perhaps in another thread? People did argue against the use of Rust for web dev, for which it's a perfectly reasonable choice among many. Second, I have an embedded HTTP server running on a microcontroller with 500kb of ram in my current project. Works great in Rust. Simply not possible in C#. > If [any language] is good for that use case then use it. Agreed. The best camera is the one in your pocket, and the best language is the one you know. > Also there are genuine benefits to having a runtime. Things which are commonly associated with runtimes - memory safety, automatic memory management, various type systems, high level language abstractions - are all genuinely useful. Folks in this thread seem to want to hold on to a categorization of languages which Rust breaks by virtue of providing features typically only found in languages with runtimes. What Rust shows is that those benefits can be a part of a well designed language, with or without a runtime. And not having a runtime is a hard requirement in areas like embedded, OS development, realtime, etc. There is typically a separation between languages you'd use for that sort of thing and languages you might use for web dev, but the reasons for that separation do not apply to Rust. Which is fun. Some people seem to be salty about it though, lol. One significant downside to having a runtime is that it significantly complicates the process of program verification. Making it much harder to do statically. Necessitating certain things happen at runtime like error handling and performance profiling. Rust mostly has what it needs to get that work done at compile time, which means the developer has an opportunity to fix it, before some user runs into it.
  - tormeh 2y ago
    I think Rust is a good fit for webdev, if you have programmers who already know or actively want to learn Rust, and if you don't need libraries not available for Rust. Admittedly those are some big caveats, but better latency and throughput are never bad things. The lack of GC is not actually a problem once you have internalized the rules of the borrow checker. The only big problem I see with Rust that makes it a bad fit for webdev is the young ecosystem. The compile times are not great, but I don't think that's a significant issue when writing APIs.
- EasyMark 2y ago
  Or they could just carry on with their preferred language and not start shaming the shame bell until you repent your ungodly c++ ways. I think we have to consider both sides, weigh the languages and costs, including cost of writing a new code base and training new programmers.
- germandiago 2y ago
  I do want changes in C++, but believe me, the Safe C++ proposal (a copy of Rust typesystem on top of C++) that was sent to WG21 is not the push I would like for safety in C++ for reasons beyond the scope of Rust.
kobalsky 2y ago
we gotta admit that not using, let's say screwdrivers, because some annoying people made a silly religion around them calls for some introspection.
- surgical_fire 2y ago
  Except all languages are screwdrivers in this analogy. However, There here are some immensely annoying people (just see other replies here) that can't fucking shut up about how their screwdriver of choice is better.
  - kobalsky 2y ago
    the point is that if some screwdriver is objectively better (doesn't snap and takes your eye off when you make a mistake) then the decision to use it shouldn't be affected by who recommends it.
    - surgical_fire 2y ago
      > objectively better Except it is not. As any other language, it has many potential upsides and downsides in picking it depending on the context. This lack of nuanced thinking from evangelists is precisely why some people just prefer to shut it off entirely.
      - orf 2y ago
        So what you’re saying is: I like to program in C/C++ and don't plan to change, thankyouverymuch?
        surgical_fire 2y ago
        No. I am saying that depending on the context I might pick Go. Or Java. Or Python. Or Node. Or C#.
    - germandiago 2y ago
kccqzy 2y ago
A lot of times they are the same people. The Haskell community really isn't as active as it was five or even ten years ago, and many of those Haskell evangelists became Rust evangelists. Some people are just attracted to using the most "advanced" language (for whatever definition of "advanced" that's in vogue) and some of them are extremely vocal about that.
- tome 2y ago
  The Haskell community is admittedly less active in promoting niche concepts like zygohistic prepomorphisms, but much more active in building out a solid ecosystem. You won't hear much about the latter because it isn't shiny and weird.
  - kccqzy 2y ago
    How has the ecosystem become more solid in recent years? All of the important Haskell libraries I use were initially released eight years ago or before then. While I personally don't like people promoting niche concepts as well (I'd rather have them promote building out a solid ecosystem as you say), I still feel the "brain drain" out of the Haskell community.
    - tome 2y ago
      * We now have ghcup, a solid way to install Haskell (inspired by rustup, I believe). It used to be that you got access to one GHC package from your Linux distribution if you were lucky, otherwise you had to install manually from a bindist. * We now have HLS, which integrates superbly with VS Code (it's also fine in Emacs and I guess in other editors, but I don't know). It can be flaky on large codebases, but it's a big step up from what we had before (which was almost nothing). * GHC and bundled libraries have a much higher degree of API stability. In fact in the last 18 months there has been minimal breakage due to new GHC releases[1]. Community libraries are a bit more of a mixed bag, but there's much more awareness in the community that continual API breakage churn is harmful for adoption. * We now have the Haskell Foundation[2] supporting all sorts of critical ecosystem activity behind the scenes, and helping people work together harmoniously. There used to be extremely fraught and unpleasant interpersonal battles in the community. Those are a thing of the past. * We now have solid effect systems (Bluefin[3] and effectful) that combine the best of the transformers world (build effects from components, type safety, handle effects and remove them from the type) and the IO-based world (predictable performance, resource safety, escape hatches). I'm willing to boldly claim that effects are no longer a problem in Haskell. I'm in the same boat as you: I don't use particularly man new libraries. Is that a problem? I'm given to understand that in the Java world that's called "Monday". Sure, I would have liked it if certain community members had stayed more active, but I don't feel I'm missing anything in particular. (That may just be to do with what I work on.) What are you missing? [1] See * https://github.com/tomjaguarpaw/tilapia/blob/master/breakage-inventory-ghc-9.8.md https://github.com/tomjaguarpaw/tilapia/blob/master/breakage... * https://github.com/tomjaguarpaw/tilapia/blob/master/breakage-inventory-ghc-9.10.md https://github.com/tomjaguarpaw/tilapia/blob/master/breakage... [2] Disclaimer: I'm the vice chair [3] Disclaimer: I'm the effect system author
tormeh 2y ago
I was one of the people that were really enthusiastic about Scala. But back then even as an enthusiast I had to admit Scala had a lot of drawbacks. Every bad thing inherited from Java, to start, and the leaky abstractions that forced, as well as the learning curve. Maybe the worst part was how easy Scala made it to write completely unintelligible code. Scala could effortlessly tap into the Java ecosystem, though. Rust is much easier to recommend than Scala ever was. Rust's ecosystem is a bit smaller than you'd typically like, but that's a temporary problem.
germandiago 2y ago
> I think it is a special case because the Rust people is especially annoying in their evangelism I would say that what is bad about this is like they seem to think there is no other way. There is "the true Rust way" and after that, the others. At least I got that attitude, because when claims have been done about why the only path to Safe C++ is to copy Rust and I question it, they reply as "what you say is impossible" and I show them there are ways, then they move the attack somewhere else, even I have been accused of "wasting their time"...

vlovich123 2y ago

One could make the argument that the rust people had to become annoying evangelists because otherwise the default is still pushback from c/c++ folks that don’t want changes.

hu3 2y ago
It's more than that because rust evangelists often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). So it's not only about C/C++.
- timschmidt 2y ago
  Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet. This is so unusual, it may be unique. And I think that leads to a lot of experimentation and application of the language to the sorts of problem which typically receive attention in memory safe languages, but not compiled languages. Rust, by definition, straddles both.
  - hu3 2y ago
    > Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet. This is so unusual, it may be unique. Is that sarcasm? If not, thanks for proving my point. From the top of my head, Go/.NET/Java are fast and safe choices. Also safe in the sense that you won't have a hard time hiring devs that are productive from the get go.
    - timschmidt 2y ago
      > often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). > proving my point. Was your point misunderstanding that garbage collection != memory safety? Having garbage collection doesn't make a language any better for web dev. Being memory safe does. If you do not understand the difference and needlessly associate the two, you are validating the work put in by the evangelists.
      - hu3 2y ago
        > Was your point misunderstanding that garbage collection != memory safety? What?! You really think memory safety is binary? > Having garbage collection doesn't make a language any better for web dev. It does though. It's more ergonomic than fighting rust compiler and does add safety over manual memory management from the likes of C/C++. I just want to thank you for demonstrating so clearly how rust evangelists think.
        timschmidt 2y ago
        > What?! You really think memory safety is binary? Not sure why you'd assume that. The languages you offered are only as memory safe as their runtimes, which are usually implemented in something C flavored, and the compiler for same. Rust identifies memory unsafe areas instead with the unsafe tag. Functionally equivalent but I know which I like more. > It does though. It's more ergonomic and does adds safety over manual memory management. This is the misunderstanding. Rust manages to be wonderfully ergonomic without GC. The type system is really the only thing that makes it wordier than C++. And I've written large Rust applications with no manual memory management whatsoever. Occasionally I'll have to wrap something in an Arc Mutex because something needs to run in another thread. One or two variables in a whole application. Your complaints apply to other languages.
        surgical_fire 2y ago
        Thanks for proving my original point. I rest my case.
  - germandiago 2y ago
    Java, C#, Go... Not the only one. Maybe the fastest, yes. But... at what cost? Also, I think people seem to believe that memory safety is all safeties. Attacks come in many shapes and forms, from supply chain injection, to SQL injection, to unsanitized input, overflows, secret leaking... memory safety is one of the weak points of a chain, but not the only one.
    - timschmidt 2y ago
      > Java, C#, Go... All require runtimes. Which means they're not in the same class of language as C, C++, and Rust. > Also, I think people seem to believe that memory safety is all safeties. It's 70% of CVEs in C and C++. People focus on it because it's the biggest single category. Enums and Option types and the whole type system for that matter goes a long way toward addressing logic bugs in Rust as well.
      - consteval 2y ago
        > All require runtimes. Which means they're not in the same class of language as C, C++, and Rust Right, which is why it makes no sense to say "no don't use C# for webdev!! Use Rust!" They're different classes of languages. If C# is good for that use case then use it. Also there are genuine benefits to having a runtime.
        timschmidt 2y ago
        > it makes no sense to say "no don't use C# for webdev!! Use Rust!" Well, first of all, I don't see anywhere where anyone said that. Perhaps in another thread? People did argue against the use of Rust for web dev, for which it's a perfectly reasonable choice among many. Second, I have an embedded HTTP server running on a microcontroller with 500kb of ram in my current project. Works great in Rust. Simply not possible in C#. > If [any language] is good for that use case then use it. Agreed. The best camera is the one in your pocket, and the best language is the one you know. > Also there are genuine benefits to having a runtime. Things which are commonly associated with runtimes - memory safety, automatic memory management, various type systems, high level language abstractions - are all genuinely useful. Folks in this thread seem to want to hold on to a categorization of languages which Rust breaks by virtue of providing features typically only found in languages with runtimes. What Rust shows is that those benefits can be a part of a well designed language, with or without a runtime. And not having a runtime is a hard requirement in areas like embedded, OS development, realtime, etc. There is typically a separation between languages you'd use for that sort of thing and languages you might use for web dev, but the reasons for that separation do not apply to Rust. Which is fun. Some people seem to be salty about it though, lol. One significant downside to having a runtime is that it significantly complicates the process of program verification. Making it much harder to do statically. Necessitating certain things happen at runtime like error handling and performance profiling. Rust mostly has what it needs to get that work done at compile time, which means the developer has an opportunity to fix it, before some user runs into it.
- tormeh 2y ago
  I think Rust is a good fit for webdev, if you have programmers who already know or actively want to learn Rust, and if you don't need libraries not available for Rust. Admittedly those are some big caveats, but better latency and throughput are never bad things. The lack of GC is not actually a problem once you have internalized the rules of the borrow checker. The only big problem I see with Rust that makes it a bad fit for webdev is the young ecosystem. The compile times are not great, but I don't think that's a significant issue when writing APIs.
EasyMark 2y ago
Or they could just carry on with their preferred language and not start shaming the shame bell until you repent your ungodly c++ ways. I think we have to consider both sides, weigh the languages and costs, including cost of writing a new code base and training new programmers.
germandiago 2y ago
I do want changes in C++, but believe me, the Safe C++ proposal (a copy of Rust typesystem on top of C++) that was sent to WG21 is not the push I would like for safety in C++ for reasons beyond the scope of Rust.

kobalsky 2y ago

we gotta admit that not using, let's say screwdrivers, because some annoying people made a silly religion around them calls for some introspection.

surgical_fire 2y ago
Except all languages are screwdrivers in this analogy. However, There here are some immensely annoying people (just see other replies here) that can't fucking shut up about how their screwdriver of choice is better.
- kobalsky 2y ago
  the point is that if some screwdriver is objectively better (doesn't snap and takes your eye off when you make a mistake) then the decision to use it shouldn't be affected by who recommends it.
  - surgical_fire 2y ago
    > objectively better Except it is not. As any other language, it has many potential upsides and downsides in picking it depending on the context. This lack of nuanced thinking from evangelists is precisely why some people just prefer to shut it off entirely.
    - orf 2y ago
      So what you’re saying is: I like to program in C/C++ and don't plan to change, thankyouverymuch?
      - surgical_fire 2y ago
        No. I am saying that depending on the context I might pick Go. Or Java. Or Python. Or Node. Or C#.
  - germandiago 2y ago

kccqzy 2y ago

A lot of times they are the same people. The Haskell community really isn't as active as it was five or even ten years ago, and many of those Haskell evangelists became Rust evangelists. Some people are just attracted to using the most "advanced" language (for whatever definition of "advanced" that's in vogue) and some of them are extremely vocal about that.

tome 2y ago
The Haskell community is admittedly less active in promoting niche concepts like zygohistic prepomorphisms, but much more active in building out a solid ecosystem. You won't hear much about the latter because it isn't shiny and weird.
- kccqzy 2y ago
  How has the ecosystem become more solid in recent years? All of the important Haskell libraries I use were initially released eight years ago or before then. While I personally don't like people promoting niche concepts as well (I'd rather have them promote building out a solid ecosystem as you say), I still feel the "brain drain" out of the Haskell community.
  - tome 2y ago
    * We now have ghcup, a solid way to install Haskell (inspired by rustup, I believe). It used to be that you got access to one GHC package from your Linux distribution if you were lucky, otherwise you had to install manually from a bindist. * We now have HLS, which integrates superbly with VS Code (it's also fine in Emacs and I guess in other editors, but I don't know). It can be flaky on large codebases, but it's a big step up from what we had before (which was almost nothing). * GHC and bundled libraries have a much higher degree of API stability. In fact in the last 18 months there has been minimal breakage due to new GHC releases[1]. Community libraries are a bit more of a mixed bag, but there's much more awareness in the community that continual API breakage churn is harmful for adoption. * We now have the Haskell Foundation[2] supporting all sorts of critical ecosystem activity behind the scenes, and helping people work together harmoniously. There used to be extremely fraught and unpleasant interpersonal battles in the community. Those are a thing of the past. * We now have solid effect systems (Bluefin[3] and effectful) that combine the best of the transformers world (build effects from components, type safety, handle effects and remove them from the type) and the IO-based world (predictable performance, resource safety, escape hatches). I'm willing to boldly claim that effects are no longer a problem in Haskell. I'm in the same boat as you: I don't use particularly man new libraries. Is that a problem? I'm given to understand that in the Java world that's called "Monday". Sure, I would have liked it if certain community members had stayed more active, but I don't feel I'm missing anything in particular. (That may just be to do with what I work on.) What are you missing? [1] See * https://github.com/tomjaguarpaw/tilapia/blob/master/breakage-inventory-ghc-9.8.md https://github.com/tomjaguarpaw/tilapia/blob/master/breakage... * https://github.com/tomjaguarpaw/tilapia/blob/master/breakage-inventory-ghc-9.10.md https://github.com/tomjaguarpaw/tilapia/blob/master/breakage... [2] Disclaimer: I'm the vice chair [3] Disclaimer: I'm the effect system author

tormeh 2y ago

I was one of the people that were really enthusiastic about Scala. But back then even as an enthusiast I had to admit Scala had a lot of drawbacks. Every bad thing inherited from Java, to start, and the leaky abstractions that forced, as well as the learning curve. Maybe the worst part was how easy Scala made it to write completely unintelligible code. Scala could effortlessly tap into the Java ecosystem, though. Rust is much easier to recommend than Scala ever was. Rust's ecosystem is a bit smaller than you'd typically like, but that's a temporary problem.

germandiago 2y ago

> I think it is a special case because the Rust people is especially annoying in their evangelism I would say that what is bad about this is like they seem to think there is no other way. There is "the true Rust way" and after that, the others. At least I got that attitude, because when claims have been done about why the only path to Safe C++ is to copy Rust and I question it, they reply as "what you say is impossible" and I show them there are ways, then they move the attack somewhere else, even I have been accused of "wasting their time"...