I am truly moved by what this small (probably one, maybe two person?) team has accomplished here. Just look at their code and its organization, while noting how languages like Rust, Nim, and Go show us how to tackle the software complexity in various software domains. Having been in the enterprise field for a handful of decades, I am convinced that work such as this is signaling a brave new world of software development that is just ahead of us -- small teams, phenomenal productivity, which needs to combine with a grasp of architecture processes to taken on complex IT stuff. After having been in the SAP, Dessault PLM, and Oracle database-centric industries for some decades now, and I am convinced that a new generation of software software engineers with imagination and willingness to learn aspects of the businesses they serve, they will take on these sprawling legacy systems with much less effort than we think it should take right now. Exiting times are ahead for those who use these opportunities, I'd say.
> a brave new world of software development that is just ahead of us -- small teams, phenomenal productivity
It's also the brave new world that lies behind us. Doom, one of the most influential computer games due to technical innovation, was created by a team of 3 programmers (and 8 non-programmers).
Small teams of brilliant people can produce phenonemal results. Unfortunately in big companies a manager is not only measured by his results, but also by his budget and the number of people under him. The division of 100 people simply looks more impressive than the room of 10. So you end up hiring lots of (at best) mediocre programmers, pay them as little as possible, and use big architectures and processes designed to cope with idiots (Enterprise architectures and Enterprise processes, as we call them).
While you're correct it's becoming more of the rule, this has been true a for a very long time.
Clayton Christen wrote about this in 1997 with "The Innovator's Dilemma". He believed it was still repeatable in large organizations via 'intrapreneurship', which I'm not convinced is entirely true... considering the enterprises continued obsession with middle management and hierarchy, and top-down R&D.
I assumed, I guess incorrectly, that Racket was more than a 1-2 person team. Also was perturbed that they were only at a v0.4. Not sure how things like SAP and Oracle are valid in a conversation about Racket...
There's some super exciting stuff in this release, but what caught my eye was this:
> Aynchronous Request Handling (#17)
>
> In 0.5, Rocket will migrate to the latest asynchronous version of hyperand futures with compatibility for async/await syntax. Of utmost importance is preserving Rocket's usability. As such, these changes will be largely internal, with asynchronous I/O peeking over the covers only when explicitly desired or required. As a side effect, we expect a substantial performance boost from the migration as well as resolution to long-standing issues.
Lacking async was my main reason at the time for switching out a hobby project from Rocket to Actix, It's exciting to see that this might change soon as Rocket really just hits the nail on the head when it comes to useability. It _feels_ fantastic compared to so many frameworks both in Rust and other languages.
I don’t really understand this. Futures don’t “peak from under the covers” they hit you over the head with syntax. And iirc Rocket uses a thread per request model.
So I’m guessing they have optimized their threaded model with futures, plus given you the ability to turn on a non blocking mode, but your routes will need to use futures if you do that?
All of this is done while pursuing a computer science PhD at Stanford, teaching, and other life activities. Sergio has been digging deep for a really long time. It is great to see that others are helping to advance Rocket's mission but as with most open source projects, the primary author moves it forward. This release isn't just about new features or rewrites. It's about passion for one's work. It's about grit. It's about uncompromising commitment to excellence.
While there will ever be only one Sergio in the world, there are many others in the broader Rust community who are signaling many of the same positive qualities. The signal is only increasing in strength as new talent adopts the language for critical path work.
I am more optimistic than ever about Rust as a tool for general use, not just because of the tools but because of the leadership in its community.
Once rocket makes it to stable, I think it will be the go to choice for web development in Rust. The focus on creating a great developer story makes rocket a joy to use.
I am shocked that Sergio maintained rocket alone for so long. I would have figured there was a team of 3-4 people working on rocket. Glad to see he is getting help!
I'm really eager to push for use of rocket (and thus rust) at work, but while rocket being on version 0.x it probably is a tough sell. The benefits rocket (at least seems to) bring feels obvious and I notice every now and then at work that "hey, this would be so easy to do with rocket".
I've toyed with various Rust web frameworks and I think rocket is one of the most promising. A thought out, high quality project. The person behind it strikes me as someone who pays attention to details, from the codebase, docs, all the way to the presentational website. Kudos!
I lurk the Matrix room for Rocket and I have no idea where Sergio finds the time to near single handedly develop a huge web framework while helping at least a dozen people a day get into it on the IRC.
It's a bit rough to work with still - the IDE support is still a work in progress (though improving) and there is a compile step with every iteration (incremental compilation has improved this too).
Diesel is the main library for interacting with SQL databases, it wasn't async last time I used it, and a quick web search tells me it still isn't - this has been a BIG problem with Rust over the last year, as everyone waits for the async implementation to finally become stable.
Rust is a funny beast at the moment - you have to deal with the learning curve, you have to deal with the unstable/pre-1.0 libraries (some of which are fine), you have to deal with all the errors the compiler throws at you.
But once you've done all that, something magical happens: you end up with software that is mind-blowingly stable and blazingly fast. It doesn't throw segfaults, it doesn't leak memory, it just works, and works amazingly well.
I've bumped around a site idea I've been working on for five years now. I started with Flask, then Django, then felt bad about page load times so I looked for something faster.
That basically made me shelf it for about two years, until last year when Rocket was rising and I gave it a shot. Got hung up again that year due to missing expressiveness in query handling and shelved it again. In the last month I picked it back up and have been working on it again and I must say - this is the best server side development experience I've had, either on the side or working with node / rails / etc for money.
I also definitely feel the performance bump, even without async in yet, and scaling Rocket apps is much more trivial than trying to scale Flask / Django via multiprocess.
I've also been spoiled by the Rust compiler and RLS, despite its breakages its still some really impressive stuff with how if you can get something to compile it is substantially more likely to work and not have errant edge cases that something written in a less prudent language would struggle with.
I haven't really gotten involved in any larger scale Rust projects or took on a maintainer role on anything substantial - I've just made a few patches to Rocket and some support libraries - but I can easily imagine this is the best kind of environment to do collaborative work in. You get rustfmt for style, you get the best compiler ever for debugging, and the project management of Cargo is just impossibly elegant and delightful over anything else I've used. Its definitely something I'd love to work in at a day job as it matures onto the market.
> What's it like to work with? Do you prefer it to JS/PHP/Python for web related projects?
Of the popular frameworks in languages you mention, Rocket is fairly close to Flask in terms of feel. Rust is a typed language and Rocket uses code generation and function's type signatures to automatically check the incoming parameters.
This can be fairly simple, like verifying+converting a param to a number. It can be fairly involved like setting it up so that if one of your handler function's arguments is an AdminUser, Rocket will take the user id from the request/cookie, connect to the database, and verify that the user is an admin. This is doable with middleware in many frameworks for the languages you mention but the difference is that this is on-demand based on the argument types.
> Can you iterate on code quickly, or is there a compile step on every iteration?
Rust is a compiled language. There's a compile step when you make a code change.
> Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?
There are libraries for interacting with all those things. That said, the Rust async ecosystem is in a transition period at the moment. If you're familiar with the JS transition from callbacks to Promises to async/await, it's basically that. Check back in 6 months.
> Is there good IDE support, for example in Atom?
IDE support in Rust isn't particularly good yet. In general, find references and go to defintion work but autocomplete does not.
> What's it like to work with? Do you prefer it to JS/PHP/Python for web related projects?
Coming from dynamic languages it will feel very different, especially if you don't have a lot of experience with typed compiled languages. Personally, I came from a JS background and I love it. It totally sold me on the benefits of a good type system so much so that I sorely miss it when working with JS now.
Writing web servers in Rust is a fairly new space, it's not as mature as js/php/python, however things are moving quickly. Having your code run orders of magnitude faster is pretty nice too.
> Can you iterate on code quickly, or is there a compile step on every iteration?
I think conflating 'working on code quickly' with compilation is a mistake, however, yes, you do need to compile your code. IMO a compiler will help you iterate more quickly because it's able to check for errors before you run your code.
> Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?
If you want an ORM the thing you want to look at is diesel. I'm not sure if it's async or not.
> Is there good IDE support, for example in Atom?
rust language server (RLS) has plugins for most editors. I think the best experience for developing rust right now is in VScode or vim, IMO.
I am a long time Pythonist and I started with Rust a year ago. Rust has become my goto language now. I mostly use python with the interpreter nowadays (as a enhanced calculator) or for scripting.
Rust has such a great tooling. In Python starting new projects, remembering whether to use pipenv pyenv, pew, pip virtualenv, which file was supposed to mean what feels much much more convoluted. In rust this is a two word shell command.
The compiler will fuck with you more than you would like, but if you don't fight it, but try to figure out why it is right, you will find that most compile errors are totally for a reason. I had FAR less runtime errors with rust. If the code compiles it is either code with a logic error or it just works as intended.
I did a lot of stuff with Django and Flask. On current project I was free to choose a platform, so I went with Rocket.
The framework itself is similar to Flask in productivity and amount of boilerplate, though it's even better. It converts all input data to proper types for you using type signatures of handlers. So I don't need to convert strings into ints, or into json and then check if it conforms to a schema. If handler is called, input is parsed and converted.
Rust itself is more verbose than python. Typical data manipulation, like put something in dict, extract/count uniques, "transpose" a datastructure, load data from file, usually takes 1.5x-3x as much chars. For this price you get strict compile-time type checks that take lots and lots of mental load off code refactoring, C++ level performance, and real multithreading, including easy data parallelism with libs like rayon. Rust also has enums (aka algebraic types or tagged unions) that can help to represent problem space better and make fewer logic mistakes later.
It would be all unicorns and rainbows for me if a more concise database interface was awailable. Currently the go-to ORM is Diesel, and it's very verbose comparing to, say, python's sqlalchemy. Current solution is to move database access from views into methods of a model.
About iteration: code requires recompilation. Changes to non-compiled templates do not. I use Maud templates and they make html look suprisingly clean, they compile and are fast, but well, you need to recompile them every time. Currently debug build takes ~10s, though parsing and typecheking are done in the first several seconds.
Diesel doesn't support async yet, AFAIK. But async is usually used to save on context switches and stack space, allowing to support tens of thousands of live connections. You won't ever have tens of thousands of connections to database like Postgres. 100 connections is quite generous. 500 connections may be possible on the fattest DB boxes. Postgres is not async itself, it allocates a 4MB scratch buffer for each client from the start, IIRC. The only good reason to use async for communication with postgres may be if all of your other code is async and you don't want to deal with sync/async impedance mismatch. Though you'll likely want have connection pool anyway.
About IDEs I can't say much, I use emacs with LSP, it works most of the time.
Is anyone able to lay out some of the reasons why you might want to write web applications in rust? I was under the impression rust was designed as a safer language for low level systems programming. Thanks!
I'd say that in all the talk of Rust being a C replacement, what gets lost is that it is also a very expressive, modern, functionally flavored language, perfectly suitable for higher-level programming.
If you want type safety, speed, expressive language & native binaries, Rust is a good choice.
Web servers for embedded or otherwise constrained systems, bolt-on embedded api servers for your existing apps, or just any high perf app/gateway. All the reasons you would otherwise do it in cpp except nope.
Honestly, the nightly compiler is _really_ stable for the "nightly" moniker it receives. It's basically just the rolling release of the current Rust codebase each night. I've run into issues before where I get an internal compiler error, but those have been rare and rolling back a version (or waiting to roll forward) resolves them.
For the most part, there's very little risk running Rust nightly and in fact, that's my MO. I like being able to receive the latest benefits and opt into compiler gates and whatnot. I couldn't do that on Rust stable.
Overall, I feel very little friction sticking with nightly rust and using libraries that are still nightly-only.
I think it is healthy to have some projects pushing the envelope on what is possible. It provides a goal to work towards and helps test out those new language features so they can be further refined before hitting stable.
It becomes less healthy if the whole community is relying on nightly.
AFAIK Rocket has always been focused on developing an ergonomic type safe API to building web applications. Many things it depends on, codegen, proc macros, that sort of thing, are yet to be stabilized. I'm not affiliated with the project, this is just what I've read about it.
There are other frameworks you can use if you want to use stable, many of them are async already. Granted, none are really 'mature', but this is a new-ish space for Rust anyway.
With all due respect, 166 packages to compile for a 5 line hello-word is so Nodejsy. It is a smell, a red flag.
We should learn more from Go and Erlang.
If you try to compile hello-world in C, you would need a gigantic libc.so, with a lot of stuff you do not need.
These 166 packages you need to compile Rocket, not your hello-world. Rocket itself is much more complex then your hello-world, like libc.so is much more complex than hello-world coded in C, I see nothing wrong with it. Rocket and libc.so were created for solving a wide class of problems and hello-world is just one problem from that class.
gtycomb|7 years ago
wongarsu|7 years ago
It's also the brave new world that lies behind us. Doom, one of the most influential computer games due to technical innovation, was created by a team of 3 programmers (and 8 non-programmers).
Small teams of brilliant people can produce phenonemal results. Unfortunately in big companies a manager is not only measured by his results, but also by his budget and the number of people under him. The division of 100 people simply looks more impressive than the room of 10. So you end up hiring lots of (at best) mediocre programmers, pay them as little as possible, and use big architectures and processes designed to cope with idiots (Enterprise architectures and Enterprise processes, as we call them).
dmix|7 years ago
Clayton Christen wrote about this in 1997 with "The Innovator's Dilemma". He believed it was still repeatable in large organizations via 'intrapreneurship', which I'm not convinced is entirely true... considering the enterprises continued obsession with middle management and hierarchy, and top-down R&D.
herrosheep|7 years ago
Reisen|7 years ago
> Aynchronous Request Handling (#17) > > In 0.5, Rocket will migrate to the latest asynchronous version of hyperand futures with compatibility for async/await syntax. Of utmost importance is preserving Rocket's usability. As such, these changes will be largely internal, with asynchronous I/O peeking over the covers only when explicitly desired or required. As a side effect, we expect a substantial performance boost from the migration as well as resolution to long-standing issues.
Lacking async was my main reason at the time for switching out a hobby project from Rocket to Actix, It's exciting to see that this might change soon as Rocket really just hits the nail on the head when it comes to useability. It _feels_ fantastic compared to so many frameworks both in Rust and other languages.
woah|7 years ago
So I’m guessing they have optimized their threaded model with futures, plus given you the ability to turn on a non blocking mode, but your routes will need to use futures if you do that?
Dowwie|7 years ago
While there will ever be only one Sergio in the world, there are many others in the broader Rust community who are signaling many of the same positive qualities. The signal is only increasing in strength as new talent adopts the language for critical path work.
I am more optimistic than ever about Rust as a tool for general use, not just because of the tools but because of the leadership in its community.
hermanradtke|7 years ago
I am shocked that Sergio maintained rocket alone for so long. I would have figured there was a team of 3-4 people working on rocket. Glad to see he is getting help!
vhakulinen|7 years ago
unknown|7 years ago
[deleted]
k__|7 years ago
rapsey|7 years ago
plainOldText|7 years ago
zanny|7 years ago
osrec|7 years ago
What's it like to work with? Do you prefer it to JS/PHP/Python for web related projects?
Can you iterate on code quickly, or is there a compile step on every iteration?
Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?
Is there good IDE support, for example in Atom?
Thanks!
jlangenauer|7 years ago
Diesel is the main library for interacting with SQL databases, it wasn't async last time I used it, and a quick web search tells me it still isn't - this has been a BIG problem with Rust over the last year, as everyone waits for the async implementation to finally become stable.
Rust is a funny beast at the moment - you have to deal with the learning curve, you have to deal with the unstable/pre-1.0 libraries (some of which are fine), you have to deal with all the errors the compiler throws at you.
But once you've done all that, something magical happens: you end up with software that is mind-blowingly stable and blazingly fast. It doesn't throw segfaults, it doesn't leak memory, it just works, and works amazingly well.
zanny|7 years ago
That basically made me shelf it for about two years, until last year when Rocket was rising and I gave it a shot. Got hung up again that year due to missing expressiveness in query handling and shelved it again. In the last month I picked it back up and have been working on it again and I must say - this is the best server side development experience I've had, either on the side or working with node / rails / etc for money.
I also definitely feel the performance bump, even without async in yet, and scaling Rocket apps is much more trivial than trying to scale Flask / Django via multiprocess.
I've also been spoiled by the Rust compiler and RLS, despite its breakages its still some really impressive stuff with how if you can get something to compile it is substantially more likely to work and not have errant edge cases that something written in a less prudent language would struggle with.
I haven't really gotten involved in any larger scale Rust projects or took on a maintainer role on anything substantial - I've just made a few patches to Rocket and some support libraries - but I can easily imagine this is the best kind of environment to do collaborative work in. You get rustfmt for style, you get the best compiler ever for debugging, and the project management of Cargo is just impossibly elegant and delightful over anything else I've used. Its definitely something I'd love to work in at a day job as it matures onto the market.
grayrest|7 years ago
Of the popular frameworks in languages you mention, Rocket is fairly close to Flask in terms of feel. Rust is a typed language and Rocket uses code generation and function's type signatures to automatically check the incoming parameters.
This can be fairly simple, like verifying+converting a param to a number. It can be fairly involved like setting it up so that if one of your handler function's arguments is an AdminUser, Rocket will take the user id from the request/cookie, connect to the database, and verify that the user is an admin. This is doable with middleware in many frameworks for the languages you mention but the difference is that this is on-demand based on the argument types.
> Can you iterate on code quickly, or is there a compile step on every iteration?
Rust is a compiled language. There's a compile step when you make a code change.
> Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?
There are libraries for interacting with all those things. That said, the Rust async ecosystem is in a transition period at the moment. If you're familiar with the JS transition from callbacks to Promises to async/await, it's basically that. Check back in 6 months.
> Is there good IDE support, for example in Atom?
IDE support in Rust isn't particularly good yet. In general, find references and go to defintion work but autocomplete does not.
leshow|7 years ago
Coming from dynamic languages it will feel very different, especially if you don't have a lot of experience with typed compiled languages. Personally, I came from a JS background and I love it. It totally sold me on the benefits of a good type system so much so that I sorely miss it when working with JS now.
Writing web servers in Rust is a fairly new space, it's not as mature as js/php/python, however things are moving quickly. Having your code run orders of magnitude faster is pretty nice too.
> Can you iterate on code quickly, or is there a compile step on every iteration?
I think conflating 'working on code quickly' with compilation is a mistake, however, yes, you do need to compile your code. IMO a compiler will help you iterate more quickly because it's able to check for errors before you run your code.
> Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?
If you want an ORM the thing you want to look at is diesel. I'm not sure if it's async or not.
> Is there good IDE support, for example in Atom?
rust language server (RLS) has plugins for most editors. I think the best experience for developing rust right now is in VScode or vim, IMO.
atoav|7 years ago
Rust has such a great tooling. In Python starting new projects, remembering whether to use pipenv pyenv, pew, pip virtualenv, which file was supposed to mean what feels much much more convoluted. In rust this is a two word shell command.
The compiler will fuck with you more than you would like, but if you don't fight it, but try to figure out why it is right, you will find that most compile errors are totally for a reason. I had FAR less runtime errors with rust. If the code compiles it is either code with a logic error or it just works as intended.
And it is performant as hell.
spatular|7 years ago
The framework itself is similar to Flask in productivity and amount of boilerplate, though it's even better. It converts all input data to proper types for you using type signatures of handlers. So I don't need to convert strings into ints, or into json and then check if it conforms to a schema. If handler is called, input is parsed and converted.
Rust itself is more verbose than python. Typical data manipulation, like put something in dict, extract/count uniques, "transpose" a datastructure, load data from file, usually takes 1.5x-3x as much chars. For this price you get strict compile-time type checks that take lots and lots of mental load off code refactoring, C++ level performance, and real multithreading, including easy data parallelism with libs like rayon. Rust also has enums (aka algebraic types or tagged unions) that can help to represent problem space better and make fewer logic mistakes later.
It would be all unicorns and rainbows for me if a more concise database interface was awailable. Currently the go-to ORM is Diesel, and it's very verbose comparing to, say, python's sqlalchemy. Current solution is to move database access from views into methods of a model.
About iteration: code requires recompilation. Changes to non-compiled templates do not. I use Maud templates and they make html look suprisingly clean, they compile and are fast, but well, you need to recompile them every time. Currently debug build takes ~10s, though parsing and typecheking are done in the first several seconds.
Diesel doesn't support async yet, AFAIK. But async is usually used to save on context switches and stack space, allowing to support tens of thousands of live connections. You won't ever have tens of thousands of connections to database like Postgres. 100 connections is quite generous. 500 connections may be possible on the fattest DB boxes. Postgres is not async itself, it allocates a 4MB scratch buffer for each client from the start, IIRC. The only good reason to use async for communication with postgres may be if all of your other code is async and you don't want to deal with sync/async impedance mismatch. Though you'll likely want have connection pool anyway.
About IDEs I can't say much, I use emacs with LSP, it works most of the time.
matt2000|7 years ago
AsyncAwait|7 years ago
If you want type safety, speed, expressive language & native binaries, Rust is a good choice.
staticassertion|7 years ago
Those three things are very appealing, whether it's web or anything else.
haiihaii|7 years ago
JTenerife|7 years ago
steveklabnik|7 years ago
leoh|7 years ago
Spartan-S63|7 years ago
For the most part, there's very little risk running Rust nightly and in fact, that's my MO. I like being able to receive the latest benefits and opt into compiler gates and whatnot. I couldn't do that on Rust stable.
Overall, I feel very little friction sticking with nightly rust and using libraries that are still nightly-only.
epage|7 years ago
It becomes less healthy if the whole community is relying on nightly.
leshow|7 years ago
There are other frameworks you can use if you want to use stable, many of them are async already. Granted, none are really 'mature', but this is a new-ish space for Rust anyway.
steveklabnik|7 years ago
The post does discuss this as well.
unknown|7 years ago
[deleted]
throwaway487551|7 years ago
I hope the Tide will do.
steveklabnik|7 years ago
jake_the_third|7 years ago
Yikes!
Does anyone know where I can get an overview of the entirety of rocket's dependency graph. Crates.io only lists 11 direct dependencies.
ordu|7 years ago
These 166 packages you need to compile Rocket, not your hello-world. Rocket itself is much more complex then your hello-world, like libc.so is much more complex than hello-world coded in C, I see nothing wrong with it. Rocket and libc.so were created for solving a wide class of problems and hello-world is just one problem from that class.
IshKebab|7 years ago
InGodsName|7 years ago
Looking for ActiveMerchant equivalent in Rust.
How do you handle subscription billing?
jozfeen|7 years ago
[deleted]
throwaway487550|7 years ago
[deleted]
jozfeen|7 years ago
[deleted]