24 ms·

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhi

Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust with the O'Reilly Rust book. We see real productivity in about two weeks, which is actually faster than it was to ramp them up on our C++ code base. The compiler errors are amazing and it's almost like giving them a built in tutor. I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good.

da02 8y ago
Do you use only the O'Reilly book? Or do some grads go and buy a few others?
- ilovecaching 8y ago
  We buy the book for them because we feel it's the best text out there, and they can get the 'Rust Book' for free on Rust's website, so that's two resources for them, plus being able to ask our already ramped up engineers questions.
user111233 8y ago
I had a play with rust at the start of the year while I was evaluating if it would be good for the api backend for my new website. I was using rocket as a framework. The language itself seemed quite ready for use and the book was very helpful but I found all the libraries I needed were half finished and didn't have the features I needed or if they did they had docs that assume you will read the source code and work most of it out yourself. I spent ages trying to work out how to set up postgres with it and got stuck on stuff about connection pools and multithreading. I ended up just using rails in api mode which is a shame because it chews up the limited memory on my server. Most of these issues would go away if I was a rust pro and I could just write my own libraries and read the source but it really didn't feel like rust was helping me become productive fast like ruby did.
- davydog187 8y ago
  Seems like Elixir + Phoenix would be a better alternative over rails for you
  - user111233 8y ago
    Maybe. I also tried Haskell and Yesod but had the same issues. It seems the size of the userbase for a language/framework massively impacts how fast I can do things. With haskell I was posting multiple questions on stack overflow every day but with ruby I find almost everything I need already answered.
- ilovecaching 8y ago
  Ruby is also a dynamically type, interpreted language with a GIL, that's much older than Rust. You're sacrificing a lot in terms of speed and correctness up front to get something that's easier to jump into. Rust crates should have documentation though. Rust has great tooling around writing docs in comments and generating the documentation from those. Rust is also statically typed, which makes it easier to reason about what a function does without the docs. In fact, lifetimes give you even more information about the relationship between inputs and outputs than a normal statically typed language.
  - TylerE 8y ago
    Are you? Every app I've ever written that talks to postgres spends way more time...waiting on postgres than doing anything else. It's like the joke about getting a faster processor so you're 99% idle instead of 95% idle.
    - sanderjd 8y ago
      I always found it easier to improve the time waiting for postgres by tuning critical queries than to track down runaway memory usage and tune garbage collection. I also felt like I spent a lot of my wall clock time during active development waiting for apps to start up and run tests or whatever. There are best practices which speak to most of this, but they were hard won.
hyperpallium 8y ago
> "can we have speed, correctness, and expressiveness in one language?" Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems something more is required... What has rust got beyond that?
- maccam94 8y ago
  > OCaml bytecode and native code programs can be written in a multithreaded style, with preemptive context switching. However, because the garbage collector of the INRIA OCaml system (which is the only currently available full implementation of the language) is not designed for concurrency, symmetric multiprocessing is unsupported. --https://en.wikipedia.org/wiki/OCaml https://en.wikipedia.org/wiki/OCaml Rust has memory-safe concurrency without a GC.
- GolDDranks 8y ago
  Threads and predictable runtime model. (No GC)
  - lmm 8y ago
    Threads are an implementation technique, not a user requirement (at least they shouldn't be).
  - ernst_klim 8y ago
    Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.
    - imtringued 8y ago
      You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is. Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model. What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust. [0] https://doc.rust-lang.org/1.1.0/arena/index.html https://doc.rust-lang.org/1.1.0/arena/index.html
bb88 8y ago
> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love Rust, but..." or "It's a great language once you get past...". My favorite: "There's an awesome web framework but you have to use Rust-nightly..." Javascript is thought of as a terrible language by language snobs, and yet it has a huge following. Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has. The lesson from the early 2000's is that C++ may be a superior language to Java (I used to think that way), however people were so much more productive with Java. They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc. Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today.
- deleted 8y ago
  [deleted]
- ilovecaching 8y ago
  > I don't mean to burst your bubble here. You won't. > But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good documentation. It has a free book. We've had no trouble getting our new grads up and running with Rust. It's not that hard. > Javascript is thought of as a terrible language by language snobs, and yet it has a huge following. Having a huge following doesn't make it less terrible by the measures of PL theory or sensibility. It's also the only choice on the web, but that may soon change, Rust has first class support for wasm so it's in a good spot there. > Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has. By most accounts the Haskell ecosystem and user base are quite large considering it is intended as a research language, and the community is still growing. Rust isn't intended for research, and it's incredibly young compared to Java or Python, so it has plenty of time to catch up. > but people were so much more productive with Java. Hahaha. You mean people wrote a lot of Java. Let's please make the distinction between productivity and writing a bunch of enterprise crapware churned out by barrelful. > They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc. That's exactly what Rust does for you. > Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today. Actually companies are becoming more aware that speed is a feature, and that Moore's law isn't holding out. We're also moving to smaller form factors: phones, watches, glasses... the future is not on the desktop by any means, and no one wants to waste capacity in a datacenter needlessly.
rqs 8y ago
I think the learning curve thing is depends on what's the language that you are compare it with. C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit). Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to learn when you normally learning a language (std library & stuff). Luckily though, Rust did many thing in later years made it a little bit easier to use and learn. Like the rewritten books and manual and in my opinion most importantly few twists to the language. My biggest (maybe nothing in the big picture) complain about Rust now is maybe it's too community driven, which can sometime cause minor fragmentation. As a personal developer, if I've already followed every best practice writing my code, then to be honest, after the code is finished, I'm not willing to rewrite my code just to make it dated or work again (I mean, I'll pay my time to do it, but my hate meter will rise). Currently, Rust cannot fully deliver that. I think Rust need strong leaders to layout a clear and stable plan, so more things can be standardized across it's ecosystem (Somewhat like what Go did, for example, io.Reader && io.Writer is life changing for me). In that way I can keep my hate meter at a safe level.
- steveklabnik 8y ago
  Traits for interop are a prime consideration for std, even if we try to keep it small. But we can only add things when they’re ready; that’s part of the stability you desire. Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.
  - rqs 8y ago
    I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`. In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need. This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any. In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down). BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.
dbcurtis 8y ago
> Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My biggest gripe is that they left out readability. I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project. Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard.
- ilovecaching 8y ago
  Well... compared to Python is kind of an apples to oranges comparison. Compared to Java or C++ I find it to be incredibly direct and expressive. Rust definitely doesn't stop you from writing spaghetti, but no language does.
  - petersellers 8y ago
    I don't think the potential for spaghetti code is the problem, I think it's more the terseness of Rust code that makes it hard to read (speaking as someone who doesn't know Rust very well, but has a mild interest in learning it). I agree with the above complaint - it does feel a bit terse and that makes it harder to read IMO. Languages like Java are more verbose which does make it a bit more frustrating to write but on the flip side I find them easier to read.
    - namibj 8y ago
      That's in part due to the compiler not yet being the best in type inference, and should get better (as far as explicit type signatures are required).
- village-idiot 8y ago
  Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.
MarkovUnchained 8y ago
The failures of Rust are the same failures of C++. Leaky abstractions making it impossible to separate representation details, making the abstraction consume a disproportionate mental load. Given that Rust doesn't actually solve any of the actual problems C++ programmers have, there is no motivation to switch.
- ilovecaching 8y ago
  Rust is based on ADTs, typeclasses, and type parameters. C++s toolkit for abstraction is templates and OOP. They're completely different, and it sounds like you're just trolling anyway.
  - MarkovUnchained 8y ago
    C++ has ADTs from C++17 and will have typeclasses from C++20. Templates with type traits are effectively a superclass of type parameters anyway.
    - iopq 8y ago
      Templates generate bad error messages because they are duck-typed. Rust is better at this.
    - Rusky 8y ago
      C++'s ADTs are std::variant, which is horrific. C++'s type classes are concepts, which are hardly more than syntactic sugar over SFINAE. Neither can really compare to Rust's enums or traits.
- zlynx 8y ago
  Actual problems like: - sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here. - returning a pointer or reference to an invalidated iterator - returning a pointer or reference to the contents of a temporary Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc
weberc2 8y ago
I imagine the learning curve is a lot more manageable when you have an office full of full time Rust developers. If you’re on your own you become painfully aware of how often you need to solicit help, and the time it takes to familiarize someone else with your problem over chat or forum post really eats away at one’s motivation.
- ilovecaching 8y ago
  Well the Rust community is super welcoming, and the meetups have been really positive. They even have the #rust-beginners channel. :) I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it". Rust is a language that rewards understanding, and stops you from making mistakes when you don't know how things are actually working. This is a revolutionary plus. At the end of the day, Rust's rules are what other languages enforce through convention and the school of hard knocks. After all, is that not the point of computing? To have the computer check things for you that a human is prone to error on?
  - weberc2 8y ago
    > Well the Rust community is super welcoming, and the meetups have been really positive. For sure. The Rust community takes the cake when it comes to owning criticism, wanting to make things better (as opposed to excusing issues), and self-organizing to affect change (e.g., the working groups). I like Go and its community is well above average, but it stands to learn from Rust's community IMHO. > the meetups have been really positive. They even have the #rust-beginners channel. :) I know, but a slack/irc/email/etc channel is a really poor substitute for having humans in a room who already have context about the problem you're trying to solve. > I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it". Hard to make heads or tails of this without knowing what you're comparing it to. I do agree that Rust does a fantastic job (via its error messages, documentation, books, etc) at addressing the hard problem of dealing with a compiler that pedantically enforces not-very-intuitive invariants, and I respect Rust for believing that those invariants are worth the trouble. I think they _are_ for lots of applications, but I think Rust needs to do quite a lot on the learnability/intuitability front before the economics justify using Rust for general purpose application development. For the time being, for most applications, it's just so much _cheaper_ to use something like Go in the general case.
otabdeveloper1 8y ago
A shallow learning curve and cute compiler messages are the least of your problems when doing C++-caliber software. The 'small, easy language for ignorant developers' niche certainly exists, but it's already taken by Go. Rust currently provides no benefit over (modern) C++ for the problems where using Rust or C++ makes sense. (Though perhaps Rust will make it easier for layman developers to learn Rust and then transition to C++.)
- andy_ppp 8y ago
  Interesting! I don’t know how modern C++ deals with multi threading and shared memory etc.? Care to fill us in on the state of the art and how it’s as good as rust?
  - otabdeveloper1 8y ago
    State of the art is pthreads and mutexes. The C++ and Rust wrappers for them are roughly equivalent. Rust has some nice features for handling ownership semantics, but they are not significantly better than those in C++. Meanwhile, Rust still lacks a normal exception handling story. Exception handling is absolutely necessary in 2018 for building real software systems. (And even though Rust claims that errors are nicely dichotomized into "recoverable" and "not recoverable" camps, this is simply not true in the real world. There are obvious counterexamples that don't fit into this dichotomy.)
    - setr 8y ago
      Haven't spent that much time with rust, but so far Result<> has sufficed for all my exception-needs; it's not clear to me what the practical difference is between exceptions and result<>, that would be relevant to implementing real software systems? As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result<>, where panic! is naturally left for logic errors (ie states the program should never reach, regardless of circumstance; maintaining invariants), and Result<> is for everything else. Exceptions do the same, but you can catch the broken-invariant case as well? I'm not sure how often you want to recover from such a state though. Another aspect is retrieving the stack-trace, which iirc doesn’t exist in a normal result-type, but error-chain! magically handles it for my case (never looked into how, or at what cost) Otherwise, the other major difference is that rust enforces that you explicitly handle all result types, making it part of the API contract, while most languages, with unchecked exceptions, leave it as a new runtime error to be found after updating your libraries. Java gives you checked exceptions, but in a much more syntax-unpleasant fashion (but thats always the case with java). As far as I'm aware, Result<> seems to me a much cleaner solution than exceptions for the same use-case. A bit of concern for API updating, since the errors are part of the API so its more difficult, but at the same time, I'd rather update the library and fix the codebase, than update and wonder if a new Exception exists (or perhaps, always existed? Is there any way to find out the list of possible exceptions in C++, without reading the function, and all the code it depends on?). The primary unpleasantness is that a single use of Result<> infects the entire callgraph until its handled, but thats true with exceptions as well. I'm not too happy about async/await for the same reason Of course, part of the reason I'm interested in using rust as my hobby-language is because I'm absolutely sick of runtime errors and writing worthless tests in python, so maybe there's an appeal thats missing for me
crimsonalucard 8y ago
C++ itself is not just overly complicated. However, in addition to that, C++ promotes object orientation. Design patterns add an additional layer of complexity for new grads to plow through.

da02 8y ago

Do you use only the O'Reilly book? Or do some grads go and buy a few others?

ilovecaching 8y ago
We buy the book for them because we feel it's the best text out there, and they can get the 'Rust Book' for free on Rust's website, so that's two resources for them, plus being able to ask our already ramped up engineers questions.

user111233 8y ago

I had a play with rust at the start of the year while I was evaluating if it would be good for the api backend for my new website. I was using rocket as a framework. The language itself seemed quite ready for use and the book was very helpful but I found all the libraries I needed were half finished and didn't have the features I needed or if they did they had docs that assume you will read the source code and work most of it out yourself. I spent ages trying to work out how to set up postgres with it and got stuck on stuff about connection pools and multithreading. I ended up just using rails in api mode which is a shame because it chews up the limited memory on my server. Most of these issues would go away if I was a rust pro and I could just write my own libraries and read the source but it really didn't feel like rust was helping me become productive fast like ruby did.

davydog187 8y ago
Seems like Elixir + Phoenix would be a better alternative over rails for you
- user111233 8y ago
  Maybe. I also tried Haskell and Yesod but had the same issues. It seems the size of the userbase for a language/framework massively impacts how fast I can do things. With haskell I was posting multiple questions on stack overflow every day but with ruby I find almost everything I need already answered.
ilovecaching 8y ago
Ruby is also a dynamically type, interpreted language with a GIL, that's much older than Rust. You're sacrificing a lot in terms of speed and correctness up front to get something that's easier to jump into. Rust crates should have documentation though. Rust has great tooling around writing docs in comments and generating the documentation from those. Rust is also statically typed, which makes it easier to reason about what a function does without the docs. In fact, lifetimes give you even more information about the relationship between inputs and outputs than a normal statically typed language.
- TylerE 8y ago
  Are you? Every app I've ever written that talks to postgres spends way more time...waiting on postgres than doing anything else. It's like the joke about getting a faster processor so you're 99% idle instead of 95% idle.
  - sanderjd 8y ago
    I always found it easier to improve the time waiting for postgres by tuning critical queries than to track down runaway memory usage and tune garbage collection. I also felt like I spent a lot of my wall clock time during active development waiting for apps to start up and run tests or whatever. There are best practices which speak to most of this, but they were hard won.

hyperpallium 8y ago

> "can we have speed, correctness, and expressiveness in one language?" Didn't ocaml already answer that question? Since ocaml hasn't dominated, it seems something more is required... What has rust got beyond that?

maccam94 8y ago
> OCaml bytecode and native code programs can be written in a multithreaded style, with preemptive context switching. However, because the garbage collector of the INRIA OCaml system (which is the only currently available full implementation of the language) is not designed for concurrency, symmetric multiprocessing is unsupported. --https://en.wikipedia.org/wiki/OCaml https://en.wikipedia.org/wiki/OCaml Rust has memory-safe concurrency without a GC.
GolDDranks 8y ago
Threads and predictable runtime model. (No GC)
- lmm 8y ago
  Threads are an implementation technique, not a user requirement (at least they shouldn't be).
- ernst_klim 8y ago
  Rust does not have predictable allocations, till it would have custom allocators. Malloc is not better than GC.
  - imtringued 8y ago
    You're moving goal posts so far I don't even understand what your point is. Malloc vs GC doesn't matter at all because you can decide to not use it if you don't want to in Rust, C, C++. The vast majority of performance sensitive code avoids dynamic allocation of memory at all costs by either preallocating a large chunk of memory upfront and reusing it or by only using the stack. When no allocations are performed in a time critical section of code it is not affected by other threads making allocations. This is what a predictable runtime model is. Programming languages like javascript or python always dynamically allocate every single object. When the GC does it's job it has to stop all threads and therefore will stop your time critical code even if you avoid allocating inside it. This is what is commonly understood as an unpredictable runtime model. What does predictable allocations even mean? Allocation is always predictable, it will happen when you use "new" (Java), "Box::new"(Rust), malloc, etc. The unpredictable aspect is the stop the world pause caused by garbage collection. Your complaint regarding custom allocators doesn't make sense because arena allocators [0] and probably others are available in rust. [0] https://doc.rust-lang.org/1.1.0/arena/index.html https://doc.rust-lang.org/1.1.0/arena/index.html

bb88 8y ago

> I'm very bullish on Rust becoming the language of choice in the 2020s for everything from operating systems, web services, desktop applications, and more. It's that good. I don't mean to burst your bubble here. But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Looking at this thread there are plenty of examples of "I love Rust, but..." or "It's a great language once you get past...". My favorite: "There's an awesome web framework but you have to use Rust-nightly..." Javascript is thought of as a terrible language by language snobs, and yet it has a huge following. Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has. The lesson from the early 2000's is that C++ may be a superior language to Java (I used to think that way), however people were so much more productive with Java. They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc. Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today.

deleted 8y ago
[deleted]
ilovecaching 8y ago
> I don't mean to burst your bubble here. You won't. > But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. This is relative. Rust is far easier to learn than C++. It has a compiler that will even enforce that you don't shoot yourself in the foot. It also has nice tooling to get you up and running quickly. It has good documentation. It has a free book. We've had no trouble getting our new grads up and running with Rust. It's not that hard. > Javascript is thought of as a terrible language by language snobs, and yet it has a huge following. Having a huge following doesn't make it less terrible by the measures of PL theory or sensibility. It's also the only choice on the web, but that may soon change, Rust has first class support for wasm so it's in a good spot there. > Haskell, on the other hand, is much beloved, and doesn't. Don't get me wrong, it's got its share of love, but hasn't seen the explosive growth that python or java has. By most accounts the Haskell ecosystem and user base are quite large considering it is intended as a research language, and the community is still growing. Rust isn't intended for research, and it's incredibly young compared to Java or Python, so it has plenty of time to catch up. > but people were so much more productive with Java. Hahaha. You mean people wrote a lot of Java. Let's please make the distinction between productivity and writing a bunch of enterprise crapware churned out by barrelful. > They didn't have to worry about memory management, segfaults, crazy C++ semantics, etc. That's exactly what Rust does for you. > Companies were more willing to throw hardware at a problem to reduce risk/time in development. And that is still true today. Actually companies are becoming more aware that speed is a feature, and that Moore's law isn't holding out. We're also moving to smaller form factors: phones, watches, glasses... the future is not on the desktop by any means, and no one wants to waste capacity in a datacenter needlessly.

rqs 8y ago

I think the learning curve thing is depends on what's the language that you are compare it with. C++ for example, is a hard language, but the learning curve is ... progressive (rise bit by bit). Rust on the other hand, is like climbing a cliff: You're exposed to everything as soon as you start learning. That's all the Rust things (memory safety model and borrow etc) plus the rest of the knowledge that you need to learn when you normally learning a language (std library & stuff). Luckily though, Rust did many thing in later years made it a little bit easier to use and learn. Like the rewritten books and manual and in my opinion most importantly few twists to the language. My biggest (maybe nothing in the big picture) complain about Rust now is maybe it's too community driven, which can sometime cause minor fragmentation. As a personal developer, if I've already followed every best practice writing my code, then to be honest, after the code is finished, I'm not willing to rewrite my code just to make it dated or work again (I mean, I'll pay my time to do it, but my hate meter will rise). Currently, Rust cannot fully deliver that. I think Rust need strong leaders to layout a clear and stable plan, so more things can be standardized across it's ecosystem (Somewhat like what Go did, for example, io.Reader && io.Writer is life changing for me). In that way I can keep my hate meter at a safe level.

steveklabnik 8y ago
Traits for interop are a prime consideration for std, even if we try to keep it small. But we can only add things when they’re ready; that’s part of the stability you desire. Look at the Future trait, as an example. And rust has had the equivalent of io.{Reader, Writer} since 1.0.
- rqs 8y ago
  I know. But for me personally, the `io::Reader` and `io::Writer` is still not comfortable enough. Mainly because it's return values, `io::Error` to be specific. Because I found that in many of my cases, predefined `io::ErrorKind` is not enough for me, this results my abuse of `io::ErrorKind::Other`. In Go, `error` is an interface that can later be asserted, so I can return any `error` then deal with them as late as I need. This gives me ability to write some complex `io.Reader` and `io.Writer`. For example, an `io.Reader` that can Decode data stream, and returns both CodecError and IoError when it encountered any. In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes the code inflexible (As one simple change to the `Result` may effect the entire call chain up and down). BUT ... Maybe it's Go's fault, it treats me too well, make me want something that I cannot have for free (performance cost) else where.

dbcurtis 8y ago

> Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My biggest gripe is that they left out readability. I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project. Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard.

ilovecaching 8y ago
Well... compared to Python is kind of an apples to oranges comparison. Compared to Java or C++ I find it to be incredibly direct and expressive. Rust definitely doesn't stop you from writing spaghetti, but no language does.
- petersellers 8y ago
  I don't think the potential for spaghetti code is the problem, I think it's more the terseness of Rust code that makes it hard to read (speaking as someone who doesn't know Rust very well, but has a mild interest in learning it). I agree with the above complaint - it does feel a bit terse and that makes it harder to read IMO. Languages like Java are more verbose which does make it a bit more frustrating to write but on the flip side I find them easier to read.
  - namibj 8y ago
    That's in part due to the compiler not yet being the best in type inference, and should get better (as far as explicit type signatures are required).
village-idiot 8y ago
Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.

MarkovUnchained 8y ago

The failures of Rust are the same failures of C++. Leaky abstractions making it impossible to separate representation details, making the abstraction consume a disproportionate mental load. Given that Rust doesn't actually solve any of the actual problems C++ programmers have, there is no motivation to switch.

ilovecaching 8y ago
Rust is based on ADTs, typeclasses, and type parameters. C++s toolkit for abstraction is templates and OOP. They're completely different, and it sounds like you're just trolling anyway.
- MarkovUnchained 8y ago
  C++ has ADTs from C++17 and will have typeclasses from C++20. Templates with type traits are effectively a superclass of type parameters anyway.
  - iopq 8y ago
    Templates generate bad error messages because they are duck-typed. Rust is better at this.
  - Rusky 8y ago
    C++'s ADTs are std::variant, which is horrific. C++'s type classes are concepts, which are hardly more than syntactic sugar over SFINAE. Neither can really compare to Rust's enums or traits.
zlynx 8y ago
Actual problems like: - sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here. - returning a pointer or reference to an invalidated iterator - returning a pointer or reference to the contents of a temporary Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc

weberc2 8y ago

I imagine the learning curve is a lot more manageable when you have an office full of full time Rust developers. If you’re on your own you become painfully aware of how often you need to solicit help, and the time it takes to familiarize someone else with your problem over chat or forum post really eats away at one’s motivation.

ilovecaching 8y ago
Well the Rust community is super welcoming, and the meetups have been really positive. They even have the #rust-beginners channel. :) I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it". Rust is a language that rewards understanding, and stops you from making mistakes when you don't know how things are actually working. This is a revolutionary plus. At the end of the day, Rust's rules are what other languages enforce through convention and the school of hard knocks. After all, is that not the point of computing? To have the computer check things for you that a human is prone to error on?
- weberc2 8y ago
  > Well the Rust community is super welcoming, and the meetups have been really positive. For sure. The Rust community takes the cake when it comes to owning criticism, wanting to make things better (as opposed to excusing issues), and self-organizing to affect change (e.g., the working groups). I like Go and its community is well above average, but it stands to learn from Rust's community IMHO. > the meetups have been really positive. They even have the #rust-beginners channel. :) I know, but a slack/irc/email/etc channel is a really poor substitute for having humans in a room who already have context about the problem you're trying to solve. > I find Rust to be fairly easy to reason about. The compiler has awesome messages, and even links you to your error type with more information. I also HIGHLY recommend reading the O'Reilly book AND the official Rust book (the free one) if you feel like you're "just not getting it". Hard to make heads or tails of this without knowing what you're comparing it to. I do agree that Rust does a fantastic job (via its error messages, documentation, books, etc) at addressing the hard problem of dealing with a compiler that pedantically enforces not-very-intuitive invariants, and I respect Rust for believing that those invariants are worth the trouble. I think they _are_ for lots of applications, but I think Rust needs to do quite a lot on the learnability/intuitability front before the economics justify using Rust for general purpose application development. For the time being, for most applications, it's just so much _cheaper_ to use something like Go in the general case.

otabdeveloper1 8y ago

A shallow learning curve and cute compiler messages are the least of your problems when doing C++-caliber software. The 'small, easy language for ignorant developers' niche certainly exists, but it's already taken by Go. Rust currently provides no benefit over (modern) C++ for the problems where using Rust or C++ makes sense. (Though perhaps Rust will make it easier for layman developers to learn Rust and then transition to C++.)

andy_ppp 8y ago
Interesting! I don’t know how modern C++ deals with multi threading and shared memory etc.? Care to fill us in on the state of the art and how it’s as good as rust?
- otabdeveloper1 8y ago
  State of the art is pthreads and mutexes. The C++ and Rust wrappers for them are roughly equivalent. Rust has some nice features for handling ownership semantics, but they are not significantly better than those in C++. Meanwhile, Rust still lacks a normal exception handling story. Exception handling is absolutely necessary in 2018 for building real software systems. (And even though Rust claims that errors are nicely dichotomized into "recoverable" and "not recoverable" camps, this is simply not true in the real world. There are obvious counterexamples that don't fit into this dichotomy.)
  - setr 8y ago
    Haven't spent that much time with rust, but so far Result<> has sufficed for all my exception-needs; it's not clear to me what the practical difference is between exceptions and result<>, that would be relevant to implementing real software systems? As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result<>, where panic! is naturally left for logic errors (ie states the program should never reach, regardless of circumstance; maintaining invariants), and Result<> is for everything else. Exceptions do the same, but you can catch the broken-invariant case as well? I'm not sure how often you want to recover from such a state though. Another aspect is retrieving the stack-trace, which iirc doesn’t exist in a normal result-type, but error-chain! magically handles it for my case (never looked into how, or at what cost) Otherwise, the other major difference is that rust enforces that you explicitly handle all result types, making it part of the API contract, while most languages, with unchecked exceptions, leave it as a new runtime error to be found after updating your libraries. Java gives you checked exceptions, but in a much more syntax-unpleasant fashion (but thats always the case with java). As far as I'm aware, Result<> seems to me a much cleaner solution than exceptions for the same use-case. A bit of concern for API updating, since the errors are part of the API so its more difficult, but at the same time, I'd rather update the library and fix the codebase, than update and wonder if a new Exception exists (or perhaps, always existed? Is there any way to find out the list of possible exceptions in C++, without reading the function, and all the code it depends on?). The primary unpleasantness is that a single use of Result<> infects the entire callgraph until its handled, but thats true with exceptions as well. I'm not too happy about async/await for the same reason Of course, part of the reason I'm interested in using rust as my hobby-language is because I'm absolutely sick of runtime errors and writing worthless tests in python, so maybe there's an appeal thats missing for me

crimsonalucard 8y ago

C++ itself is not just overly complicated. However, in addition to that, C++ promotes object orientation. Design patterns add an additional layer of complexity for new grads to plow through.