17 ms·

I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety

by agentgt 10y ago

I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and balanced community approach to creating PL. Everything seems to be carefully thought out and iterated on. There is a lot to be said to this (although ironically I suppose one could call that safe)! PL is more than the language. It is works, community and mindshare. If Rust was so concerned with safety I don't think much work would be done on making it so consumable for all with continuous improvements of compiler error messages, easier syntax and improved documentation. Rust is one of the first languages in a long time that makes you think different. If it is just safety... safety is one overloaded word.

svckr 10y ago
I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.
- jfaucett 10y ago
  IMO the biggest plus for rust is actually cargo. Building, versioning, and sharing modular code is essentially copy/paste in C/C++, and compared to that cargo is lightyears ahead. I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.
  - cmyr 10y ago
    I couldn't agree more with this. Cargo (and the general desire to think and work hard on ease-of-use) is a huge part of what makes Rust a pleasure. It alone would be enough for me to steer someone with experience in neither to Rust over C++ for lots and lots of use cases.
    - hedora 10y ago
      I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and creating a massive new problem (there is a whole thread below this one talking about rust dll hell between nightly and stable, and the thread links to other HN articles!). From my perspective all this work is wasted just because some developers somewhere use an OS that doesn't support apt or ports. Sorry this is so ranty, but I really want to know if anyone has had luck using rust with their native package manager.
      - white-flame 10y ago
        apt & ports don't follow you into other OSes. Language-specific package managers do, without requiring entanglement with the OS or admin permissions. All you need is sockets and a filesystem. I think the language-specific ones will win for developer-oriented library management for platform-agnostic language environments.
        hedora 10y ago
        Apt and/or ports follow you to every OS kernel I can think of (Linux, MacOS, Windows, *BSD, the Solarises), though the packaging doesn't always (for instance, the OpenBSD guys have a high bar, but that's a feature). My theory is that each language community thinks it will save them time to have one package manager to rule them all instead of just packaging everything up for 4-5 different targets. The bad thing about this is that it transfers the burden of dealing with yet another package manager to the (hopefully) 10's or 100's of thousands of developers that consume the libraries, so now we've wasted developer centuries reading docs and learning the new package manager. Next, the whole platform agnostic thing falls apart the second someone tries to write a GUI or interface with low-level OS APIs (like async I/O), and the package manager ends up growing a bunch of OS-specific warts/bugs so you end up losing on both ends. Finally, most package manager developers don't seem to realize they need to handle dependencies and anti-dependencies (which leads you to NP-Complete land fast), or that they're building mission-critical infrastructure that needs to have bullet proof security. This gets back to that "reinvent dpkg poorly" comment I made above. In my own work I do my best to minimize dependencies. When that doesn't work out, I just pick a target LTS release of an OS, and either use that on bare metal or in a VM. Also, I wait for languages to be baked enough to have reasonable OS-level package manager support. (I'm typing this on a devuan box, so maybe I'm an outlier.)
- rubber_duck 10y ago
  >But Rust can compete on so many more levels How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala). What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this space and GC based languages are just more elegant and not to mention the tooling is way more mature. Runtime also doesn't matter that much and with the recent changes to .NET can be avoided anyway. This Rust fanboyism is turning in to the new node hype "use node for everything node is web scale fast because it uses an event loop io instead of thread based io", "use rust for everything because the type safety is literally the best and it's the only language with a strong type system out there". I get it it's new and shiny, I like it to, and it has a strong argument to make in the systems programming - the designers are doing a good job of making trade offs that let you retain low level control while still having memory safety - but these tradeoffs are just that and they come at the expense of higher level stuff, higher level languages don't need to make these because they don't pretend to be systems programming languages.
  - andrewflnr 10y ago
    Yeah, on any given dimension, even safety, you'll find languages that are stronger than Rust. It excels IMO because of the balance it finds between type system, safety, functional vs imperative code, etc. It puts all these together in one package that I feel like I can use for actual work. I don't know of any other solid contenders here, except maybe Swift. I have to agree that the "Rust all the things!" game is getting old.
  - EugeneOZ 10y ago
    When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and great performance - just all the best.
dom0 10y ago
> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.
- chc 10y ago
  How so? Most big projects have both stable releases and nightly builds that contain unfinished features. Why is it particularly troublesome for Rust?
- nercury 10y ago
  I am not sure it's really a split when you can build stable on nightly. Nightly is great for experimentation.
- pimeys 10y ago
  I don't see a split here. I know lots of cool ideas have been posted to Hacker News lately, that showcase something possible in future versions of Rust. But I seriously hope people keep these libraries as showcases, not production-quality tools. I'd say this nightly/stable split is a bit out of proportion. In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rust. And maybe in the end of the year we can take a proper look what we can do with Rocket, or Diesel...
  - steveklabnik 10y ago
    Tokio runs entirely on stable, though 1.0 won't happen until some language changes land. Diesel does work on stable today, but its nightly features will be on stable in five weeks with 1.15.
    - pimeys 10y ago
      > Tokio runs entirely on stable, though 1.0 won't happen until some language changes land. Are you talking about impl Trait or some other language changes?
kibwen 10y ago
I think this comment and the OP are both correct. The point of Rust is safety, in the sense that memory safety should be the default for all programming languages, and has been the default for all non-systems languages since the 90s. The only holdouts have been because people used to claim that memory safety wasn't possible without making a language unusably slow, which Rust has disproven. In all my years of teaching Rust, I can't count how many times I've told people that you can have a memory-safe systems language without garbage collection and have them look me in the eye and say, "what, no, that's supposed to be impossible", and I still get a kick out of it every time. The importance of Rust is that it's raised the baseline for low-level languages in the modern age. If any future systems languages emerge that don't feature memory safety, it will have to be a deliberate choice that must be defended rather than just an implicit assumption of how the world works.
- jwn 10y ago
  I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours. With that said, can you recommend a good source to really understand best practices and patterns for ownership and borrowing? I feel that's the biggest hurdle to using Rust (at least in my case).
  - bjz_ 10y ago
    Alas, I think a week is too short to give Rust. Go will get you more pay-off in the short term, but as you internalise the rules of Rust you'll really start to reap the benefits. Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.
    - eropple 10y ago
      Agreed. It took me about two months to really understand Rust, and I was coming from a background of languages like C++ and Scala. It pays off, though, for what I want to do with computers. The rise of "it demos well so we should use it" is in a lot of ways troubling. The inflection point for productivity doesn't need to be "five minutes in" to be worthwhile if you're doing something that is, itself, worthwhile.

by agentgt 10y ago

svckr 10y ago

I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.

jfaucett 10y ago
IMO the biggest plus for rust is actually cargo. Building, versioning, and sharing modular code is essentially copy/paste in C/C++, and compared to that cargo is lightyears ahead. I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.
- cmyr 10y ago
  I couldn't agree more with this. Cargo (and the general desire to think and work hard on ease-of-use) is a huge part of what makes Rust a pleasure. It alone would be enough for me to steer someone with experience in neither to Rust over C++ for lots and lots of use cases.
  - hedora 10y ago
    I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and creating a massive new problem (there is a whole thread below this one talking about rust dll hell between nightly and stable, and the thread links to other HN articles!). From my perspective all this work is wasted just because some developers somewhere use an OS that doesn't support apt or ports. Sorry this is so ranty, but I really want to know if anyone has had luck using rust with their native package manager.
    - white-flame 10y ago
      apt & ports don't follow you into other OSes. Language-specific package managers do, without requiring entanglement with the OS or admin permissions. All you need is sockets and a filesystem. I think the language-specific ones will win for developer-oriented library management for platform-agnostic language environments.
      - hedora 10y ago
        Apt and/or ports follow you to every OS kernel I can think of (Linux, MacOS, Windows, *BSD, the Solarises), though the packaging doesn't always (for instance, the OpenBSD guys have a high bar, but that's a feature). My theory is that each language community thinks it will save them time to have one package manager to rule them all instead of just packaging everything up for 4-5 different targets. The bad thing about this is that it transfers the burden of dealing with yet another package manager to the (hopefully) 10's or 100's of thousands of developers that consume the libraries, so now we've wasted developer centuries reading docs and learning the new package manager. Next, the whole platform agnostic thing falls apart the second someone tries to write a GUI or interface with low-level OS APIs (like async I/O), and the package manager ends up growing a bunch of OS-specific warts/bugs so you end up losing on both ends. Finally, most package manager developers don't seem to realize they need to handle dependencies and anti-dependencies (which leads you to NP-Complete land fast), or that they're building mission-critical infrastructure that needs to have bullet proof security. This gets back to that "reinvent dpkg poorly" comment I made above. In my own work I do my best to minimize dependencies. When that doesn't work out, I just pick a target LTS release of an OS, and either use that on bare metal or in a VM. Also, I wait for languages to be baked enough to have reasonable OS-level package manager support. (I'm typing this on a devuan box, so maybe I'm an outlier.)
rubber_duck 10y ago
>But Rust can compete on so many more levels How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala). What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this space and GC based languages are just more elegant and not to mention the tooling is way more mature. Runtime also doesn't matter that much and with the recent changes to .NET can be avoided anyway. This Rust fanboyism is turning in to the new node hype "use node for everything node is web scale fast because it uses an event loop io instead of thread based io", "use rust for everything because the type safety is literally the best and it's the only language with a strong type system out there". I get it it's new and shiny, I like it to, and it has a strong argument to make in the systems programming - the designers are doing a good job of making trade offs that let you retain low level control while still having memory safety - but these tradeoffs are just that and they come at the expense of higher level stuff, higher level languages don't need to make these because they don't pretend to be systems programming languages.
- andrewflnr 10y ago
  Yeah, on any given dimension, even safety, you'll find languages that are stronger than Rust. It excels IMO because of the balance it finds between type system, safety, functional vs imperative code, etc. It puts all these together in one package that I feel like I can use for actual work. I don't know of any other solid contenders here, except maybe Swift. I have to agree that the "Rust all the things!" game is getting old.
- EugeneOZ 10y ago
  When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and great performance - just all the best.

dom0 10y ago

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

chc 10y ago
How so? Most big projects have both stable releases and nightly builds that contain unfinished features. Why is it particularly troublesome for Rust?
nercury 10y ago
I am not sure it's really a split when you can build stable on nightly. Nightly is great for experimentation.
pimeys 10y ago
I don't see a split here. I know lots of cool ideas have been posted to Hacker News lately, that showcase something possible in future versions of Rust. But I seriously hope people keep these libraries as showcases, not production-quality tools. I'd say this nightly/stable split is a bit out of proportion. In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rust. And maybe in the end of the year we can take a proper look what we can do with Rocket, or Diesel...
- steveklabnik 10y ago
  Tokio runs entirely on stable, though 1.0 won't happen until some language changes land. Diesel does work on stable today, but its nightly features will be on stable in five weeks with 1.15.
  - pimeys 10y ago
    > Tokio runs entirely on stable, though 1.0 won't happen until some language changes land. Are you talking about impl Trait or some other language changes?

kibwen 10y ago

I think this comment and the OP are both correct. The point of Rust is safety, in the sense that memory safety should be the default for all programming languages, and has been the default for all non-systems languages since the 90s. The only holdouts have been because people used to claim that memory safety wasn't possible without making a language unusably slow, which Rust has disproven. In all my years of teaching Rust, I can't count how many times I've told people that you can have a memory-safe systems language without garbage collection and have them look me in the eye and say, "what, no, that's supposed to be impossible", and I still get a kick out of it every time. The importance of Rust is that it's raised the baseline for low-level languages in the modern age. If any future systems languages emerge that don't feature memory safety, it will have to be a deliberate choice that must be defended rather than just an implicit assumption of how the world works.

jwn 10y ago
I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours. With that said, can you recommend a good source to really understand best practices and patterns for ownership and borrowing? I feel that's the biggest hurdle to using Rust (at least in my case).
- bjz_ 10y ago
  Alas, I think a week is too short to give Rust. Go will get you more pay-off in the short term, but as you internalise the rules of Rust you'll really start to reap the benefits. Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.
  - eropple 10y ago
    Agreed. It took me about two months to really understand Rust, and I was coming from a background of languages like C++ and Scala. It pays off, though, for what I want to do with computers. The rise of "it demos well so we should use it" is in a lot of ways troubling. The inflection point for productivity doesn't need to be "five minutes in" to be worthwhile if you're doing something that is, itself, worthwhile.