21 ms·

Rust can be difficult to learn and frustrating, but it's also very exciting

287 points by pauldix 8y ago

EduardoBautista 8y ago
Rust is one of those languages that I just can't see myself ever working with (I mostly do web dev), but it's a language I am really glad I learned and has made me a better overall developer.
- the_other_guy 8y ago
  you may want to have a look at Rocket https://rocket.rs/ https://rocket.rs/, you won't be disappointed
  - coder543 8y ago
    Rocket requires the nightly Rust compiler, which isn't something I find acceptable for production applications, and it's synchronous, so it's really slow. I have been rather disappointed by what I perceive as the author's unwillingness to work towards stable Rust. They have a GitHub issue where they track all of their dependencies on nightly, and kind of just say they aren't going to do anything about it -- it's up to the Rust core team to just make all the things stable that Rocket is using, or else it will stay on nightly forever. Rocket's biggest feature is their flashy website, in my opinion. Their website is really nice looking and the self-assured marketing is convincing to readers. Actix-Web seems like a more mature framework (I don't expect my application to randomly break), it's asynchronous (so it's really fast) and it works on stable Rust. Warp and Tower Web look like promising async frameworks, but they're not very mature yet. Rouille is a pretty stable option for a simple, synchronous web framework.
    - staticassertion 8y ago
      > which isn't something I find acceptable for production applications For what it's worth, at least some of the largest rust adopters just pin to a nightly version, and don't have a ton of issues upgrading.
      - coder543 8y ago
        That was definitely true before Rust 1.15, but it becomes even less beneficial with each new stable release. I work for one such prominent early adopter of Rust, and we were very happy to move to stable sometime back. Stable versions are widely used, so issues are much more likely to be noticed, and fixes are backported to the current stable release. If you pick a random nightly version, you have much less support to begin with simply because fewer people use it, and you're on nightly because you're dependent on features that haven't been as thoroughly tested as those features that exist on stable, and which could disappear entirely in the next nightly. Each time you upgrade to a different nightly increases the risk of introducing some hard-to-find bug into production. Some companies do use nightly Rust in production. You're completely correct. It's just not something that I would personally be willing to do unless I had absolutely no reasonable alternative.
    - Spartan-S63 8y ago
      It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Despite it not being async, yet, Rocket is my go-to because it has the best ergonomics. Something like actix-web may be more performant, but it's ergonomics are poor in comparison. Regardless, Rust is stabilizing procedural macros which just leaves the never type as the last stabilization required for Rocket to be able to run on stable Rust. Additionally, I believe their next release is targeting the rewrite to async. A lot of it has to do with Rust firming up its own story around async.
      - coder543 8y ago
        > It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Two sides of the same coin. I clearly disagree about the amount of ergonomics that would have to be "sacrificed" in order to make the library usable in a production environment (on stable). So, it's simply an unwillingness to bring the library to stable, from my point of view. Take Tower Web for example: https://medium.com/@carllerche/tower-web-0-3-async-await-and-template-support-e0bb8ed47941 https://medium.com/@carllerche/tower-web-0-3-async-await-and... This has very similar ergonomics to Rocket in that it allows decorating handlers with their route, but it runs on Stable Rust. If you want to use `async fn`, that requires nightly for now since that's literally the nightly syntax for an async function, but the route decorators work on stable. As I previously mentioned, Tower Web is not mature, so I would not recommend it at this stage, but it shows what is possible. I don't personally think that decorating handlers with routes is significantly more ergonomic than defining a table of contents somewhere else, like Actix does it. Defining routes is usually a very small part of your code that you do once and move on. Beyond that, what ergonomics are we talking about? Actix can easily and automatically deserialize JSON into structs, for example: https://actix.rs/docs/extractors/#json https://actix.rs/docs/extractors/#json
      - foldr 8y ago
        Is Rocket still on track to run on stable by the end of 2018, as per your comment here? https://news.ycombinator.com/item?id=16543914 https://news.ycombinator.com/item?id=16543914 Anecdotally, I've been hearing claims that Rocket will run on stable "real soon now" for quite a while now. It just doesn't look like it's going to happen.
    - charliesome 8y ago
      > and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.
      - coder543 8y ago
        I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete each request, that server can only handle 40 requests per second. If that server were asynchronous, each thread could handle thousands of simultaneous connections, making the performance literally thousands of times better at a minimum. If you suggest spinning up an unlimited number of OS threads, that's quickly going to run into problems because most OSes can only handle a couple of thousand threads before you start running into OS limits that you have to adjust, knobs for which aren't always easy to find, and even then, each thread takes a significant amount of time to start and stop, as well as much larger amounts of RAM. An alternative solution is green threading, which Go calls Goroutines, for example. In such a system, the asynchronous operations are handled by the underlying runtime and your code can treat them as synchronous and just spawn new "threads". If you disagree, I would love to hear a more detailed response, because I can't see how your claim could be true.
        charliesome 8y ago
        All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that your userland scheduler can do a better job than the kernel's own scheduler. This bet might pay off in highly specialised cases where your userland scheduler is well tuned to your workload, but the majority of userland schedulers (to name a few examples: the Go runtime, node.js's libuv) are also aimed at general purpose workloads and in many cases are far less mature than the kernel's scheduler. There's been a massive amount of engineering work that's gone into the Linux kernel's various scheduling algorithms over the years. Pathological edge cases resulting in starvation or other performance issues have largely been identified and worked out. The various schedulers are also highly tuneable to the specifics of your workload if you need to do that. These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications. While threads will have 8MB of virtual address space reserved for their stack by default, this is just 'on paper' memory use - no pages are actually allocated until you use them.
- pauldix 8y ago
  Yeah, if I was still doing primarily web applications, particularly version 1 apps where you don't know what the final product will actually be, I would probably still be using Rails for that. It's just insanely fast for creating those apps and once you've found the features that are hits that need to scale, you can pull those pieces out into services written in languages like Rust or Go. But since I mostly do lower level stuff now, Rust is looking very compelling.
- tech2 8y ago
  I kinda felt similarly until I found one of my existing web services wasn't quite fast enough (currently serving around 1000req/s at peak). I could either go for a third rewrite in yet another framework hoping to increase performance by maybe 30%, or I could try something entirely new. First attempt with rust more than doubled performance of the existing system on the same hardware. Now I feel a need to learn more.
  - vmchale 8y ago
    What are you serving? Some of the Rust frameworks for backend should be able to do more than 1000req/s, but it depends what you're doing.
    - tech2 8y ago
      The system's peak _usage_ is 60kreq/min (avg 1k/s), the Python code it's written in can handle maybe 850/s per instance at 100% CPU. Rust is fine, rust is managing almost 2k/s on the same hardware. And this is when I know practically nothing about Rust, I expect I'm likely able to do better given time. It's acting as a simple filter and cache over JSON data on Postgres.
      - emptysea 8y ago
        Any reason you didn't scale up horizontally with more python instances?
        steveklabnik 8y ago
        We have seen production users choose to make this port to save on server costs. You can always scale horizontally, but it comes with a price tag.
        richardwhiuk 8y ago
        Also complexity - managing an order of magnitude more instances is more hassle.
- Axsuul 8y ago
  Can you please expand on how it made you a better developer?
  - EduardoBautista 8y ago
    It made more conscious about when I was modifying values stored in memory or creating copies those values.
tsomctl 8y ago
Can anyone recommend exercises for learning a new language. For example, something like "implement a class with these methods", or implement a function that does this. Something that is realistic, should only take an hour or two to implement for a competent programmer, requires you to learn more complicated features of a language, yet I can finish before getting bored or frustrated?
- bambataa 8y ago
  Things like Cryptopals (https://cryptopals.com/ https://cryptopals.com/) are good. But surely it's going to depend somewhat on the language and what things are easy/hard to do in that language?
- pauldix 8y ago
  For Rust I've seen people reference Rust Koans (https://github.com/crazymykl/rust-koans https://github.com/crazymykl/rust-koans), but I haven't looked at that myself. I wanted a project that was sizeable enough to force me to use a good number of language features (but not all). I think the interpreter was a pretty good balance there, but it definitely took a time investment.
- tomjakubowski 8y ago
  I'd also like to hear what others do to learn languages. I like to write a little RPN calculator. The program's interface might vary depending on the language: to learn browser JS, you might do a DOM-based UI; for Rust it might be a CLI; for Go or Erlang maybe a line-oriented network service. Depending on the interface, this tends to exercise language and runtime features like: string handling and parsing, event handling, conditionals / pattern matching, etc. "Calculator" is also a big enough problem space that you can come back to it to try out more interesting language features (e.g. using Rust enums to model your calculator's operations).
  - djhworld 8y ago
    I usually write data structures like Linked Lists when learning a new programming language. This was a critical mistake for me when learning Rust and led to many, many stumbling blocks
asdfman123 8y ago
Question: does "getting rusty" mean you're getting better or worse at Rust?
- Axsuul 8y ago
  Worse. I think "getting oxidized" would mean getting better.
- felipellrocha 8y ago
  Yes.
ammaskartik 8y ago
I have been learning Rust on and off this year. I have been writing mostly GO for the past few years, but am moving to coding almost primarily in Rust for any new project, and porting over some older ones. Microservices, Data Layer, etc... Honestly, while not perfect, its one of the most beautiful languages I have ever come across. Plus, I have not enjoyed coding in a language this much in a while.
- dev_dull 8y ago
  How does your team (E.g., the people on the hook for reviewing/supporting/contributing to your project) feel about the change? This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).
  - cdoxsey 8y ago
    I don't think that's fair. I'm not entirely sure what beautiful means for a programming language, but I've seen many examples of Go programs which exhibited a beautiful simplicity. This project for example: https://github.com/inconshreveable/slt https://github.com/inconshreveable/slt.
    - dev_dull 8y ago
      I didn’t mean to knock Go. It’s just that when I ask people what they love about it, nobody usually expresses a “feeling” they have when they use it.
      - ammaskartik 8y ago
        Yes I agree. Beauty is highly subjective when it comes to programming languages. Its definitely an expression of a feeling from use and relative successes/failures. I know people I highly respect that call C# with Linq & its lambda implementation very beautiful, and I can see why, but I have not a strong opinion one way or another on it. I had a lot fun when initially learning Rust, and the way I have phased it in to the projects (work & home) that I have been doing has led to successes, which definitely increases my bias towards the fact rust is awesome =).
js2 8y ago
I think folks might find Sentry’s use of Rust interesting. Sentry is quite invested in Python on their backend, but needed additional performance mostly related to symbolication of crash reports. So they have a Rust symbolication library with Python bindings giving them the best of both worlds for their app. https://github.com/getsentry/symbolic https://github.com/getsentry/symbolic
nevi-me 8y ago
I've enjoyed learning Rust, but I'm at the stage where I'm hitting constant stumbling blocks because of the slightly niche nature of what I'm doing. It's the ugly side of Rust; when you're stuck with a series of problems that you can't solve (or take too long to solve), when there aren't enough people in the community to help you, and you end up being unproductive for a while. Where I've seen small projects to their completion, Rust has been greatly rewarding to me. It's the projects that are bigger and more ambitious where I'm struggling. > After reading the first 10 chapters of Programming Rust, I was able to push through the rest of the implementation. I still have open questions, and I’m not sure if the structure I used makes the most sense. There's some chapters of TRPL and other resources that I've re-read a few times by now. Learning the language ends up being quite a lot of an academic exercise, but the benefit's that once a concept clicks, it paves way for many other concepts. My only advice to less experienced programmers (whom you're not) learning Rust: Stay away from writing or rewriting time-critical applications in Rust if you can't tolerate being stuck on a problem or series thereof for weeks.
- ammaskartik 8y ago
  Great job in pushing through though. Where have you been posting for help, I am no ways an expert, and have been learning Rust, but all I have heard is the welcoming nature of the community, and would love to at-least try and help. Its a great language, but yes, a stabilizing and emerging ecosystem. But this is the way it will mature; implement tasks that push the language and hopefully come out with good solutions. The Go ecosystem evolved in this manner as-well, and others as well.
- manaskarekar 8y ago
  Usually someone will help you out on irc or on the rust subreddit, but I think your point may still stand.
  - nevi-me 8y ago
    It depends, my biggest struggle right now is with the tokio/futures ecosystem, so I'm on gitter::tokio quite a bit, and have posted once on /r/rust. With patience, I eventually solve many problems, but the lead-time is costly. Plus when I'm doing something wrong in my code, rustc could take over 5 minutes compiling, and then come back complaining. Even when I find someone willing to help me debug, the process takes a few hours, and I end up feeling bad for wasting someone's time.
vmchale 8y ago
I don't actually think Rust has that many stumbling blocks compared to other programming languages. It's a pain in the ass compared to Haskell but not e.g. Java.
13415 8y ago
I've learned a bit of Rust recently but then started programming in Go. Now that I've learned a decent amount of Go I'm thinking of giving Rust another try, because Go has so many obvious weaknesses. However, I'm still torn between those languages, which I both consider as fancy alternatives to C++ with a growing amount of libraries and community support. I neither like Go nor Rust, but learn them to keep up to date and because I need something with good tooling and many libraries that creates compact and fast executables. Rust still seems overly complicated to me, though, and I say that as someone who enjoys programming in Ada.
- whytaka 8y ago
  Could you elaborate a bit on the obvious weaknesses in Go?
  - 13415 8y ago
    Arbitrary examples off the top of my head: lack of references, no generics, verbose error handling, a few quirks (e.g. need to write (*slice)[i]), inconsistencies like new vs. make, interface{} hacks where there could be a zero-cost abstraction, oddities with untyped literals, no way to declare "not null" pointers and the Million Dollar Mistake, built-in functions for built-in primitives (i.e., append(slice, datum) instead of slice.append(datum)) Stuff like that, which has been discussed over and over. Go is a bit of an odd language if you're used to languages like Ada, CommonLisp, or Racket, but I really like it a lot. I like the sense of pragmatism, that it has been developed to get things done. I believe that Go2 will be even better and am especially happy that the Go team has decided to adjust and include generics rather than stubbornly insisting that they are not needed.
    - whytaka 8y ago
      Thank you!
ram_rar 8y ago
Rust has definitely made me a better systems engineer overall. But, its not a language I can use for web dev. I hope, it gets easier to integrate rust into python in future.
- Axsuul 8y ago
  How so?
- chimpburger 8y ago
  https://rocket.rs/ https://rocket.rs/
  - juststeve 8y ago
    nah actix web and diesel
joobus 8y ago
I'm optimistic for the future of Rust. I currently program in Go for server side web stuff, but with the proposed changes to the Go language, the decision to choose Go over Rust becomes less compelling; Rust already has generics, a competent module system, better error handling, and ADTs. Go had a very narrow scope and very clear oversights, which are now bigger issues they are trying to shoehorn solutions into with the go v2 proposal. I've been following rust for a while and have known it is not web ready, but early next year I think will be a different story.
- Dowwie 8y ago
  It's web ready. It's very web ready.
  - mwcampbell 8y ago
    IMO it's not really web ready until there's one web framework that has a clear majority of mindshare, like Rails for Ruby or Django for Python.
    - fiedzia 8y ago
      What's the point of this requirement? Python doesn't have "the one" either, does it mean its not web ready?
      - deleted 8y ago
        [deleted]
  - jayflux 8y ago
    Woah, I’m a big fan of rust, but saying it’s web ready is disingenuous. Rocket isn’t stable, most of the libraries rocket depends on aren’t stable either. Making http requests.. are there any stable http libraries yet? Last I checked Hyper was still on a 0 release with no h2 support. Rust has conquered a lot, but it’s web service/API story is not complete yet. Go is ahead in this respect.
qaq 8y ago
Learning Rust at the moment and Pony looks really interesting too. I think at this point in time it's safe to say Rust is here to stay so the investment of time into learning it is well worth it as it will stay around for a long time.
ilovecaching 8y ago
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.
erwan 8y ago
I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead. The curve to productivity seem way too steep for the payoff.
- ilovecaching 8y ago
  Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge. It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to ensure you use Rust correctly. It has brought so many crucial advancements as well: immutable by default, typeclasses instead of OOP (thank god), real sum types, better unicode support, better concurrency primitives, and much much much better tooling and package management. No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++. Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap. Go is also incredibly divisive, it's a step backwards that hardcodes a few useful container types, and gives you no facility to create your own. It has a hard coded method of concurrency (goroutines). While useful in it's simplicity, it lacks the generality one would expect of an industrial language, and these concerns are only now being accepted by the Go team in their 2.0 drafts. Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits ,and Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
  - xyzzy_plugh 8y ago
    > Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stability. > Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended. I think that was very much the intent. There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together. Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations. Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming. Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it. I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.
sidcool 8y ago
How does it compare to Go? Concurrency and safety seem to be the forte of Go lang too.
throwaway487548 8y ago
It seems that the main problem with Rust is that it has been grown up not from the CS and PL theory fundamentals, like ML, or Scheme or Erlang or even Go, and it is obviously not a small, clean language everyone loves and appreciates as being beautiful. In other words it is just little better than C++, which is a crap. If a language could be grown from ML (Ocaml) roots (like Scala) instead of C++, it could be much smaller, cleaner and more pleasant to work with. Rust's only innovation is in the compiler tech, which could be ported and simplified (due to more predictable semantics of a functional language) to any ML-family language. I cannot overemphasize how beautiful the pattern-matching with local bindings on algebraic data-types is, and what a wonderful thing is Erlang's pattern-matching on receive, and how, say, protobuf is basically product/record-types annotations, which could be done in a ML-family language itself etc. Rust is under the curse of C++ (a statically typed and standardized dialect of PHP3) if you wish. It is obviously good language compared to C++, but somehow Ruby-ish, compared to ML-family languages. It is actually a pity that Rust and not ML/Ocaml are considered cool and sexy by modern teenagers (like it used to be with Ruby and with Rails not so long ago). ML is much better starting point than C++. Perhaps, polished to perfection languages (Scheme, Haskell) are less appealing for the crowd being too dry, without ambivalence. BTW, the next cool language definitely should be something like typed Erlang with Ocaml's syntax ;) - a hybrid into which typed Python or Typescript are growing into.
- nestorD 8y ago
  I would love to see more ML derived language gain traction (F# being my current favorite) but it has to be said that Rust was first derived from Ocaml : https://fr.slideshare.net/KelCecil/hey-theres-ocaml-in-my-rust https://fr.slideshare.net/KelCecil/hey-theres-ocaml-in-my-ru...
- nchie 8y ago
  While Rust competes with C++ by sharing a lot of goals, it is _way_ closer to ML than C++ is. If it was developed with the goal of being an ML language, my guess is that a lot of what it does wouldn't be possible and it'd end up being another language very similar to OCaml.
- UK-Al05 8y ago
snrji 8y ago
I enjoy coding in Rust, and I think it's a step in the right direction, but I'm still looking for a general purpose programming language which model IO/State effects the same way languages supporting functional programming do with pure functions. Haskell monads are not granular enough. The closer thing I've seen is Purescript, but still is not general purpose enough. Solidity's "pure" annotations are a step in the right direction, but I'm speaking about something much expressive. Also, it should have a Rust/C-like syntax in order to be able to be mainstream, but I'm happy with Haskell-like syntaxes.
- how_to_bake 8y ago
  Check out Nim. They recently added support for a function declaration in addition to a proc. Function automatically checks that it is a pure function with no side effects. Considering the flexibility of the language as a whole, this is really cool!
kieckerjan 8y ago
Rust's main attraction for me (coming from a C background) is that it allows you to do threading reasonably confident that you will not enter a world of pain after a simple mistake. In an ever more concurrent world that is a major plus.
misrab 8y ago
Try writing a linked list in Rust...or implementing a graph. It's not intuitive I think?
atoav 8y ago
I didn’t really find Rust especially hard to learn. I came from Python with a very beginner level experience in embedded C. The hardest part is probably to stop yourself from trying to applying solutions you learned in other languages into Rust. I caught myself multiple times trying to put things into python style classes, which failed horrible each time. The moment you grasp how to do things the rust way you will end up with solutions that are most likely more elegant, safe and fast than the thing that you tried to do first. Over time (a few weeks) I managed to get a good enough intuition on Rusts concepts of ownership to not having to constantly think about it.

287 points by pauldix 8y ago

Rust is one of those languages that I just can't see myself ever working with (I mostly do web dev), but it's a language I am really glad I learned and has made me a better overall developer.

the_other_guy 8y ago
you may want to have a look at Rocket https://rocket.rs/ https://rocket.rs/, you won't be disappointed
- coder543 8y ago
  Rocket requires the nightly Rust compiler, which isn't something I find acceptable for production applications, and it's synchronous, so it's really slow. I have been rather disappointed by what I perceive as the author's unwillingness to work towards stable Rust. They have a GitHub issue where they track all of their dependencies on nightly, and kind of just say they aren't going to do anything about it -- it's up to the Rust core team to just make all the things stable that Rocket is using, or else it will stay on nightly forever. Rocket's biggest feature is their flashy website, in my opinion. Their website is really nice looking and the self-assured marketing is convincing to readers. Actix-Web seems like a more mature framework (I don't expect my application to randomly break), it's asynchronous (so it's really fast) and it works on stable Rust. Warp and Tower Web look like promising async frameworks, but they're not very mature yet. Rouille is a pretty stable option for a simple, synchronous web framework.
  - staticassertion 8y ago
    > which isn't something I find acceptable for production applications For what it's worth, at least some of the largest rust adopters just pin to a nightly version, and don't have a ton of issues upgrading.
    - coder543 8y ago
      That was definitely true before Rust 1.15, but it becomes even less beneficial with each new stable release. I work for one such prominent early adopter of Rust, and we were very happy to move to stable sometime back. Stable versions are widely used, so issues are much more likely to be noticed, and fixes are backported to the current stable release. If you pick a random nightly version, you have much less support to begin with simply because fewer people use it, and you're on nightly because you're dependent on features that haven't been as thoroughly tested as those features that exist on stable, and which could disappear entirely in the next nightly. Each time you upgrade to a different nightly increases the risk of introducing some hard-to-find bug into production. Some companies do use nightly Rust in production. You're completely correct. It's just not something that I would personally be willing to do unless I had absolutely no reasonable alternative.
  - Spartan-S63 8y ago
    It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Despite it not being async, yet, Rocket is my go-to because it has the best ergonomics. Something like actix-web may be more performant, but it's ergonomics are poor in comparison. Regardless, Rust is stabilizing procedural macros which just leaves the never type as the last stabilization required for Rocket to be able to run on stable Rust. Additionally, I believe their next release is targeting the rewrite to async. A lot of it has to do with Rust firming up its own story around async.
    - coder543 8y ago
      > It's not that he's unwilling to make it run on stable, it's that he has to sacrifice ergonomics to make it run on stable. Two sides of the same coin. I clearly disagree about the amount of ergonomics that would have to be "sacrificed" in order to make the library usable in a production environment (on stable). So, it's simply an unwillingness to bring the library to stable, from my point of view. Take Tower Web for example: https://medium.com/@carllerche/tower-web-0-3-async-await-and-template-support-e0bb8ed47941 https://medium.com/@carllerche/tower-web-0-3-async-await-and... This has very similar ergonomics to Rocket in that it allows decorating handlers with their route, but it runs on Stable Rust. If you want to use `async fn`, that requires nightly for now since that's literally the nightly syntax for an async function, but the route decorators work on stable. As I previously mentioned, Tower Web is not mature, so I would not recommend it at this stage, but it shows what is possible. I don't personally think that decorating handlers with routes is significantly more ergonomic than defining a table of contents somewhere else, like Actix does it. Defining routes is usually a very small part of your code that you do once and move on. Beyond that, what ergonomics are we talking about? Actix can easily and automatically deserialize JSON into structs, for example: https://actix.rs/docs/extractors/#json https://actix.rs/docs/extractors/#json
    - foldr 8y ago
      Is Rocket still on track to run on stable by the end of 2018, as per your comment here? https://news.ycombinator.com/item?id=16543914 https://news.ycombinator.com/item?id=16543914 Anecdotally, I've been hearing claims that Rocket will run on stable "real soon now" for quite a while now. It just doesn't look like it's going to happen.
  - charliesome 8y ago
    > and it's synchronous, so it's really slow. > it's asynchronous (so it's really fast) Whether something is 'synchronous' or 'asynchronous' has absolutely no bearing on performance.
    - coder543 8y ago
      I don't understand the point you're trying to make. In networked stuff, the (a)synchronicity absolutely does make something fast or slow. Suppose you have a synchronous web server with 4 threads, synchronous naturally means that each thread can only handle one request at a time. Each request can take dozens or hundreds of milliseconds to complete, just by being bottlenecked on latency. If it takes 100ms to complete each request, that server can only handle 40 requests per second. If that server were asynchronous, each thread could handle thousands of simultaneous connections, making the performance literally thousands of times better at a minimum. If you suggest spinning up an unlimited number of OS threads, that's quickly going to run into problems because most OSes can only handle a couple of thousand threads before you start running into OS limits that you have to adjust, knobs for which aren't always easy to find, and even then, each thread takes a significant amount of time to start and stop, as well as much larger amounts of RAM. An alternative solution is green threading, which Go calls Goroutines, for example. In such a system, the asynchronous operations are handled by the underlying runtime and your code can treat them as synchronous and just spawn new "threads". If you disagree, I would love to hear a more detailed response, because I can't see how your claim could be true.
      - charliesome 8y ago
        All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that your userland scheduler can do a better job than the kernel's own scheduler. This bet might pay off in highly specialised cases where your userland scheduler is well tuned to your workload, but the majority of userland schedulers (to name a few examples: the Go runtime, node.js's libuv) are also aimed at general purpose workloads and in many cases are far less mature than the kernel's scheduler. There's been a massive amount of engineering work that's gone into the Linux kernel's various scheduling algorithms over the years. Pathological edge cases resulting in starvation or other performance issues have largely been identified and worked out. The various schedulers are also highly tuneable to the specifics of your workload if you need to do that. These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications. While threads will have 8MB of virtual address space reserved for their stack by default, this is just 'on paper' memory use - no pages are actually allocated until you use them.
pauldix 8y ago
Yeah, if I was still doing primarily web applications, particularly version 1 apps where you don't know what the final product will actually be, I would probably still be using Rails for that. It's just insanely fast for creating those apps and once you've found the features that are hits that need to scale, you can pull those pieces out into services written in languages like Rust or Go. But since I mostly do lower level stuff now, Rust is looking very compelling.
tech2 8y ago
I kinda felt similarly until I found one of my existing web services wasn't quite fast enough (currently serving around 1000req/s at peak). I could either go for a third rewrite in yet another framework hoping to increase performance by maybe 30%, or I could try something entirely new. First attempt with rust more than doubled performance of the existing system on the same hardware. Now I feel a need to learn more.
- vmchale 8y ago
  What are you serving? Some of the Rust frameworks for backend should be able to do more than 1000req/s, but it depends what you're doing.
  - tech2 8y ago
    The system's peak _usage_ is 60kreq/min (avg 1k/s), the Python code it's written in can handle maybe 850/s per instance at 100% CPU. Rust is fine, rust is managing almost 2k/s on the same hardware. And this is when I know practically nothing about Rust, I expect I'm likely able to do better given time. It's acting as a simple filter and cache over JSON data on Postgres.
    - emptysea 8y ago
      Any reason you didn't scale up horizontally with more python instances?
      - steveklabnik 8y ago
        We have seen production users choose to make this port to save on server costs. You can always scale horizontally, but it comes with a price tag.
        richardwhiuk 8y ago
        Also complexity - managing an order of magnitude more instances is more hassle.
Axsuul 8y ago
Can you please expand on how it made you a better developer?
- EduardoBautista 8y ago
  It made more conscious about when I was modifying values stored in memory or creating copies those values.

tsomctl 8y ago

Can anyone recommend exercises for learning a new language. For example, something like "implement a class with these methods", or implement a function that does this. Something that is realistic, should only take an hour or two to implement for a competent programmer, requires you to learn more complicated features of a language, yet I can finish before getting bored or frustrated?

bambataa 8y ago
Things like Cryptopals (https://cryptopals.com/ https://cryptopals.com/) are good. But surely it's going to depend somewhat on the language and what things are easy/hard to do in that language?
pauldix 8y ago
For Rust I've seen people reference Rust Koans (https://github.com/crazymykl/rust-koans https://github.com/crazymykl/rust-koans), but I haven't looked at that myself. I wanted a project that was sizeable enough to force me to use a good number of language features (but not all). I think the interpreter was a pretty good balance there, but it definitely took a time investment.
tomjakubowski 8y ago
I'd also like to hear what others do to learn languages. I like to write a little RPN calculator. The program's interface might vary depending on the language: to learn browser JS, you might do a DOM-based UI; for Rust it might be a CLI; for Go or Erlang maybe a line-oriented network service. Depending on the interface, this tends to exercise language and runtime features like: string handling and parsing, event handling, conditionals / pattern matching, etc. "Calculator" is also a big enough problem space that you can come back to it to try out more interesting language features (e.g. using Rust enums to model your calculator's operations).
- djhworld 8y ago
  I usually write data structures like Linked Lists when learning a new programming language. This was a critical mistake for me when learning Rust and led to many, many stumbling blocks

asdfman123 8y ago

Question: does "getting rusty" mean you're getting better or worse at Rust?

Axsuul 8y ago
Worse. I think "getting oxidized" would mean getting better.
felipellrocha 8y ago
Yes.

ammaskartik 8y ago

I have been learning Rust on and off this year. I have been writing mostly GO for the past few years, but am moving to coding almost primarily in Rust for any new project, and porting over some older ones. Microservices, Data Layer, etc... Honestly, while not perfect, its one of the most beautiful languages I have ever come across. Plus, I have not enjoyed coding in a language this much in a while.

dev_dull 8y ago
How does your team (E.g., the people on the hook for reviewing/supporting/contributing to your project) feel about the change? This is a big difference when moving from Go. A language that nobody calls beautiful, but is very easy for a team to contribute to and support (relative to other languages).
- cdoxsey 8y ago
  I don't think that's fair. I'm not entirely sure what beautiful means for a programming language, but I've seen many examples of Go programs which exhibited a beautiful simplicity. This project for example: https://github.com/inconshreveable/slt https://github.com/inconshreveable/slt.
  - dev_dull 8y ago
    I didn’t mean to knock Go. It’s just that when I ask people what they love about it, nobody usually expresses a “feeling” they have when they use it.
    - ammaskartik 8y ago
      Yes I agree. Beauty is highly subjective when it comes to programming languages. Its definitely an expression of a feeling from use and relative successes/failures. I know people I highly respect that call C# with Linq & its lambda implementation very beautiful, and I can see why, but I have not a strong opinion one way or another on it. I had a lot fun when initially learning Rust, and the way I have phased it in to the projects (work & home) that I have been doing has led to successes, which definitely increases my bias towards the fact rust is awesome =).

js2 8y ago

I think folks might find Sentry’s use of Rust interesting. Sentry is quite invested in Python on their backend, but needed additional performance mostly related to symbolication of crash reports. So they have a Rust symbolication library with Python bindings giving them the best of both worlds for their app. https://github.com/getsentry/symbolic https://github.com/getsentry/symbolic

nevi-me 8y ago

I've enjoyed learning Rust, but I'm at the stage where I'm hitting constant stumbling blocks because of the slightly niche nature of what I'm doing. It's the ugly side of Rust; when you're stuck with a series of problems that you can't solve (or take too long to solve), when there aren't enough people in the community to help you, and you end up being unproductive for a while. Where I've seen small projects to their completion, Rust has been greatly rewarding to me. It's the projects that are bigger and more ambitious where I'm struggling. > After reading the first 10 chapters of Programming Rust, I was able to push through the rest of the implementation. I still have open questions, and I’m not sure if the structure I used makes the most sense. There's some chapters of TRPL and other resources that I've re-read a few times by now. Learning the language ends up being quite a lot of an academic exercise, but the benefit's that once a concept clicks, it paves way for many other concepts. My only advice to less experienced programmers (whom you're not) learning Rust: Stay away from writing or rewriting time-critical applications in Rust if you can't tolerate being stuck on a problem or series thereof for weeks.

ammaskartik 8y ago
Great job in pushing through though. Where have you been posting for help, I am no ways an expert, and have been learning Rust, but all I have heard is the welcoming nature of the community, and would love to at-least try and help. Its a great language, but yes, a stabilizing and emerging ecosystem. But this is the way it will mature; implement tasks that push the language and hopefully come out with good solutions. The Go ecosystem evolved in this manner as-well, and others as well.
manaskarekar 8y ago
Usually someone will help you out on irc or on the rust subreddit, but I think your point may still stand.
- nevi-me 8y ago
  It depends, my biggest struggle right now is with the tokio/futures ecosystem, so I'm on gitter::tokio quite a bit, and have posted once on /r/rust. With patience, I eventually solve many problems, but the lead-time is costly. Plus when I'm doing something wrong in my code, rustc could take over 5 minutes compiling, and then come back complaining. Even when I find someone willing to help me debug, the process takes a few hours, and I end up feeling bad for wasting someone's time.

vmchale 8y ago

I don't actually think Rust has that many stumbling blocks compared to other programming languages. It's a pain in the ass compared to Haskell but not e.g. Java.

13415 8y ago

I've learned a bit of Rust recently but then started programming in Go. Now that I've learned a decent amount of Go I'm thinking of giving Rust another try, because Go has so many obvious weaknesses. However, I'm still torn between those languages, which I both consider as fancy alternatives to C++ with a growing amount of libraries and community support. I neither like Go nor Rust, but learn them to keep up to date and because I need something with good tooling and many libraries that creates compact and fast executables. Rust still seems overly complicated to me, though, and I say that as someone who enjoys programming in Ada.

whytaka 8y ago
Could you elaborate a bit on the obvious weaknesses in Go?
- 13415 8y ago
  Arbitrary examples off the top of my head: lack of references, no generics, verbose error handling, a few quirks (e.g. need to write (*slice)[i]), inconsistencies like new vs. make, interface{} hacks where there could be a zero-cost abstraction, oddities with untyped literals, no way to declare "not null" pointers and the Million Dollar Mistake, built-in functions for built-in primitives (i.e., append(slice, datum) instead of slice.append(datum)) Stuff like that, which has been discussed over and over. Go is a bit of an odd language if you're used to languages like Ada, CommonLisp, or Racket, but I really like it a lot. I like the sense of pragmatism, that it has been developed to get things done. I believe that Go2 will be even better and am especially happy that the Go team has decided to adjust and include generics rather than stubbornly insisting that they are not needed.
  - whytaka 8y ago
    Thank you!

ram_rar 8y ago

Rust has definitely made me a better systems engineer overall. But, its not a language I can use for web dev. I hope, it gets easier to integrate rust into python in future.

Axsuul 8y ago
How so?
chimpburger 8y ago
https://rocket.rs/ https://rocket.rs/
- juststeve 8y ago
  nah actix web and diesel

joobus 8y ago

I'm optimistic for the future of Rust. I currently program in Go for server side web stuff, but with the proposed changes to the Go language, the decision to choose Go over Rust becomes less compelling; Rust already has generics, a competent module system, better error handling, and ADTs. Go had a very narrow scope and very clear oversights, which are now bigger issues they are trying to shoehorn solutions into with the go v2 proposal. I've been following rust for a while and have known it is not web ready, but early next year I think will be a different story.

Dowwie 8y ago
It's web ready. It's very web ready.
- mwcampbell 8y ago
  IMO it's not really web ready until there's one web framework that has a clear majority of mindshare, like Rails for Ruby or Django for Python.
  - fiedzia 8y ago
    What's the point of this requirement? Python doesn't have "the one" either, does it mean its not web ready?
    - deleted 8y ago
      [deleted]
- jayflux 8y ago
  Woah, I’m a big fan of rust, but saying it’s web ready is disingenuous. Rocket isn’t stable, most of the libraries rocket depends on aren’t stable either. Making http requests.. are there any stable http libraries yet? Last I checked Hyper was still on a 0 release with no h2 support. Rust has conquered a lot, but it’s web service/API story is not complete yet. Go is ahead in this respect.

qaq 8y ago

Learning Rust at the moment and Pony looks really interesting too. I think at this point in time it's safe to say Rust is here to stay so the investment of time into learning it is well worth it as it will stay around for a long time.

ilovecaching 8y ago

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.

erwan 8y ago

I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead. The curve to productivity seem way too steep for the payoff.

ilovecaching 8y ago
Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge. It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to ensure you use Rust correctly. It has brought so many crucial advancements as well: immutable by default, typeclasses instead of OOP (thank god), real sum types, better unicode support, better concurrency primitives, and much much much better tooling and package management. No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++. Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap. Go is also incredibly divisive, it's a step backwards that hardcodes a few useful container types, and gives you no facility to create your own. It has a hard coded method of concurrency (goroutines). While useful in it's simplicity, it lacks the generality one would expect of an industrial language, and these concerns are only now being accepted by the Go team in their 2.0 drafts. Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits ,and Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
- xyzzy_plugh 8y ago
  > Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stability. > Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended. I think that was very much the intent. There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together. Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations. Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming. Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it. I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.

sidcool 8y ago

How does it compare to Go? Concurrency and safety seem to be the forte of Go lang too.

throwaway487548 8y ago

It seems that the main problem with Rust is that it has been grown up not from the CS and PL theory fundamentals, like ML, or Scheme or Erlang or even Go, and it is obviously not a small, clean language everyone loves and appreciates as being beautiful. In other words it is just little better than C++, which is a crap. If a language could be grown from ML (Ocaml) roots (like Scala) instead of C++, it could be much smaller, cleaner and more pleasant to work with. Rust's only innovation is in the compiler tech, which could be ported and simplified (due to more predictable semantics of a functional language) to any ML-family language. I cannot overemphasize how beautiful the pattern-matching with local bindings on algebraic data-types is, and what a wonderful thing is Erlang's pattern-matching on receive, and how, say, protobuf is basically product/record-types annotations, which could be done in a ML-family language itself etc. Rust is under the curse of C++ (a statically typed and standardized dialect of PHP3) if you wish. It is obviously good language compared to C++, but somehow Ruby-ish, compared to ML-family languages. It is actually a pity that Rust and not ML/Ocaml are considered cool and sexy by modern teenagers (like it used to be with Ruby and with Rails not so long ago). ML is much better starting point than C++. Perhaps, polished to perfection languages (Scheme, Haskell) are less appealing for the crowd being too dry, without ambivalence. BTW, the next cool language definitely should be something like typed Erlang with Ocaml's syntax ;) - a hybrid into which typed Python or Typescript are growing into.

nestorD 8y ago
I would love to see more ML derived language gain traction (F# being my current favorite) but it has to be said that Rust was first derived from Ocaml : https://fr.slideshare.net/KelCecil/hey-theres-ocaml-in-my-rust https://fr.slideshare.net/KelCecil/hey-theres-ocaml-in-my-ru...
nchie 8y ago
While Rust competes with C++ by sharing a lot of goals, it is _way_ closer to ML than C++ is. If it was developed with the goal of being an ML language, my guess is that a lot of what it does wouldn't be possible and it'd end up being another language very similar to OCaml.
UK-Al05 8y ago

snrji 8y ago

I enjoy coding in Rust, and I think it's a step in the right direction, but I'm still looking for a general purpose programming language which model IO/State effects the same way languages supporting functional programming do with pure functions. Haskell monads are not granular enough. The closer thing I've seen is Purescript, but still is not general purpose enough. Solidity's "pure" annotations are a step in the right direction, but I'm speaking about something much expressive. Also, it should have a Rust/C-like syntax in order to be able to be mainstream, but I'm happy with Haskell-like syntaxes.

how_to_bake 8y ago
Check out Nim. They recently added support for a function declaration in addition to a proc. Function automatically checks that it is a pure function with no side effects. Considering the flexibility of the language as a whole, this is really cool!

kieckerjan 8y ago

Rust's main attraction for me (coming from a C background) is that it allows you to do threading reasonably confident that you will not enter a world of pain after a simple mistake. In an ever more concurrent world that is a major plus.

misrab 8y ago

Try writing a linked list in Rust...or implementing a graph. It's not intuitive I think?

atoav 8y ago

I didn’t really find Rust especially hard to learn. I came from Python with a very beginner level experience in embedded C. The hardest part is probably to stop yourself from trying to applying solutions you learned in other languages into Rust. I caught myself multiple times trying to put things into python style classes, which failed horrible each time. The moment you grasp how to do things the rust way you will end up with solutions that are most likely more elegant, safe and fast than the thing that you tried to do first. Over time (a few weeks) I managed to get a good enough intuition on Rusts concepts of ownership to not having to constantly think about it.