8 ms·

I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many pr

by troad 2y ago

I am a fan of Rust for systems programming, but so many people are using Rust for things that are nothing even remotely close to systems programming. So many projects you see being written (or rewritten) in Rust are projects where I just think 'wait, why can't this just have a GC'? And then you look at the code base, and it's all Arc<Mutex<RefCell>>s, and you can't help at marvel at this, since that's just GC, so what's the benefit of Rust here, exactly? (Don't @ me, ARC is GC.) I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. People will brag about Rust's memory safety, and then you find out that they don't really know how lifetimes work, they just .clone() or Arc<Mutex<RefCell>> everything. Which is totally valid, but Rust is hardly necessary for that. Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right.

CharlieDigital 2y ago
> I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. F# seems like a good option.
- cmrdporcupine 2y ago
  Or just OCaml
  - sunshowers 2y ago
    OCaml is an excellent language, but doesn't it have a GIL?
    - throwitaway1123 2y ago
      Multicore OCaml finally landed a few years ago: https://news.ycombinator.com/item?id=34013767 https://news.ycombinator.com/item?id=34013767
- satvikpendem 2y ago
  How is F# on non-Microsoft platforms, is it fully cross platform? I don't use C#, .NET, or F# so I have no idea about the ecosystem.
  - mathw 2y ago
    Yes F# has come along for the ride with modern .NET and it's as cross-platform as C# is. However, a lot of the really shiny .NET stuff is tooled up mostly for C# users, so it can be a challenge if you wanted to do something like a .NET MAUI (cross-platform GUI library) application in F# because the tooling and the content out there to teach you about it assumes C#. F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support. Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me. Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.
    - scns 2y ago
      > C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed) Why not name it Traits?
  - CharlieDigital 2y ago
    Really good. I'm in a startup using .NET. We deploy to a variety of targets including AWS t4g (Arm64) instances in AWS as well as x86/64 targets in GCP. All devs are on M1 Macs. Our build pipeline is GitHub Actions Linux runners. Our DB is either AWS RDS Postgres or GCP Cloud SQL Postgres with a mix of EF Core as ORM and Dapper (for more complex read queries). C# has, over the years, converged with TypeScript so they are very similar[0] (though no Duck typing in C#). Good mix of OOP and FP paradigms borrowed from F#. F# interoperates with C# so it can tap into the larger C# ecosystem. It's a good platform; very productive. CLI has a functional hot reload (much more limited than Node on JS as the granularity of module replacement isn't quite as good). [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
- akkad33 2y ago
  F#is not C like and it's tooling and packaging is not as good as rust. Last time I checked it had multiple packaging solutions like paket and nuget. The tooling on vscode can be buggy
  - pjmlp 2y ago
    Easy, stay with .NET standard tools, MSBuild. There is also Visual Studio and Rider.
    - antonvs 2y ago
      > stay with .NET standard tools That’s a dealbreaker in many situations.
      - piaste 2y ago
        Such as? They're cross-platform and MIT licensed.
      - pjmlp 2y ago
        Then probably .NET isn't an ecosystem for you, that is fine, there are other options.
      - CharlieDigital 2y ago
        If you haven't used .NET since the early 2000's, I'd recommend checking out current `dotnet` CLI and tool chain.
sunshowers 2y ago
I'm just really leery of using languages that don't have a clear separation between immutable and mutable state. Having it in Rust catches so many bugs. I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at. edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality. If I pass in a slice of something, I'm no longer worried that something ten layers down will change it. Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.) ADTs mean dependencies represent fewer illegal states internally. It's just really nice to write code where the bugs are a couple levels up from bullshit like this.
- rtpg 2y ago
  I think this is a legit sort of reasoning, but in an interesting way it's something where OCaml could fill the gap. It has its ergonomics issues, but I think the issues are basically the same/worse in Rust (except I guess Rust's macro system is better). I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.
  - sunshowers 2y ago
    OCaml is definitely something I'd consider using if I didn't already live and breathe Rust :) I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)
  - tomtheelder 2y ago
    I like OCaml a lot as a language, but the tooling is very, very poor by modern standards. Poor enough that I think it’s a total blocker on wider adoption.
andrewjf 2y ago
I came to Rust from Ruby-on-Rails and I’m absolutely done with method_missing and finding nils and NoMethodError in production. This is not remotely a trade off I’m interested in making.
- cies 2y ago
  Having written some Rust and a lot of Ruby, I find Kotlin to be a really nice "typed Ruby". Just like Ruby, Kotlin is an OO language in the core that is really friendly to FP. It's terse (not as terse as Ruby, as there are types to specify); but MUCH terser that Java. Kotlin is serious about null-safety.
saghm 2y ago
> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that. Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").
- jeroenvlek 2y ago
  Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless. It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one? I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.
pjmlp 2y ago
Which is a classical example of everything is a nail.
chrismorgan 2y ago
> Don't @ me, ARC is GC. Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.
mrbonner 2y ago
I think RC and clone are the way people begin to use Rust. While lots of criticism are against this usage for not idiomatic, it should be acceptable. Coming from Python, nodejs or Ruby, even RC and clone or stack based variables is still a magnitude faster than those languages. When it's about absolute control for performance you can drop down a notch to the borrow checker behavior.
- mathw 2y ago
  That's an interesting perspective I'd not considered before. Maybe there are different "registers" of Rust, in the same sense that linguists talk about registers in human languages, where you use your language differently for different purposes. And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.
  - Philpax 2y ago
    You may be interested in https://without.boats/blog/the-registers-of-rust/ https://without.boats/blog/the-registers-of-rust/ :)
  - LtdJorge 2y ago
    I think Rc<Box<T>> could be simplified to Rc<T>.
  - scotty79 2y ago
    I'm gonna plug my Rust "invention" here: Show HN: How to program in Rust as if it was old school C++ with pointers https://news.ycombinator.com/item?id=34067924 https://news.ycombinator.com/item?id=34067924
wiz21c 2y ago
I do some systems programming, use rust for that and I am exactly the person you describe :-)
fire_lake 2y ago
People want everything in one language.
berkes 2y ago
> that are nothing even remotely close to systems programming This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably. Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult). * Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker. * Its multithreading is stellar. The borrow checker helps a lot in making it such. * Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with. * Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have. * Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc. * Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented. I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C. All have their strengths and weaknesses. Their place and use-cases. But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.
- biztos 2y ago
  I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you don’t have to chmod.
  - berkes 2y ago
    Certainly. A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone! My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.
cultofmetatron 2y ago
> - Phoenix on Elixir! Yes, it's not quite so blazing fast As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)
madeofpalk 2y ago
Is Rust only for "systems programming"?
- gbin 2y ago
  I would say it shines when you have systems constraints, for example embedded & robotics work well with Rust. You cannot have a GC (either you don't have a heap or you cannot tolerate a GC pause resp.) but you still have the benefits of a good functional programming language to write your algorithms in. The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.
- scotty79 2y ago
  System programmers thinks so. I guess that if all you do is hammer nails then a multitool is just a hammer.
antonvs 2y ago
> Go try Ruby on Rails for a while! You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits. I’m sure it made sense in your head.
scotty79 2y ago
If Rust had no borrowing at all, just Rc<> everywhere I'd lose maybe 5% interest in it, maybe less. Value orientation and Traits system, close to bare metal speed and stellar stdlib are what's most interesting for me.
jokethrowaway 2y ago
I agree the type system is the best feature of Rust but neither Ruby or Elixir have the level of type safety and type expressiveness of Rust. I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std). Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this? I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.
IgorPartola 2y ago
After reading endless insufferable comments on HN a la “this should have been written in Rust” I realized that there is a very strong possibility that the people making those comments do not know another language. We saw this with JavaScript a decade ago. Before that it was Ruby.
keybored 2y ago
> Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right. Who changes their minds about what to do for fun because someone on HN thought it was unnecessary? Doing what some random person wants instead because they want to be “heretical” (because it’s a religion right) sounds like the opposite of fun to me. But I’ll see you on the next thread about making a Rube Goldberg web server in C++ templates. Or some such very necessary and “approved for prod by HN” thing.

by troad 2y ago

CharlieDigital 2y ago

> I think a lot of what people actually like about Rust, to be honest, is that it's essentially an ML language masquerading as a C-like, with a stellar packaging and tooling story. F# seems like a good option.

cmrdporcupine 2y ago
Or just OCaml
- sunshowers 2y ago
  OCaml is an excellent language, but doesn't it have a GIL?
  - throwitaway1123 2y ago
    Multicore OCaml finally landed a few years ago: https://news.ycombinator.com/item?id=34013767 https://news.ycombinator.com/item?id=34013767
satvikpendem 2y ago
How is F# on non-Microsoft platforms, is it fully cross platform? I don't use C#, .NET, or F# so I have no idea about the ecosystem.
- mathw 2y ago
  Yes F# has come along for the ride with modern .NET and it's as cross-platform as C# is. However, a lot of the really shiny .NET stuff is tooled up mostly for C# users, so it can be a challenge if you wanted to do something like a .NET MAUI (cross-platform GUI library) application in F# because the tooling and the content out there to teach you about it assumes C#. F# can usually handle C# things - they put a lot of work into ensuring interop with new C# features - but the languages are from different paradigms so it is sometimes a bit awkward despite F#'s comprehensive OO support. Personally I struggle a bit with F# because it doesn't have typeclasses, and a language that looks that much like Haskell but doesn't have typeclasses just feels weird to me. Although it might get them... C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed), so F# could presumably piggyback on that if they wanted.
  - scns 2y ago
    > C# are looking at adding a traits-type feature (they don't seem to know what to call it yet, but the design's been kicking around the language team for ages now and keeps getting discussed) Why not name it Traits?
- CharlieDigital 2y ago
  Really good. I'm in a startup using .NET. We deploy to a variety of targets including AWS t4g (Arm64) instances in AWS as well as x86/64 targets in GCP. All devs are on M1 Macs. Our build pipeline is GitHub Actions Linux runners. Our DB is either AWS RDS Postgres or GCP Cloud SQL Postgres with a mix of EF Core as ORM and Dapper (for more complex read queries). C# has, over the years, converged with TypeScript so they are very similar[0] (though no Duck typing in C#). Good mix of OOP and FP paradigms borrowed from F#. F# interoperates with C# so it can tap into the larger C# ecosystem. It's a good platform; very productive. CLI has a functional hot reload (much more limited than Node on JS as the granularity of module replacement isn't quite as good). [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
akkad33 2y ago
F#is not C like and it's tooling and packaging is not as good as rust. Last time I checked it had multiple packaging solutions like paket and nuget. The tooling on vscode can be buggy
- pjmlp 2y ago
  Easy, stay with .NET standard tools, MSBuild. There is also Visual Studio and Rider.
  - antonvs 2y ago
    > stay with .NET standard tools That’s a dealbreaker in many situations.
    - piaste 2y ago
      Such as? They're cross-platform and MIT licensed.
    - pjmlp 2y ago
      Then probably .NET isn't an ecosystem for you, that is fine, there are other options.
    - CharlieDigital 2y ago
      If you haven't used .NET since the early 2000's, I'd recommend checking out current `dotnet` CLI and tool chain.

sunshowers 2y ago

I'm just really leery of using languages that don't have a clear separation between immutable and mutable state. Having it in Rust catches so many bugs. I also want to write code in languages where you don't have to engage in bad software engineering practices to get optimal performance. That usually means aggressive inlining, something that Rust excels at. edit: the other thing I wanted to mention is that rust's features cause dependencies to be pretty high quality. If I pass in a slice of something, I'm no longer worried that something ten layers down will change it. Error handling is explicit and panics are rare, so I'm not worried that dependencies will start throwing exceptions after an update. (This is the reason functions should indicate errors in type signatures—a better ecosystem.) ADTs mean dependencies represent fewer illegal states internally. It's just really nice to write code where the bugs are a couple levels up from bullshit like this.

rtpg 2y ago
I think this is a legit sort of reasoning, but in an interesting way it's something where OCaml could fill the gap. It has its ergonomics issues, but I think the issues are basically the same/worse in Rust (except I guess Rust's macro system is better). I say this as a Rust enjoyer, but I take the pain because I _really_ want what I'm working on to be fast.
- sunshowers 2y ago
  OCaml is definitely something I'd consider using if I didn't already live and breathe Rust :) I use Rust often for things that aren't possible in other languages, so I also use it for things that are possible in other languages. (Though I used Python for a production and an art project recently -- with uv it's quite nice.)
- tomtheelder 2y ago
  I like OCaml a lot as a language, but the tooling is very, very poor by modern standards. Poor enough that I think it’s a total blocker on wider adoption.

andrewjf 2y ago

I came to Rust from Ruby-on-Rails and I’m absolutely done with method_missing and finding nils and NoMethodError in production. This is not remotely a trade off I’m interested in making.

cies 2y ago
Having written some Rust and a lot of Ruby, I find Kotlin to be a really nice "typed Ruby". Just like Ruby, Kotlin is an OO language in the core that is really friendly to FP. It's terse (not as terse as Ruby, as there are types to specify); but MUCH terser that Java. Kotlin is serious about null-safety.

saghm 2y ago

> What people fall in love with is the rigorous static typing, the Option monad, the exhaustive enums (which are just sum types in disguise), the traits (type classes in disguise), the borrow checker (a half-way house to immutability) etc. I feel like I say this every time this sort of discussion comes up, but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation. Most of the time I bring this up, someone will suggest something like Swift or OCaml, but I think the part people miss is how even despite all of the complexity that comes with being a systems programming language, Rust really goes out of its way to try to be developer friendly despite that. Yes, it's a meme that Rust programmers are zealous evangelists and want to rewrite the world in it (which is a bit of an exaggeration in terms of lumping all Rust enthusiasts into that group, but there's certainly an element of truth in it), but no one seems to talk about how _weird_ of an idea it is for a language notorious for having a terrible learning curve to be so popular with people perceived to be lacking real-world experience with the domain. How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively? You might chalk some of it up to marketing, but I think people undervalue how much effort is put into the little details in Rust to try to make it more approachable, like error messages, standard library documentation, first-class support for all major platforms, and high-quality introductory materials (e.g. both the original and rewritten The Rust Programming Language book, Rust by Example, Rustlings). I don't think the same experience is there if you want to use Swift on Linux (where the support isn't nearly as strong, and a lot of the fancy new things coming out won't be available) or OCaml (from googling right now, a debate on reddit about "which stdlib should I use as a beginner" is on the first page of results when I search "ocaml std" or "ocaml stdlib").

jeroenvlek 2y ago
Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless. It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one? I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.

pjmlp 2y ago

Which is a classical example of everything is a nail.

chrismorgan 2y ago

> Don't @ me, ARC is GC. Don’t know if you intended this joke, but some time before Rust 1.0, @ was the sigil for garbage collection types (@T, like &T these days). Which I think was just reference counting, without even a cycle collector, because was shown to be undesirable before it could be improved.

mrbonner 2y ago

I think RC and clone are the way people begin to use Rust. While lots of criticism are against this usage for not idiomatic, it should be acceptable. Coming from Python, nodejs or Ruby, even RC and clone or stack based variables is still a magnitude faster than those languages. When it's about absolute control for performance you can drop down a notch to the borrow checker behavior.

mathw 2y ago
That's an interesting perspective I'd not considered before. Maybe there are different "registers" of Rust, in the same sense that linguists talk about registers in human languages, where you use your language differently for different purposes. And thus, maybe if you're writing something that doesn't need to be screamingly fast absolutely all the time there's a register of Rust where putting lots of things in Rc<Box<T>> is completely acceptable, in much the same way that you might use a lot of impolite words around your friends but you don't in front of your employer.
- Philpax 2y ago
  You may be interested in https://without.boats/blog/the-registers-of-rust/ https://without.boats/blog/the-registers-of-rust/ :)
- LtdJorge 2y ago
  I think Rc<Box<T>> could be simplified to Rc<T>.
- scotty79 2y ago
  I'm gonna plug my Rust "invention" here: Show HN: How to program in Rust as if it was old school C++ with pointers https://news.ycombinator.com/item?id=34067924 https://news.ycombinator.com/item?id=34067924

wiz21c 2y ago

I do some systems programming, use rust for that and I am exactly the person you describe :-)

fire_lake 2y ago

People want everything in one language.

berkes 2y ago

> that are nothing even remotely close to systems programming This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably. Sure, rust is primarily a language aimed at systems programming. But it also is so much more (and also a cult). * Its type system is excellent. Especially the lack of a "null". Even if, like me, you're fine with a GC, the type system alone is worth dealing with this insistent borrow-checker. * Its multithreading is stellar. The borrow checker helps a lot in making it such. * Its mutable/immutable model is highly practical. It's what makes the threading stellar and the type system more useful than in any other language I worked with. * Its "oop" model is uncomfortable at first (coming from Ruby and Java) but forcing the "composition over inheritance" by not having inheritance is probably the best thing that can happen to "OOP". Every solution where I used inheritance, I shouldn't have. * Its culture of "making the good way the easy way", being opinionated, and a community that adheres to this, is worth dealing with a thousand borrow-checker WTFs. cargo fmt, clippy, etc. * Its build system that generates binaries that can just be "plopped" onto a server, "chmod +x" -ed, and ran is unprecedented. I come from Ruby, Java, Javascript (typescript). I do a lot of Python, maintain some go services, have decades of PHP under the belt and occasionally dabble in some C and even C++. I can find my way around in a C# codebase and Objective-C. All have their strengths and weaknesses. Their place and use-cases. But rust, for me, is the only "ecosystem" that ticks all checkboxes in nearly all situations. It has downsides, and I consider the borrow-checker to be one of them in a lot of my use-cases, but it's something I'm willing to deal with gladly, because rust's other benefits.

biztos 2y ago
I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you don’t have to chmod.
- berkes 2y ago
  Certainly. A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone! My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.

cultofmetatron 2y ago

> - Phoenix on Elixir! Yes, it's not quite so blazing fast As someone running a fairly cpu heavy SAAS application for users who literally dog pile our whatsapp support forums if it goes down for even a second, Phoenix is pretty damn fast in production. I won't claim its as fast as rust but it will run circles around ruby or python and for IO bound tasks, competes perfectly fine with go. Its never been a bottleneck (database is another story)

madeofpalk 2y ago

Is Rust only for "systems programming"?

gbin 2y ago
I would say it shines when you have systems constraints, for example embedded & robotics work well with Rust. You cannot have a GC (either you don't have a heap or you cannot tolerate a GC pause resp.) but you still have the benefits of a good functional programming language to write your algorithms in. The benefits are less obvious if you have less of those constraints: go is way way simpler to write large codebases for cloud applications in and still provide an excellent concurrency support. Python is way better for experimenting.
scotty79 2y ago
System programmers thinks so. I guess that if all you do is hammer nails then a multitool is just a hammer.

antonvs 2y ago

> Go try Ruby on Rails for a while! You gave a long list of benefits of Rust - which should have answered your own question - and then suggested people use an ecosystem with almost none of those benefits. I’m sure it made sense in your head.

scotty79 2y ago

If Rust had no borrowing at all, just Rc<> everywhere I'd lose maybe 5% interest in it, maybe less. Value orientation and Traits system, close to bare metal speed and stellar stdlib are what's most interesting for me.

jokethrowaway 2y ago

I agree the type system is the best feature of Rust but neither Ruby or Elixir have the level of type safety and type expressiveness of Rust. I'd recommend Haskell as an alternative, but Rust "fixes" plenty of long term Haskell annoyances (especially around laziness by default, concurrency, unsafe std). Being able to use Arc<Mutex<T>>, Rc<RefCell<T>> and other smart pointers gives you granularity and control over what happens to your memory. I think it's a nice feature to have to mentally reason about your memory usage (incidentally a weak point in Haskell); even if it were on-par with a GC implementation-wise, why use a GC over this? I like to have control over my code (and I'm probably one of the few who think monad transformers in haskell were a good feature - despite their clunkiness) and I'd pick explicit code over "magic garbage collection in the background" any day. This is not to say I like verbosity for verbosity's sake (eg. think React Redux in JS vs the implementation of the same idea in Elm) but in some cases I think it's justified and it brings extra value.

IgorPartola 2y ago

After reading endless insufferable comments on HN a la “this should have been written in Rust” I realized that there is a very strong possibility that the people making those comments do not know another language. We saw this with JavaScript a decade ago. Before that it was Ruby.

keybored 2y ago

> Rust is great, but - heretic idea - not literally everything needs to be in Rust. Go try Ruby on Rails for a while! Or - if Rust has whetted your appetite for more functional styles - Phoenix on Elixir! Yes, it's not quite so blazing fast, but - let's be honest here - you're not going to be getting billions of requests per second on your hobby website where you write about taking apart Amigas. It's OK! She'll be right. Who changes their minds about what to do for fun because someone on HN thought it was unnecessary? Doing what some random person wants instead because they want to be “heretical” (because it’s a religion right) sounds like the opposite of fun to me. But I’ll see you on the next thread about making a Rube Goldberg web server in C++ templates. Or some such very necessary and “approved for prod by HN” thing.