11 ms·

I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which

I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here. Another example is the "This Week in Rust" newsletter which takes progress that would've taken you hours to read about yourself, and puts it into a succinct format that you can get through in minutes [1]. The Rust 2017 roadmap which targeted forward movement on all the language's weakest features was admirable in itself, but even moreso is how much progress has already been made. In particular, I'm really excited about incremental compilation, which is showing as much as 5x speedups in early results [2]. I was also very happy to hear that the Rust team acknowledges that regardless of how performant they are, futures are not a particularly ergonomic or maintainable way to write code, and are considering what new constructs might look like over the longer term: > Over the rest of this year, we expect all of the above libraries to significantly mature; for a middleware ecosystem to sprout up; for the selection of supported protocols and services to grow; and, quite possibly, to tie all this all together with an async/await notation that works natively with Rust’s futures. I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension, or as high level as a DB-backed HTTP application. It seems to have an almost perfect compromise between performance, safety, productivity, and ecosystem. [1] https://this-week-in-rust.org/ https://this-week-in-rust.org/ [2] https://blog.rust-lang.org/2017/05/15/rust-at-two-years.html#rust-should-have-a-pleasant-edit-compile-debug-cycle https://blog.rust-lang.org/2017/05/15/rust-at-two-years.html...

FlyingSnake 9y ago
Agreed. Rust is like a fresh breath of air, and the community around the language is a great example how an OpenSource project can work without being hostile to newcomers. Kudos to the Rust team!
sillysaurus3 9y ago
I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application. Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.
- brandur 9y ago
  > Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy to make, but have to be repaid in full, and without perfect discipline you'll be paying interest on top. Now consider most development teams (who are generally strapped for resources) like middle-class earners who don't make quite enough to pay back that balance every month. It starts to accumulate, and the owed interest compounds. Compilers can do a lot to ensure high productivity and a good user experience: (1) be fast, (2) have great error messages, and (3) be easy to use (no makefiles or heavy build systems). Rust's compiler has learnt from the mistakes of its predecessors in other languages, and does all these for you.
  - omaranto 9y ago
    Compiled languages can have REPLs too. Common Lisp and Haskell come to mind.
    - steveklabnik 9y ago
      https://github.com/murarth/rusti https://github.com/murarth/rusti was the start of one; it's not particularly maintained these days.
    - skariel123 9y ago
mej10 9y ago
Yeah, I feel like they have done an incredible job with that aspect of Rust. Like, they _are_ making a lot of progress, but because of the amount of time spent on developing/informing the community and other non-implementation pieces it feels like a rocket ship rather than "just" a well executed project.
ben_jones 9y ago
In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.
- brandur 9y ago
  > In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I think about personally and which are probably a little more unusual to see: * Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it. * Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct. [1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html https://blog.rust-lang.org/2017/05/05/libz-blitz.html
  - eridius 9y ago
    Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.
jadbox 9y ago
Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.
- im_down_w_otp 9y ago
  I'll happily fund one person full-time to work on that, but you'll have to convince the primary author to go for it :-)
  - erickt 9y ago
    Hello! Rust core and community team member here. If you (or anyone else) are serious about trying to fund development of Tokio, please send us an email at community-team@rust-lang.org and we would happily connect you to people working on the project.
- carllerche 9y ago
  I'm curious what gives you that impression. What do you think is missing or should be tackled sooner than later? There has been a lot of evolution, however it has all been done in backwards compatible ways so there has not yet been a need to bump the version. It's also spread out across a number of crates.

FlyingSnake 9y ago

Agreed. Rust is like a fresh breath of air, and the community around the language is a great example how an OpenSource project can work without being hostile to newcomers. Kudos to the Rust team!

sillysaurus3 9y ago

I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application. Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc.

brandur 9y ago
> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy to make, but have to be repaid in full, and without perfect discipline you'll be paying interest on top. Now consider most development teams (who are generally strapped for resources) like middle-class earners who don't make quite enough to pay back that balance every month. It starts to accumulate, and the owed interest compounds. Compilers can do a lot to ensure high productivity and a good user experience: (1) be fast, (2) have great error messages, and (3) be easy to use (no makefiles or heavy build systems). Rust's compiler has learnt from the mistakes of its predecessors in other languages, and does all these for you.
- omaranto 9y ago
  Compiled languages can have REPLs too. Common Lisp and Haskell come to mind.
  - steveklabnik 9y ago
    https://github.com/murarth/rusti https://github.com/murarth/rusti was the start of one; it's not particularly maintained these days.
  - skariel123 9y ago

mej10 9y ago

Yeah, I feel like they have done an incredible job with that aspect of Rust. Like, they _are_ making a lot of progress, but because of the amount of time spent on developing/informing the community and other non-implementation pieces it feels like a rocket ship rather than "just" a well executed project.

ben_jones 9y ago

In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.

brandur 9y ago
> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I think about personally and which are probably a little more unusual to see: * Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it. * Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct. [1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html https://blog.rust-lang.org/2017/05/05/libz-blitz.html
- eridius 9y ago
  Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.

jadbox 9y ago

Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.

im_down_w_otp 9y ago
I'll happily fund one person full-time to work on that, but you'll have to convince the primary author to go for it :-)
- erickt 9y ago
  Hello! Rust core and community team member here. If you (or anyone else) are serious about trying to fund development of Tokio, please send us an email at community-team@rust-lang.org and we would happily connect you to people working on the project.
carllerche 9y ago
I'm curious what gives you that impression. What do you think is missing or should be tackled sooner than later? There has been a lot of evolution, however it has all been done in backwards compatible ways so there has not yet been a need to bump the version. It's also spread out across a number of crates.