13 ms·

2016 Rust Commercial User Survey Results

111 points by cpeterso 10y ago

the_duke 10y ago
Great to see Rust gaining a foothold in commercial areas. While by no means a perfect language, I enjoy it much more than writing C++.
- sdegutis 10y ago
  Why do you specifically enjoy it more than C++? As far as I know, the main goal of Rust is to be safer than C++, not more enjoyable to write.
  - livingparadox 10y ago
    Having confidence and trust in your code, and having less surprise runtime bugs in your code would naturally lead to a more enjoyable coding experience, I'd imagine.
  - pcwalton 10y ago
    It was designed to be nicer than C++ to write too. Why would we have gone through the trouble to add (for example) pattern matching if it wasn't?
    - vvanders 10y ago
      Totally. Pattern matching and blocks as expressions are something I reach for constantly in C++ & Java and always end up disappointed when I remember they aren't there.
  - outworlder 10y ago
    Wasn't it? I can contrast the respective compiler error messages to point out that, whether it was designed as such or not, writing Rust IS more enjoyable.
  - jamesmunns 10y ago
    For me (also ~1000 lines of rust in production), the tooling and packaging was a huge winner. Having docs (with a doc generator), a test framework, a package manager, and a helpful [cross] compiler all put together, along with blazing speed and amazing reliability at runtime is an amazing combo.
  - quantumhobbit 10y ago
    Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. Also rust has some more modern functionalish constructs like lambadas and pattern matching.
    - duneroadrunner 10y ago
      > Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. For those times when you have to use C++, SaferCPlusPlus[1] should help. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
      - pjmlp 10y ago
        How does it help to make everyone on the team play ball to not use C style coding or the quality of third party libraries? If the answer is code review, it will never work.
        duneroadrunner 10y ago
        I can certainly appreciate the sentiment that one of the most valuable features a language can have is the ability to make your co-workers write better code :) And it's hard to compete with Rust in that sense. That is, if you're starting a brand new project. But in other circumstances, another valuable feature would be to be able to make your co-workers' (and predecessors') existing code retroactively safer. The easiest way to do that is probably by enabling the llvm/gcc sanitizers when compiling. But unfortunately that is often not a practical solution for several reasons[1], not least of which is the performance penalty. So the more practical solution may be to use SaferCPlusPlus to replace (in a straight-forward but not quite automated manner) all the potentially dangerous C/C++ data types (pointers, arrays, etc.) with safe, fast compatible direct substitutes. Thereby salvaging existing code bases. Wrt preventing the use of C/C++'s unsafe data types in new code, currently SaferCPlusPlus does not provide any mechanism for such enforcement. But you could imagine the effort required to implement such an enforcement mechanism might be small compared to rewriting some large code bases in, say, Rust. And in the mean time, even existing C++ static analyzers seem to be getting better at flagging potentially unsafe code. [1] http://duneroadrunner.github.io/SaferCPlusPlus/#safercplusplus-versus-clangllvm-sanitizers http://duneroadrunner.github.io/SaferCPlusPlus/#safercpluspl...
  - sidlls 10y ago
    Long time C++ programmer here. I specifically like the immutable-by-default, borrow, and move semantics. I can write safe code without bloating up my source with 'const &', std::move, '&& ...' and the like. The safety issue for me is about the least important thing. Touting it as the big reason to use Rust is a distraction from my point of view.
    - santaclaus 10y ago
      > The safety issue for me is about the least important thing. For real. Rust is a great language, but for the love of god, all you hear is safety safety safety. I give about 2 out of 10 fs about safety. The worst part of C++? Dependency management. Cargo is sick -- hype that up more!
      - pjmlp 10y ago
        > The worst part of C++? The worst part is people using it as if it was C with a C++ compiler. I lost count the amount of times I had to create a nice C++ wrapper for "C++" libraries that are just a pile of C functions and data structures, due to copy-paste compatibility. And yes, the respective lack of safety by not making use of C++ improved type system and standard library.
    - deleted 10y ago
      [deleted]
  - shadowmint 10y ago
    It is though. I don't know about 'main goal' but rust is fun to write. Far more than c++ for me. Compile times. Traits. Generics that aren't templates. A package manager. Functional constructs. Cross platform. It's got all the shiny toys. The state of the art in C++ is what? One file drop in headers, no package management and STL hell? Have you read the UE4 engine code base? What are horrific mess. There are certainly problems with rust (imo tooling and libraries), but I don't think for a moment how enjoyable to write it is, is one of them... C++ is a bloated language and I hate writing code in it. I hate that the mix of C++14/11/?? You get is different is every project. I despise that my C++ code from QT, UE, win32 is virtually incompatible, and the header/code legacy divide (or not if you happen to be in a system that allows it). I guess your milage may vary, but I've not talked to many people who didn't like programming in rust... Mostly just people who found it hard, or didn't know why they would bother vs. their current 'good enough' language (eg. C#).
    - pjmlp 10y ago
      Game developers, specially AAA studios, are well known for writing messy code, regardless of the language. I bet you if UE5 would get rewritten in Rust, it would just look as messy.
    - dman 10y ago
      People havent had enough time to write huge messy codebases in Rust. Irrespective of language, I suspect that people hate reading source code and would much prefer to write code rather than read code. Ten years from now, I am hoping that Rust becomes the defacto systems language, but I strongly suspect that people will have similarly bad things to say about large Rust codebases then as they do about C++ codebases now.
  - burntsushi 10y ago
    I find Rust to be more enjoyable to write in than any other programming language I've used. The reasons why aren't that interesting, because they're the same reasons everyone else has: algebraic data types, safety, control and tooling. (I just finished implementing a parallel recursive directory iterator that respects gitignore files. No unsafe. No data races. No mutexes. Blazing fast. So I'm particularly over the moon at the moment. :P)
squiguy7 10y ago
What I would be interested in is how these companies use Rust in their stack and what kind of problems they can solve. I suppose not every company can divulge this information but it would be awesome to know where Rust fits in for them.
- muizelaar 10y ago
  https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html has a single sentence version of this kind of thing.
  - kibwen 10y ago
    Lots of those sentences also link to posts with more extensive experience reports.
kinofcain 10y ago
Can't argue with anything in that list. I think it would also be useful to survey people who looked into using Rust but decided against using it, as responses from people who suffered through the warts is analogous to looking at the damage to bombers that made it back to base. Still relevant, but not the whole picture. I'd expect to see mobile/cross-compilation (which I know is getting better) to rank pretty high among people who didn't stick with it, but maybe I'm projecting.
- jntrnr 10y ago
  There's some coverage of the "why I chose not to use Rust" in the Rust community survey that happened earlier this year: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2...
Animats 10y ago
From the article: "...fourteen companies responded to our outreach" That's not a survey, that's a focus group. I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection. But there's a lot about Rust that's unnecessarily weird. - The type system is unusual, and complex. It's hard to do anything without templates. - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain. - The hacks needed to avoid the need for exceptions are uglier than exceptions. This creates major obstacles to adoption. Unlike the borrow checker, none of these things are clearly improvements. They're just different. I would have gone for Python-type exceptions rather than error enums and macros, single-inheritance OOP rather than traits, and Python-type with clauses rather than RAII.
- dbaupp 10y ago
  > - The type system is unusual, and complex. It's hard to do anything without templates. Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than <>'s in a few places. For one, not having generics would make it far more annoying to create reusable zero-cost abstractions around `unsafe` code, resulting in your other favourite criticism: more unsafe code for "unnecessary" (i.e. performance) reasons. > - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain. This isn't true: most generic types go via other schemes, and only use closures for simple combinators (making one line manipulations simpler and easier to read, but like with anything, can be abused), or when they're required to achieve the desired semantics (iterator pipelines). --- In any case, (some of) your proposed replacements don't make sense as the only built-in for their given functionality, for a systems language. If the task in question can take the loss of control, then Python (or similar) seems like a better choice for you. > would have gone for Python-type exceptions rather than error enums and macros, True Python-style exceptions require allocations to handle errors. > single-inheritance OOP rather than traits This forces dynamic dispatch everywhere and loses type safety (when passing types through functions and storing them in data structures), rather than being able to specialise functions and data types, and track exact types through code. Also, only offering single-inheritance has significant semantic problems, e.g. what happens when your type is both equatable and cloneable? > Python-type with clauses rather than RAII What exactly does this address? It seems just like a syntactic rephrasing of `let x = foo()`, given it would have to be compulsory for certain types, or else guarantees are lost. --- Rust is, as you say, different to other languages, but very little of it (and none of the features you call out) was chosen just to be gratuitously different. The new features of course might just take a little time to get used to if one is coming from mainstream imperative/OOP languages.
dreta 10y ago
I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Rust doesn’t even have support for modern features like wide registers, or any features that help you deal with raw memory, it just marks it as “unsafe”. There aren’t even any basic meta programming features like struct introspection. What problems does Rust actually solve that C and its copycats have been suffering from since the 70s.
- pcwalton 10y ago
  > I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted). > For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Well, this definition of a systems programming language excludes C. > Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ http://huonw.github.io/blog/2016/04/myths-and-legends-about-... > Rust doesn’t even have support for modern features like wide registers What is a "wide register"? Do you mean SIMD? If so, it sure does [1]. > or any features that help you deal with raw memory, it just marks it as “unsafe”. Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't. > There aren’t even any basic meta programming features like struct introspection. That's what custom derive is for. [1]: https://huonw.github.io/simd/simd/ https://huonw.github.io/simd/simd/
bfrog 10y ago
I'm using it commercially, though wasn't asked in the survey. I've had zero crash causing failures in production with a web interfaced analytics pipeline service I wrote. It just sits there, with its 10's of gigabytes of data running day in day out... handling millions of events every day, crunching business vital numbers. Best thing ever.
- Manishearth 10y ago
  Are you listed on http://rust-lang.org/friends.html http://rust-lang.org/friends.html ? If not, might want to let us know using the link at the bottom of the page :) If you are; sorry you weren't included in the survey. I don't think everyone on the friends page was included, it was more of "everyone we know who uses Rust and we have an easy way of contacting over email"
  - bfrog 10y ago
    Will try and get that stuff together, gotta ask my graphics guy for a nice SVG logo
- olauzon 10y ago
  Similar story here. Been using Rust in production for only a couple of weeks for a financial analytics pipeline processing billions of events per day and TBs of data, but absolutely no issues so far. The predictable performance of Rust has been wonderful to observe, compared to GC'ed languages this iteration of the pipeline has replaced (JVM, Go). The type system makes otherwise daring refactorings a joy.
  - Manishearth 10y ago
    -> https://news.ycombinator.com/item?id=12877334 https://news.ycombinator.com/item?id=12877334 :)
    - olauzon 10y ago
      Will ask employer for approval :)
gravypod 10y ago
> We received a resounding response to continue investing in building strong IDE tools. IDE tools in a commercial setting help teams coordinate their efforts by making it easier to navigate unfamiliar code, on-board new users, and streamline the development process. I cannot wait. I cannot wait until this happens. Rust will become my main language.
- alfalfasprout 10y ago
  This is one of the key things preventing us from moving to Rust. Yeah, I love vim but on a very large codebase an IDE just helps you keep everything much more organized and productive. Moreover, moving to Rust would require investing in ports of some large-ish C++ libraries we use. I think Rust is here to stay. It's a great language without a runtime that should be able to match C++ in performance when the compiler frontends catch up. We'll start using it in some new projects but I doubt we'll port critical infrastructure for a few years.
  - steveklabnik 10y ago
    Which IDEs matter to you? We're actively working on it.
    - gravypod 10y ago
      Eclipse for Java and PyCharm for Python Eclipse has by far the best autocompletion for Java. PyCharm has the best debugger I've ever used or could dream of.
      - steveklabnik 10y ago
        Cool, thanks. I linked to an eclipse plugin in a sibling. I'll check out PyCharm's debugger, I've never used it.
    - mindcrime 10y ago
      Not the poster you were replying to, but Eclipse here. I'd definitely want a great Rust plugin for Eclipse if I were going to invest heavily in Rust.
cm3 10y ago
This wasn't one of the question of the survey, but while having the right crowd around, I have to ask. When will Rust get 1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 2. support for naturally writing recursive functions
- steveklabnik 10y ago
  Can you elaborate on what #2 means to you?
  - cm3 10y ago
    We are discouraged from writing recursive functions, which comes naturally when expressing many algorithms. Missing TCO is one cited reason to avoid it, so I gather we're not supposed to, generally speaking.
    - saghm 10y ago
      I don't think it's discouraged (a least, not in the sense of it being considered bad); I think they're just being explicit about what guarantees you have (or rather, don't have) for recursive functions
    - kibwen 10y ago
      Support for guaranteeing TCE is possible and has been proposed, but there remain a few open questions, e.g. what to do about local variables with destructors (personally I'd statically forbid them from being in scope at the end of tail-call recursive functions).
      - cm3 10y ago
        I know, that's why I wrote "when", knowing it's been considered, but it doesn't appear to be missed by enough developers. I'm just spoiled having used those two features, and anytime someone cites the ML family as part of Rust's influence, it reminds me of these two basic, missing features. Regarding semantics, without having thought about the Rust semantics too much, I'd suggest to check out the most prominent uses for recursive functions in OCaml, SML or Haskell, then try to consider that as the sweet spot to support in Rust.

111 points by cpeterso 10y ago

Great to see Rust gaining a foothold in commercial areas. While by no means a perfect language, I enjoy it much more than writing C++.

sdegutis 10y ago
Why do you specifically enjoy it more than C++? As far as I know, the main goal of Rust is to be safer than C++, not more enjoyable to write.
- livingparadox 10y ago
  Having confidence and trust in your code, and having less surprise runtime bugs in your code would naturally lead to a more enjoyable coding experience, I'd imagine.
- pcwalton 10y ago
  It was designed to be nicer than C++ to write too. Why would we have gone through the trouble to add (for example) pattern matching if it wasn't?
  - vvanders 10y ago
    Totally. Pattern matching and blocks as expressions are something I reach for constantly in C++ & Java and always end up disappointed when I remember they aren't there.
- outworlder 10y ago
  Wasn't it? I can contrast the respective compiler error messages to point out that, whether it was designed as such or not, writing Rust IS more enjoyable.
- jamesmunns 10y ago
  For me (also ~1000 lines of rust in production), the tooling and packaging was a huge winner. Having docs (with a doc generator), a test framework, a package manager, and a helpful [cross] compiler all put together, along with blazing speed and amazing reliability at runtime is an amazing combo.
- quantumhobbit 10y ago
  Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. Also rust has some more modern functionalish constructs like lambadas and pattern matching.
  - duneroadrunner 10y ago
    > Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. For those times when you have to use C++, SaferCPlusPlus[1] should help. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
    - pjmlp 10y ago
      How does it help to make everyone on the team play ball to not use C style coding or the quality of third party libraries? If the answer is code review, it will never work.
      - duneroadrunner 10y ago
        I can certainly appreciate the sentiment that one of the most valuable features a language can have is the ability to make your co-workers write better code :) And it's hard to compete with Rust in that sense. That is, if you're starting a brand new project. But in other circumstances, another valuable feature would be to be able to make your co-workers' (and predecessors') existing code retroactively safer. The easiest way to do that is probably by enabling the llvm/gcc sanitizers when compiling. But unfortunately that is often not a practical solution for several reasons[1], not least of which is the performance penalty. So the more practical solution may be to use SaferCPlusPlus to replace (in a straight-forward but not quite automated manner) all the potentially dangerous C/C++ data types (pointers, arrays, etc.) with safe, fast compatible direct substitutes. Thereby salvaging existing code bases. Wrt preventing the use of C/C++'s unsafe data types in new code, currently SaferCPlusPlus does not provide any mechanism for such enforcement. But you could imagine the effort required to implement such an enforcement mechanism might be small compared to rewriting some large code bases in, say, Rust. And in the mean time, even existing C++ static analyzers seem to be getting better at flagging potentially unsafe code. [1] http://duneroadrunner.github.io/SaferCPlusPlus/#safercplusplus-versus-clangllvm-sanitizers http://duneroadrunner.github.io/SaferCPlusPlus/#safercpluspl...
- sidlls 10y ago
  Long time C++ programmer here. I specifically like the immutable-by-default, borrow, and move semantics. I can write safe code without bloating up my source with 'const &', std::move, '&& ...' and the like. The safety issue for me is about the least important thing. Touting it as the big reason to use Rust is a distraction from my point of view.
  - santaclaus 10y ago
    > The safety issue for me is about the least important thing. For real. Rust is a great language, but for the love of god, all you hear is safety safety safety. I give about 2 out of 10 fs about safety. The worst part of C++? Dependency management. Cargo is sick -- hype that up more!
    - pjmlp 10y ago
      > The worst part of C++? The worst part is people using it as if it was C with a C++ compiler. I lost count the amount of times I had to create a nice C++ wrapper for "C++" libraries that are just a pile of C functions and data structures, due to copy-paste compatibility. And yes, the respective lack of safety by not making use of C++ improved type system and standard library.
  - deleted 10y ago
    [deleted]
- shadowmint 10y ago
  It is though. I don't know about 'main goal' but rust is fun to write. Far more than c++ for me. Compile times. Traits. Generics that aren't templates. A package manager. Functional constructs. Cross platform. It's got all the shiny toys. The state of the art in C++ is what? One file drop in headers, no package management and STL hell? Have you read the UE4 engine code base? What are horrific mess. There are certainly problems with rust (imo tooling and libraries), but I don't think for a moment how enjoyable to write it is, is one of them... C++ is a bloated language and I hate writing code in it. I hate that the mix of C++14/11/?? You get is different is every project. I despise that my C++ code from QT, UE, win32 is virtually incompatible, and the header/code legacy divide (or not if you happen to be in a system that allows it). I guess your milage may vary, but I've not talked to many people who didn't like programming in rust... Mostly just people who found it hard, or didn't know why they would bother vs. their current 'good enough' language (eg. C#).
  - pjmlp 10y ago
    Game developers, specially AAA studios, are well known for writing messy code, regardless of the language. I bet you if UE5 would get rewritten in Rust, it would just look as messy.
  - dman 10y ago
    People havent had enough time to write huge messy codebases in Rust. Irrespective of language, I suspect that people hate reading source code and would much prefer to write code rather than read code. Ten years from now, I am hoping that Rust becomes the defacto systems language, but I strongly suspect that people will have similarly bad things to say about large Rust codebases then as they do about C++ codebases now.
- burntsushi 10y ago
  I find Rust to be more enjoyable to write in than any other programming language I've used. The reasons why aren't that interesting, because they're the same reasons everyone else has: algebraic data types, safety, control and tooling. (I just finished implementing a parallel recursive directory iterator that respects gitignore files. No unsafe. No data races. No mutexes. Blazing fast. So I'm particularly over the moon at the moment. :P)

squiguy7 10y ago

What I would be interested in is how these companies use Rust in their stack and what kind of problems they can solve. I suppose not every company can divulge this information but it would be awesome to know where Rust fits in for them.

muizelaar 10y ago
https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html has a single sentence version of this kind of thing.
- kibwen 10y ago
  Lots of those sentences also link to posts with more extensive experience reports.

kinofcain 10y ago

Can't argue with anything in that list. I think it would also be useful to survey people who looked into using Rust but decided against using it, as responses from people who suffered through the warts is analogous to looking at the damage to bombers that made it back to base. Still relevant, but not the whole picture. I'd expect to see mobile/cross-compilation (which I know is getting better) to rank pretty high among people who didn't stick with it, but maybe I'm projecting.

jntrnr 10y ago
There's some coverage of the "why I chose not to use Rust" in the Rust community survey that happened earlier this year: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2...

Animats 10y ago

From the article: "...fourteen companies responded to our outreach" That's not a survey, that's a focus group. I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection. But there's a lot about Rust that's unnecessarily weird. - The type system is unusual, and complex. It's hard to do anything without templates. - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain. - The hacks needed to avoid the need for exceptions are uglier than exceptions. This creates major obstacles to adoption. Unlike the borrow checker, none of these things are clearly improvements. They're just different. I would have gone for Python-type exceptions rather than error enums and macros, single-inheritance OOP rather than traits, and Python-type with clauses rather than RAII.

dbaupp 10y ago
> - The type system is unusual, and complex. It's hard to do anything without templates. Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than <>'s in a few places. For one, not having generics would make it far more annoying to create reusable zero-cost abstractions around `unsafe` code, resulting in your other favourite criticism: more unsafe code for "unnecessary" (i.e. performance) reasons. > - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain. This isn't true: most generic types go via other schemes, and only use closures for simple combinators (making one line manipulations simpler and easier to read, but like with anything, can be abused), or when they're required to achieve the desired semantics (iterator pipelines). --- In any case, (some of) your proposed replacements don't make sense as the only built-in for their given functionality, for a systems language. If the task in question can take the loss of control, then Python (or similar) seems like a better choice for you. > would have gone for Python-type exceptions rather than error enums and macros, True Python-style exceptions require allocations to handle errors. > single-inheritance OOP rather than traits This forces dynamic dispatch everywhere and loses type safety (when passing types through functions and storing them in data structures), rather than being able to specialise functions and data types, and track exact types through code. Also, only offering single-inheritance has significant semantic problems, e.g. what happens when your type is both equatable and cloneable? > Python-type with clauses rather than RAII What exactly does this address? It seems just like a syntactic rephrasing of `let x = foo()`, given it would have to be compulsory for certain types, or else guarantees are lost. --- Rust is, as you say, different to other languages, but very little of it (and none of the features you call out) was chosen just to be gratuitously different. The new features of course might just take a little time to get used to if one is coming from mainstream imperative/OOP languages.

dreta 10y ago

I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Rust doesn’t even have support for modern features like wide registers, or any features that help you deal with raw memory, it just marks it as “unsafe”. There aren’t even any basic meta programming features like struct introspection. What problems does Rust actually solve that C and its copycats have been suffering from since the 70s.

pcwalton 10y ago
> I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted). > For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps. Well, this definition of a systems programming language excludes C. > Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs. Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ http://huonw.github.io/blog/2016/04/myths-and-legends-about-... > Rust doesn’t even have support for modern features like wide registers What is a "wide register"? Do you mean SIMD? If so, it sure does [1]. > or any features that help you deal with raw memory, it just marks it as “unsafe”. Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't. > There aren’t even any basic meta programming features like struct introspection. That's what custom derive is for. [1]: https://huonw.github.io/simd/simd/ https://huonw.github.io/simd/simd/

bfrog 10y ago

I'm using it commercially, though wasn't asked in the survey. I've had zero crash causing failures in production with a web interfaced analytics pipeline service I wrote. It just sits there, with its 10's of gigabytes of data running day in day out... handling millions of events every day, crunching business vital numbers. Best thing ever.

Manishearth 10y ago
Are you listed on http://rust-lang.org/friends.html http://rust-lang.org/friends.html ? If not, might want to let us know using the link at the bottom of the page :) If you are; sorry you weren't included in the survey. I don't think everyone on the friends page was included, it was more of "everyone we know who uses Rust and we have an easy way of contacting over email"
- bfrog 10y ago
  Will try and get that stuff together, gotta ask my graphics guy for a nice SVG logo
olauzon 10y ago
Similar story here. Been using Rust in production for only a couple of weeks for a financial analytics pipeline processing billions of events per day and TBs of data, but absolutely no issues so far. The predictable performance of Rust has been wonderful to observe, compared to GC'ed languages this iteration of the pipeline has replaced (JVM, Go). The type system makes otherwise daring refactorings a joy.
- Manishearth 10y ago
  -> https://news.ycombinator.com/item?id=12877334 https://news.ycombinator.com/item?id=12877334 :)
  - olauzon 10y ago
    Will ask employer for approval :)

gravypod 10y ago

> We received a resounding response to continue investing in building strong IDE tools. IDE tools in a commercial setting help teams coordinate their efforts by making it easier to navigate unfamiliar code, on-board new users, and streamline the development process. I cannot wait. I cannot wait until this happens. Rust will become my main language.

alfalfasprout 10y ago
This is one of the key things preventing us from moving to Rust. Yeah, I love vim but on a very large codebase an IDE just helps you keep everything much more organized and productive. Moreover, moving to Rust would require investing in ports of some large-ish C++ libraries we use. I think Rust is here to stay. It's a great language without a runtime that should be able to match C++ in performance when the compiler frontends catch up. We'll start using it in some new projects but I doubt we'll port critical infrastructure for a few years.
- steveklabnik 10y ago
  Which IDEs matter to you? We're actively working on it.
  - gravypod 10y ago
    Eclipse for Java and PyCharm for Python Eclipse has by far the best autocompletion for Java. PyCharm has the best debugger I've ever used or could dream of.
    - steveklabnik 10y ago
      Cool, thanks. I linked to an eclipse plugin in a sibling. I'll check out PyCharm's debugger, I've never used it.
  - mindcrime 10y ago
    Not the poster you were replying to, but Eclipse here. I'd definitely want a great Rust plugin for Eclipse if I were going to invest heavily in Rust.

cm3 10y ago

This wasn't one of the question of the survey, but while having the right crowd around, I have to ask. When will Rust get 1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 2. support for naturally writing recursive functions

steveklabnik 10y ago
Can you elaborate on what #2 means to you?
- cm3 10y ago
  We are discouraged from writing recursive functions, which comes naturally when expressing many algorithms. Missing TCO is one cited reason to avoid it, so I gather we're not supposed to, generally speaking.
  - saghm 10y ago
    I don't think it's discouraged (a least, not in the sense of it being considered bad); I think they're just being explicit about what guarantees you have (or rather, don't have) for recursive functions
  - kibwen 10y ago
    Support for guaranteeing TCE is possible and has been proposed, but there remain a few open questions, e.g. what to do about local variables with destructors (personally I'd statically forbid them from being in scope at the end of tail-call recursive functions).
    - cm3 10y ago
      I know, that's why I wrote "when", knowing it's been considered, but it doesn't appear to be missed by enough developers. I'm just spoiled having used those two features, and anytime someone cites the ML family as part of Rust's influence, it reminds me of these two basic, missing features. Regarding semantics, without having thought about the Rust semantics too much, I'd suggest to check out the most prominent uses for recursive functions in OCaml, SML or Haskell, then try to consider that as the sweet spot to support in Rust.