3 ms·

Indeed! I don't believe that there are tools with a lower learning curve that solve the same problem Rust does - in particular my belief is the way that Rust is

Indeed! I don't believe that there are tools with a lower learning curve that solve the same problem Rust does - in particular my belief is the way that Rust is able to perform deep type analysis on imperative code (which is really what the dreaded borrow checker is all about) enables proficient users to write well-factored systems with a high degree of confidence in their correctness. If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. In my experience projects for which that is a high priority (and the languages which enable them) also deal with a great amount of technical debt.

problems 10y ago
You can definitely use languages that are just as safe, but higher level. You could make that argument with many functional languages like Scala or Clojure, you could even make an argument that even many imperative languages are also that solid - like C# or Java. Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. If you want something more precise - you can use Scala in a way that it's almost an imperative language with additional safety guarantees. The only gain you get going to Rust is really in the performance department. Rust is what you use if you want C-level performance combined with that safety, it might replace C and C++ as the OS, browser, high performance server and game development language. For anything else I find it hard to suggest Rust as a serious option when there are many high level languages that seem like better answers.
- jmcomets 10y ago
  > Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversion between related types.
  - problems 10y ago
    Many applications don't even need to deal with concurrent access though. Or can deal with them in very abstracted way. Sure, in those cases where you're dealing with a lot of concurrency and especially with concurrent access to things, Rust may be a good suggestion, but then you probably fall into the "high performance applications" category I was mentioning. But again, it's not a generally good solution for CRUD-y business applications, webapps, mobile apps, etc where this sort of work is generally rare if it's present at all. I definitely don't think it makes Rust seem like an appealing option. Between the limited community library selection, the verbose syntax and the borrow checker's extreme complexity to new users, I wouldn't suggest Rust to say, someone working on a web application currently because they will gain few if any advantages, but suffer many risks.
    - jmcomets 10y ago
      > I definitely don't think it makes Rust seem like an appealing option. Between the limited community library selection, the verbose syntax and the borrow checker's extreme complexity to new users, I wouldn't suggest Rust to say, someone working on a web application currently because they will gain few if any advantages, but suffer many risks. You're right that it isn't appealing to those who're looking for fast results and don't worry about maintaining a large codebase for years. For those like me, many of the features Rust provides solve issues we face on a day-to-day basis. Yes the borrow checker is a pain for a while. Yes the libraries are still immature. Syntax is much more verbose than say Ruby or Python. But IMO the benefits you reap from strong typing and borrow checking outweigh the steep learning curve. It's not just about memory management, it's also about controlling mutation (because mutation is a hard problem).
      - problems 10y ago
        I hear you, but most of those benefits are reaped from not just strong, but more importantly static typing alone, which you could gain from simply using C# or Java without the need to commit to the complexity of borrow checking, which only really buys you safety in a few additional cases, but arguably costs you big in development effort, much more so than static typing.
- galangalalgol 10y ago
  I don't see anyone proficient at Scala or clojure having troubles with the borrow checker. Even rust syntax is similar to scala, kind of. The issue is telling people that rust is a multi paradigm language when the borrow checker wants it to be functional for the most part. Java and c# are not safe from data races. I think that is an important shortfall. And learning your first functional language takes time with or without GC.
- tatterdemalion 10y ago
  It may surprise you to learn that I was already aware of all of the languages you mentioned, and yet I still asserted that Rust gave you more than just performance. I specifically asserted that Rust is capable of typing imperative code in a way that no other language is. ML-descended languages hide their imperative components behind Cells and Monads. Imperative languages have type systems which don't capture questions of ownership, aliasing, and shared mutability. I found your comment to be not at all enlightening; all you've done is list other languages with type systems and then assert that I am wrong, suggesting you read my comment with a closed mind - in which case, why comment?
  - problems 10y ago
    I just don't see what Rust's type system buys you over the others, despite the extraordinary effort it forces you to exert - so I'm quite concerned about seeing it suggested in serious applications outside of the niches in which it's truly beneficial - memory safety without the performance impact being that main niche. While there are other needs it can arguably meet, I don't feel it's worth using in most of those cases. Maybe this is a misunderstanding on my part, but I found it of little concrete benefit for a lot of extra work. Perhaps my initial experiences with Rust have colored my thinking on it though.
    - tatterdemalion 10y ago
      Maybe, recognizing that your vantage point is not absolute & people who disagree are not just miscreants leading the flock astray, you shouldn't be "quite concerned" that other people had a different experience using a tool than you & express that.
solatic 10y ago
> If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. But this is more or less why Rust isn't popular for LOB apps yet. If a business has a long-term, critical project, it needs to have relative certainty of its ability to hire programmers to work on that project, at least in case some of their current programmers leave the company, let alone wanting to hire more developers. Right now there aren't many Rust developers, and training new Rust developers past the steep learning curve is hard. So employers, even if they recognize the value of Rust as a language for a potential project, have a hard time getting off the ground. The good news is that the Rust 2017 Roadmap understands that this is one of the primary inhibitors of adoption and that the team is committed to making progress on this front. But it's why the language just isn't there yet.

problems 10y ago

You can definitely use languages that are just as safe, but higher level. You could make that argument with many functional languages like Scala or Clojure, you could even make an argument that even many imperative languages are also that solid - like C# or Java. Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. If you want something more precise - you can use Scala in a way that it's almost an imperative language with additional safety guarantees. The only gain you get going to Rust is really in the performance department. Rust is what you use if you want C-level performance combined with that safety, it might replace C and C++ as the OS, browser, high performance server and game development language. For anything else I find it hard to suggest Rust as a serious option when there are many high level languages that seem like better answers.

jmcomets 10y ago
> Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversion between related types.
- problems 10y ago
  Many applications don't even need to deal with concurrent access though. Or can deal with them in very abstracted way. Sure, in those cases where you're dealing with a lot of concurrency and especially with concurrent access to things, Rust may be a good suggestion, but then you probably fall into the "high performance applications" category I was mentioning. But again, it's not a generally good solution for CRUD-y business applications, webapps, mobile apps, etc where this sort of work is generally rare if it's present at all. I definitely don't think it makes Rust seem like an appealing option. Between the limited community library selection, the verbose syntax and the borrow checker's extreme complexity to new users, I wouldn't suggest Rust to say, someone working on a web application currently because they will gain few if any advantages, but suffer many risks.
  - jmcomets 10y ago
    > I definitely don't think it makes Rust seem like an appealing option. Between the limited community library selection, the verbose syntax and the borrow checker's extreme complexity to new users, I wouldn't suggest Rust to say, someone working on a web application currently because they will gain few if any advantages, but suffer many risks. You're right that it isn't appealing to those who're looking for fast results and don't worry about maintaining a large codebase for years. For those like me, many of the features Rust provides solve issues we face on a day-to-day basis. Yes the borrow checker is a pain for a while. Yes the libraries are still immature. Syntax is much more verbose than say Ruby or Python. But IMO the benefits you reap from strong typing and borrow checking outweigh the steep learning curve. It's not just about memory management, it's also about controlling mutation (because mutation is a hard problem).
    - problems 10y ago
      I hear you, but most of those benefits are reaped from not just strong, but more importantly static typing alone, which you could gain from simply using C# or Java without the need to commit to the complexity of borrow checking, which only really buys you safety in a few additional cases, but arguably costs you big in development effort, much more so than static typing.
galangalalgol 10y ago
I don't see anyone proficient at Scala or clojure having troubles with the borrow checker. Even rust syntax is similar to scala, kind of. The issue is telling people that rust is a multi paradigm language when the borrow checker wants it to be functional for the most part. Java and c# are not safe from data races. I think that is an important shortfall. And learning your first functional language takes time with or without GC.
tatterdemalion 10y ago
It may surprise you to learn that I was already aware of all of the languages you mentioned, and yet I still asserted that Rust gave you more than just performance. I specifically asserted that Rust is capable of typing imperative code in a way that no other language is. ML-descended languages hide their imperative components behind Cells and Monads. Imperative languages have type systems which don't capture questions of ownership, aliasing, and shared mutability. I found your comment to be not at all enlightening; all you've done is list other languages with type systems and then assert that I am wrong, suggesting you read my comment with a closed mind - in which case, why comment?
- problems 10y ago
  I just don't see what Rust's type system buys you over the others, despite the extraordinary effort it forces you to exert - so I'm quite concerned about seeing it suggested in serious applications outside of the niches in which it's truly beneficial - memory safety without the performance impact being that main niche. While there are other needs it can arguably meet, I don't feel it's worth using in most of those cases. Maybe this is a misunderstanding on my part, but I found it of little concrete benefit for a lot of extra work. Perhaps my initial experiences with Rust have colored my thinking on it though.
  - tatterdemalion 10y ago
    Maybe, recognizing that your vantage point is not absolute & people who disagree are not just miscreants leading the flock astray, you shouldn't be "quite concerned" that other people had a different experience using a tool than you & express that.

solatic 10y ago

> If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. But this is more or less why Rust isn't popular for LOB apps yet. If a business has a long-term, critical project, it needs to have relative certainty of its ability to hire programmers to work on that project, at least in case some of their current programmers leave the company, let alone wanting to hire more developers. Right now there aren't many Rust developers, and training new Rust developers past the steep learning curve is hard. So employers, even if they recognize the value of Rust as a language for a potential project, have a hard time getting off the ground. The good news is that the Rust 2017 Roadmap understands that this is one of the primary inhibitors of adoption and that the team is committed to making progress on this front. But it's why the language just isn't there yet.