Rust for web development: 2 years later(kerkour.com)
kerkour.com
Rust for web development: 2 years later
https://kerkour.com/blog/rust-for-web-development-2-years-later
100 comments
Rust is usable for web development if you consider vanilla Python Flask without extensions to be the pinnacle of all web frameworks. The abstraction level in non-nightly Rust frameworks is shockingly bad. Standard features like diffing and generating migrations that are found in mature ecosystems like Django/Laravel/ASP.NET/Prisma are non-existent in Diesel. There is no maintained, out-of-the-box authentication solution. The only framework that try to tackle some of these problems is Rocket and it has been perpetually in nightly despite stable Rust compatibility having been achieved last year. (Companies using Rust need to donate and sponsor more)
What you say is totally true. I still love using Rust for web and bet my projects on it, but is certainly the fact you will need to reimplement certain things.
In the other hand, having less features have help me in re-factor not just the code but how I do the whole thing, making more focused choices to be able to solve problems with less complexity.
Eventually the design you get (partially because the lack of support for things on Rust) is much better overall.
To make things more concrete: I use nearly 0 JS and no "single page apps", use tailwind and have reduced, a lot!, CSS designs issues, have more control in how mutate things, have less API surface, make better use of what PostgreSQL have, etc.
In the other hand, having less features have help me in re-factor not just the code but how I do the whole thing, making more focused choices to be able to solve problems with less complexity.
Eventually the design you get (partially because the lack of support for things on Rust) is much better overall.
To make things more concrete: I use nearly 0 JS and no "single page apps", use tailwind and have reduced, a lot!, CSS designs issues, have more control in how mutate things, have less API surface, make better use of what PostgreSQL have, etc.
My team recently evaluated 37 database schema migration tools and we ended up choosing Dbmate, which is written in Go but can be used with any framework or language, including Rust.
https://github.com/amacneil/dbmate
https://github.com/amacneil/dbmate
Would love to see the comparison analysis. Are you planning to publish it?
Re: the out-of-the-box auth solution, I actually open sourced this based on another thread similar to this from a few weeks ago:
https://github.com/secretkeysio/jelly-actix-web-starter
I built it because I was _also_ frustrated with the same level of abstraction you mention. Granted, I do agree that that Django/etc are more feature-rich, and that's definitely not getting replaced overnight.
https://github.com/secretkeysio/jelly-actix-web-starter
I built it because I was _also_ frustrated with the same level of abstraction you mention. Granted, I do agree that that Django/etc are more feature-rich, and that's definitely not getting replaced overnight.
As of right now, I think rust is appealing to the teams who need all of its features at the same time.
Java/Go will deliver similar perf for most web apps, and have more mature tooling, python will be better for ML, C++ for systems programming, JS/electron will be better for the frontend and java/scala for distributed processing.
Rust has the innards to do all of these things at the same time with one shared code base (albeit somewhat poorly today). It's the only one of the above languages that hasn't made some decision which makes a use case impossible such as running on a VM, no function serialization, no direct hardware bindings etc.
Java/Go will deliver similar perf for most web apps, and have more mature tooling, python will be better for ML, C++ for systems programming, JS/electron will be better for the frontend and java/scala for distributed processing.
Rust has the innards to do all of these things at the same time with one shared code base (albeit somewhat poorly today). It's the only one of the above languages that hasn't made some decision which makes a use case impossible such as running on a VM, no function serialization, no direct hardware bindings etc.
Hey,
I updated to specify that I'm specifically talking about JSON APIs.
Even then DRF and FastAPI offer an order of magnitude more features for free, and battle tested.
I've been looking at Rust API frameworks and the question I keep finding myself asking is, what is the FastAPI equivalent in Rust?
I don't know a ton about FastAPI, but it seems like it's based on OpenAPI. I posted below about Dropshot, which the company I work for wrote, is using and open sourced.
https://crates.io/crates/dropshot
It may or may not interest you!
https://crates.io/crates/dropshot
It may or may not interest you!
Yeah, this does look kind of similar, I'll take a look. Thank you!
I'd say the most powerful part of FastAPI is that it integrates everything in a relatively opinionated way, that you would spend a lot of time setting up Flask plugins/extensions for to get an equivalent feature set.
I'm not sure I'd say it's based on OpenAPI(?), but it does automatically generate OpenAPI based docs from your Python code. There's no intermediate step, the '.../docs' route just exists at runtime.
I'd say the most powerful part of FastAPI is that it integrates everything in a relatively opinionated way, that you would spend a lot of time setting up Flask plugins/extensions for to get an equivalent feature set.
I'm not sure I'd say it's based on OpenAPI(?), but it does automatically generate OpenAPI based docs from your Python code. There's no intermediate step, the '.../docs' route just exists at runtime.
how many years it took since flask to reach fastapi ?
Django (2005) to DRF (2011) is a better take as the products a linked and packed with features, many versions in the making.
I agree,Rust development for microservices and JSON APIs is quite doable. Your new book looks quite exciting. Is there a preview somewhere?
Thank you!
No preview is available today (I don't have enough bandwidth available) but it's on my todo list.
Please feel free to subscribe to the newsletter where I will announce when it's available :) https://kerkour.com/subscribe
Please feel free to subscribe to the newsletter where I will announce when it's available :) https://kerkour.com/subscribe
Subscribed! Bloom is really cool, what's the current status on it?
Thanks again!
I'm working on it 2 days a week beside writing the book.
The next major milestone is receiving emails in the inbox, but I think it will take 2-4 months to have it working.
I'm working on it 2 days a week beside writing the book.
The next major milestone is receiving emails in the inbox, but I think it will take 2-4 months to have it working.
It is a relatively new language but I bet will have more maturity within 5 years and will be very popular by then
"Rust is a real pleasure to use for web development, and I thoroughly recommend it. It is so versatile that, without a doubt, it’s the last programming language I learned. Ever."
This doesn't inspire much confidence in the evaluation of the writer.
This doesn't inspire much confidence in the evaluation of the writer.
I found myself agreeing with both of you at the same time.
I'm very interested in programming languages and expect new and better ones to be discovered in the future. At the same time yesterday I noticed that I'm not as hungry for new languages as I were before: Rust is good enough that I can live with it being the last language in existence.
I'm very interested in programming languages and expect new and better ones to be discovered in the future. At the same time yesterday I noticed that I'm not as hungry for new languages as I were before: Rust is good enough that I can live with it being the last language in existence.
I simply read it as hyperbole and facetious. It made me chuckle.
Hey author here,
I Would love to know why :)
https://en.wikipedia.org/wiki/No_Silver_Bullet
Praises are generally dismissed when they seem to contradict this principle
Praises are generally dismissed when they seem to contradict this principle
I feel like there should be a contradictory meme along the lines of "Don't need 100 wrenches, just a crescent."
While it's doubtful there's a single programming language to rule them all, I seriously doubt the panoply of languages we are faced with is the optimal solution. At some point as a developer new languages stop bending your brain in new ways, they just become the same thing with all new baggage to deal with. I can certainly see where a person is legitimately in search of the last language they ever need to learn.
While it's doubtful there's a single programming language to rule them all, I seriously doubt the panoply of languages we are faced with is the optimal solution. At some point as a developer new languages stop bending your brain in new ways, they just become the same thing with all new baggage to deal with. I can certainly see where a person is legitimately in search of the last language they ever need to learn.
> "Don't need 100 wrenches, just a crescent."
Is that contradictory? Non-adjustable wrenches still exist, and are still used on a regular basis. If you do a lot of work on at a single size they're nice because they weigh less, fit in smaller spaces, and you don't have to worry about then getting jostled and changing size on you.
Is that contradictory? Non-adjustable wrenches still exist, and are still used on a regular basis. If you do a lot of work on at a single size they're nice because they weigh less, fit in smaller spaces, and you don't have to worry about then getting jostled and changing size on you.
Yeah it's not the best analogy, but I think the rest of the idea still stands. I don't think a person looking at a language and thinking that it could be their silver bullet discredits their analysis, and Rust in particularly does seem well suited for that possibility with it's ability to address both low-level and high level programming.
Fair point.
Never heard about that before but I will dig the matter for sure.
That being said I'm sure that rustaceans disagree about the "No Silver Bullet" part (when you can compile to WebAssembly, write HTTP / TCP servers, embedded development and much more).
That being said I'm sure that rustaceans disagree about the "No Silver Bullet" part (when you can compile to WebAssembly, write HTTP / TCP servers, embedded development and much more).
> I'm sure that rustaceans disagree about the "No Silver Bullet"
Rustaceans tend to be a pretty practical bunch, so I'd imagine most of them do agree with it. It was also the one part of your post I didn't agree with (if taken literally)
Rustaceans tend to be a pretty practical bunch, so I'd imagine most of them do agree with it. It was also the one part of your post I didn't agree with (if taken literally)
> That being said I'm sure that rustaceans disagree about the "No Silver Bullet" (when you can compile to WebAssembly, write HTTP / TCP servers, embedded development and much more).
I'm certain they don't. For one, Rust can't even be used in a niche but important class of safety/mission critical software until a certain level of certifications (i.e. DO-178C) are reached so by that measure alone it is disqualified. For two, what targets the languages compile to are a necessary but far from sufficient measure of a language's practicality - the most important ones have nothing to do with the language and everything to do with ecosystem and tooling.
I'm certain they don't. For one, Rust can't even be used in a niche but important class of safety/mission critical software until a certain level of certifications (i.e. DO-178C) are reached so by that measure alone it is disqualified. For two, what targets the languages compile to are a necessary but far from sufficient measure of a language's practicality - the most important ones have nothing to do with the language and everything to do with ecosystem and tooling.
I love Rust, but I'm pretty sure it is not the best language for exploratory programming or quick prototyping.
Even excluding network and org effects -
For distributed problems I'd prefer something like Elixir. This may even be true for web dev (I admit I haven't explored it as much in Rust; just, a lot of what I've had in web services is IO bound, with strong process isolation expectations, and that's perfect for Elixir)
For heavy math, Julia or maybe Python + libs.
To build a DSL, a Lisp.
For something largely integrative of other libraries, whatever language those libraries are built in.
For certain types of problem solving and optimization problems, a logic language like Prolog.
Etc.
For distributed problems I'd prefer something like Elixir. This may even be true for web dev (I admit I haven't explored it as much in Rust; just, a lot of what I've had in web services is IO bound, with strong process isolation expectations, and that's perfect for Elixir)
For heavy math, Julia or maybe Python + libs.
To build a DSL, a Lisp.
For something largely integrative of other libraries, whatever language those libraries are built in.
For certain types of problem solving and optimization problems, a logic language like Prolog.
Etc.
No no no... You're just not using enough Rc<RefCell<>>'s /s
If I were only allowed to use one language ever again it would probably be Rust, partly because of how versatile it is. But nobody is imposing that limitation, and a willingness to continue learning is important as an engineer. Not only because there will always be languages better-suited to certain tasks than Rust is, but because you can learn things from other languages even if you don't end up using them directly. It's a big world out there.
I tried Rust this past weekend. It feels like a language that delivers on the promise of C++ -- fast, good "static" tooling, no VM, scalable to large projects -- but if C++ was designed today, with 40 years of hindsight and we could eliminate all the crazy legacy.
Something I realized doing c++ professionally for the first time last year, it's nearly three different languages. There's an inner core of procedural C, the mid-90s new/delete/raw pointers OO business that got big during the heyday of COM/ATL/other Microsoft technologies, and then what's come to be known as "modern C++", with smart pointers and a lot more automatic stuff.
What I most enjoyed about C++ is how, as someone put it, it feels like an armory with everything on offer from a pocketknife to a nuclear weapon. It integrates with everything, you can write code any way you want from embedded assembly up to functional, and it runs everywhere, on any platform, and can link with Android, Windows, Linux, .NET, Java, whatever.
I'm starting to think garbage collected languages are headed for obsolescence. Like maybe, with better languages, we could ditch all the bullshit of pip, and gems, and all that, and get back to a time where you could just download something, run it, and not have to worry about some gigantic runtime environment that eats all your memory and requires a ton of configuration. It we could pull that off without making it incredibly hard to write simple code, that'd be cool.
Something I realized doing c++ professionally for the first time last year, it's nearly three different languages. There's an inner core of procedural C, the mid-90s new/delete/raw pointers OO business that got big during the heyday of COM/ATL/other Microsoft technologies, and then what's come to be known as "modern C++", with smart pointers and a lot more automatic stuff.
What I most enjoyed about C++ is how, as someone put it, it feels like an armory with everything on offer from a pocketknife to a nuclear weapon. It integrates with everything, you can write code any way you want from embedded assembly up to functional, and it runs everywhere, on any platform, and can link with Android, Windows, Linux, .NET, Java, whatever.
I'm starting to think garbage collected languages are headed for obsolescence. Like maybe, with better languages, we could ditch all the bullshit of pip, and gems, and all that, and get back to a time where you could just download something, run it, and not have to worry about some gigantic runtime environment that eats all your memory and requires a ton of configuration. It we could pull that off without making it incredibly hard to write simple code, that'd be cool.
Garbage collected languages are still better-suited for certain things. You can make most of those things work well enough in Rust by using Rc<>, but a) it's really clunky, and b) reference-counting has caveats, like the fact that it doesn't work for circular references. Swift solves (a), but not (b). On top of that, for programs where you need to constantly allocate/deallocate, I believe (could be wrong on this) that amortized over time, sweeping GC is quite a bit more efficient than reference counting. This is extra relevant once concurrency gets involved, because now your reference-counters have to use an atomic or locking mechanism.
In short: I'm pretty sure GC isn't going anywhere, even if some of its usecases start to get covered by non-GC'd languages.
In short: I'm pretty sure GC isn't going anywhere, even if some of its usecases start to get covered by non-GC'd languages.
Don't know your age and assuming "learned" is supposed to be "learn" but
...
With all the languages that sprang up in the last 25 years, including Rust itself
...
You really don't think there will be another language that's going to be worth learning in the next, say, 25 years?
"it's the last programming language I learned. Ever."
This implies that you are going to stop learning, that you are not open to learning anything more, and that your ego is such that you think you are above having to learn anything else, having reached the peak of perfection upon which you can gaze down at everyone else as being not as enlightened as you.
This is, of course, folly. Just as one who thinks himself the best to rule the kingdom is probably the worst choice for the job, so too the one who thinks himself 100% enlightened is the least likely to actually be considered enlightened by his peers.
This is, of course, folly. Just as one who thinks himself the best to rule the kingdom is probably the worst choice for the job, so too the one who thinks himself 100% enlightened is the least likely to actually be considered enlightened by his peers.
Sounds pretty immature.
I sincerely believe that Rust is here to stay!
Java is a horrid language and it’s here to stay. I don’t understand your point.
Also, when Java first came out, people loved it because it was way more productive than C or C++ for a lot of things because of the presence of garbage collection, and the simple type system.
It really didn’t seem horrible back then.
It really didn’t seem horrible back then.
`Rust is a real pleasure to use for web development, and I thoroughly recommend it. It is so versatile that, without a doubt, it’s the last programming language I learned. Ever.`
This rings a Node.js fandom bell in my head; I'll be very careful taking authors opinion seriously.
Edit: I've myself been working on writing a websocket pubsub server in Rust and I can tell you the ecosystem is not as developed as projected by author.
This rings a Node.js fandom bell in my head; I'll be very careful taking authors opinion seriously.
Edit: I've myself been working on writing a websocket pubsub server in Rust and I can tell you the ecosystem is not as developed as projected by author.
We are using Rust for backend development at Oxide; two of my co-workers (who are the ones doing the work) laid out why they chose to do so: https://www.youtube.com/watch?v=EmSjZbSzA3A
If you asked me five years ago, I would have said "never." I was just asked this ten minutes ago, and my feelings are now "depending on your constraints, it can make a lot of sense, but I don't think it's going to be something for everyone."
If you asked me five years ago, I would have said "never." I was just asked this ten minutes ago, and my feelings are now "depending on your constraints, it can make a lot of sense, but I don't think it's going to be something for everyone."
I didn't understand Oxide's goal. You want to build a "computer" specifically designed for server and cloud.
But isn't that actually CPU and general hardware design (like ASIC/FPGA/etc)?
What does Rust have to do with that? Are you trying to implement Rust's high-level programming language concepts in silicon so the generated assembly would run faster compared to amd64 or M1 or whatever-used-in-servers?
What does Rust have to do with that? Are you trying to implement Rust's high-level programming language concepts in silicon so the generated assembly would run faster compared to amd64 or M1 or whatever-used-in-servers?
We are (well, will be) selling physical servers, yes. It involves a lot of that sort of work (hardware design). But we are also writing a lot of software, from the firmware up. And it’s all in Rust. My job responsibilities are firmware/os dev stuff, these folks are working on the higher level stuff. I believe they went over the context in their talk, but haven’t watched it since they gave it, so maybe I’m misremembering.
> firmware/os dev stuff
Can I ask which IDE do you use for writing code and for debugging? I read your book (which I think is a great starting point), and now I wanted to start playing with Rust, but for embedded (ARM, bare-metal). I have ~20 years of experience writing mostly C for embedded.
What I want is something that allows me to inspect memory, view disassembly, stack trace, setting breakpoints, watching expressions. Much like Eclipse + ARM GCC (GDB) + OpenOCD does, or KEIL uVision, or IAR EW, to name a few IDEs. IDEs I found now supporting Rust are more oriented towards desktop/server development and very limited on the debugging side. I cannot rely on println! since it would require semihosting and I don't want to walk that path yet.
I need something more low-level to really understand and learn what's going on and how it's achieved. Thanks.
Can I ask which IDE do you use for writing code and for debugging? I read your book (which I think is a great starting point), and now I wanted to start playing with Rust, but for embedded (ARM, bare-metal). I have ~20 years of experience writing mostly C for embedded.
What I want is something that allows me to inspect memory, view disassembly, stack trace, setting breakpoints, watching expressions. Much like Eclipse + ARM GCC (GDB) + OpenOCD does, or KEIL uVision, or IAR EW, to name a few IDEs. IDEs I found now supporting Rust are more oriented towards desktop/server development and very limited on the debugging side. I cannot rely on println! since it would require semihosting and I don't want to walk that path yet.
I need something more low-level to really understand and learn what's going on and how it's achieved. Thanks.
Hey there! I personally am a vim person, though I've moved to VS: Code with the vim plugin rather than stock vim. For debugging, I use GDB and openocd/pyocd, on the command line. (I am also on Windows, which puts me in the minority in the company, but this stuff all works well there too, in case you were wondering.)
Semihosting is annoying, but it is really easy to get going in Rust on bare-metal arm. https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihost... We basically have a build-time config to switch between semihosting and ITM, though we're probably at the point very soon where semihosting will basically never be useful again.
Happy to answer more questions if you've got 'em. Our stuff is still closed source but will eventually be open. You may also want to check out https://knurling.ferrous-systems.com/ too; we are using some bits of it but not going whole-hog. Similarly with the rest of the Rust open source ecosystem.
Semihosting is annoying, but it is really easy to get going in Rust on bare-metal arm. https://docs.rs/cortex-m-semihosting/0.3.7/cortex_m_semihost... We basically have a build-time config to switch between semihosting and ITM, though we're probably at the point very soon where semihosting will basically never be useful again.
Happy to answer more questions if you've got 'em. Our stuff is still closed source but will eventually be open. You may also want to check out https://knurling.ferrous-systems.com/ too; we are using some bits of it but not going whole-hog. Similarly with the rest of the Rust open source ecosystem.
Thank you!
OK. I was thinking to assemble a "Press F5 to debug" solution to speed up my learning process. I'm used to command line tools and hacking stuff together too, so I should be fine if that is the current state of the art for debugging (but it would be difficult to convince my coworkers in the future). I wonder if a combination of Eclipse for Rust and OpenOCD plugin is doable. Or perhaps cortex-debug[1] for VS:Code. I have some research to do, to explore the different solutions.
And I'm stuck on Windows too, since many of the tools I use require Windows.
Thanks again.
[1]: https://github.com/marus/cortex-debug
OK. I was thinking to assemble a "Press F5 to debug" solution to speed up my learning process. I'm used to command line tools and hacking stuff together too, so I should be fine if that is the current state of the art for debugging (but it would be difficult to convince my coworkers in the future). I wonder if a combination of Eclipse for Rust and OpenOCD plugin is doable. Or perhaps cortex-debug[1] for VS:Code. I have some research to do, to explore the different solutions.
And I'm stuck on Windows too, since many of the tools I use require Windows.
Thanks again.
[1]: https://github.com/marus/cortex-debug
Yeah, I hear you. Rust tries to fit into existing stuff as much as possible, so stuff that works with openocd/gdb should mostly Just Work, but I just haven't tried it. cortex-debug looks cool, I'll have to give it a shot! It does also say in the README:
> Initial support for Rust code (most functionality is working; disassembly views and variables view may still have issues)
So, that's pretty cool.
> Initial support for Rust code (most functionality is working; disassembly views and variables view may still have issues)
So, that's pretty cool.
also checkout these video series (by Vers Binarii):
https://www.youtube.com/watch?v=Meqhiogdp1o&list=PLP_X41VhYn...
https://www.youtube.com/watch?v=Meqhiogdp1o&list=PLP_X41VhYn...
Very interesting! Good luck to you and your team :)
I was thinking about how difficult it would be to use Rust on FaaS for a web service. Could be a good fit, since most of the web related stuff would be handled by an API gateway.
You can write at least AWS Lambdas and Cloudflare Workers in Rust, supported by upstream. Maybe other platforms too.
This is somewhat tangential, but I'm feeling a bit ambivalent about all of the popular options for building RESTFul APIs lately. With every new entry in the ecosystem, the same libraries (authentication, migrations, logging, authorization) have to be re-implemented. In spite of all of this new stuff (Go, Node, and now Rust) I look around and don't really see how we've done any better than Rails in the past decade or so. Performance needs aside, I feel like we're just going around in circles since Rails.
Performance is a real need. Iterating and maintenance is also a good thing.
A 2x refinement may be a difference in degree, but a 10x refinement will be a difference in kind that will enable other kinds of innovation.
A 2x refinement may be a difference in degree, but a 10x refinement will be a difference in kind that will enable other kinds of innovation.
Pretty much the same reason Wordpress marches on. The advantages of a "better" language are just not worth rebuilding the entire ecosystem around WP or Rails, both of which have massive leads and neither of which are standing still. RESTful APIs are pretty much a solved problem, the next language isn't going to get big by being a better Rails, it's going to get big by doing something new.
Was hoping this would go into more detail; about 50% of it was just repeating well-known points about the language itself. In particular there was no discussion of auth, which you need even if you're just doing JSON APIs.
I've fiddled around with Rust web proof-of-concepts and I tend to agree that the language is somewhat-but-not-completely suited to it, and that the ecosystem is coming-along-but-not-quite-there-yet. But I have a small sample set for those impressions; I was looking forward to reading a more in-depth anecdote about the ups and downs and how to overcome different limitations, as well as a some informed speculation about the future.
I've fiddled around with Rust web proof-of-concepts and I tend to agree that the language is somewhat-but-not-completely suited to it, and that the ecosystem is coming-along-but-not-quite-there-yet. But I have a small sample set for those impressions; I was looking forward to reading a more in-depth anecdote about the ups and downs and how to overcome different limitations, as well as a some informed speculation about the future.
I'm really not sure.
I like Rust but I think it's too "low level" for web development. Ok, it's a better C++ but I wouldn't use it for web development neither. (And yes I agree with the points raised)
For a specific component of a web service where performance is very important absolutely. For a direct connection from a customer or an app, only in very specific cases.
I like Rust but I think it's too "low level" for web development. Ok, it's a better C++ but I wouldn't use it for web development neither. (And yes I agree with the points raised)
For a specific component of a web service where performance is very important absolutely. For a direct connection from a customer or an app, only in very specific cases.
The thing with Rust is that it has a lot of low level features, but you can actually get a lot done without using them. I have found that most data pipelines can be implemented without ever explicitly having to specify borrow lifetimes, for example. To the extent that it is more difficult to implement things in Rust than (say) Python, I’ve found it’s usually because of lack of libraries (although this is much less often the case these days) than the language itself getting in the way.
> Once it compiles, it works (usually).
How does Rust help prevent logic bugs? I thought tests helped prevent logic bugs. Or does the author mean "works" in that it runs where an interpreted language would not (i.e, syntax error)?
How does Rust help prevent logic bugs? I thought tests helped prevent logic bugs. Or does the author mean "works" in that it runs where an interpreted language would not (i.e, syntax error)?
When I repeat this I’m generally talking about type-tests versus logic-tests. In dynamic languages, you only know if it’s fails at runtime so being statically typed eliminates a category of specs.
Rust excels here, in my mind, because of its expressive type system which can allow you to encode logical building-blocks as types and hoist the logic into the type system, eliminating even more specs in favor of compiler errors.
Ultimately, with a sprinkling of logic tests, you can feel confident that compilation means success.
Rust excels here, in my mind, because of its expressive type system which can allow you to encode logical building-blocks as types and hoist the logic into the type system, eliminating even more specs in favor of compiler errors.
Ultimately, with a sprinkling of logic tests, you can feel confident that compilation means success.
The type system is very powerful.
Enums help prevent a lot of logic errors.
Enums help prevent a lot of logic errors.
Well, Rust (or any language) won't prevent business logic bugs.
> Or does the author mean "works" in that it runs where an interpreted language would not (i.e, syntax error)?
More than that, but close. i.e. you won't get NPE from java. Syntax error or type mismatch from interpreted language.
In addition, NewType pattern will stop you from passing seconds into a function that takes ms and vice versa. You won't get data races. You also won't get an `undefined is not an object`.
Long story short, due to language verbosity it's hard to make logical mistakes.
> Or does the author mean "works" in that it runs where an interpreted language would not (i.e, syntax error)?
More than that, but close. i.e. you won't get NPE from java. Syntax error or type mismatch from interpreted language.
In addition, NewType pattern will stop you from passing seconds into a function that takes ms and vice versa. You won't get data races. You also won't get an `undefined is not an object`.
Long story short, due to language verbosity it's hard to make logical mistakes.
Rust compiler isn't going to tell you that your mortgage amortization logic is incorrect. You're still going to need to write tests to validate that the business logic is correct. However, the way that the calculations are implemented can be done in a way with Rust that offers higher levels of confidence about how systems will behave in production.
> When in Node.JS or Go a medium-sized service’s Docker image takes 5 to 10 mins to build and deploy,
I guess you build Go binary in building the docker image. You should build Go binary then build the docker image instead (5 seconds duration).
One the other hand, even if you build Go binary in building the docker image, 5 to 10 mins duration is still not a typical build duration for most medium-sized Go projects. One minute is enough.
I guess you build Go binary in building the docker image. You should build Go binary then build the docker image instead (5 seconds duration).
One the other hand, even if you build Go binary in building the docker image, 5 to 10 mins duration is still not a typical build duration for most medium-sized Go projects. One minute is enough.
I use rocket and it still feels beta, has issues to integrate with other libraries like tokio and mongodb because of the quick changes of versions that are incompatible, and in general lacks a lot of essential features. At the same time it’s light and easy to use, like flask
> Memory management is a distraction: Actually, no. I don’t use that many lexical lifetimes and use instead smart pointers. So yes, I have to understand the differences between a Box, an Rc and an Arc, but my productivity is not impacted compared to Node.JS or Go.
By throwing everything on the heap, I doubt you see much improvement performance-wise over Node or Go. You probably even come out behind idiomatic Go which makes good use of the stack. What's the point?
By throwing everything on the heap, I doubt you see much improvement performance-wise over Node or Go. You probably even come out behind idiomatic Go which makes good use of the stack. What's the point?
Eeeh, I run a few web services on a Rust stack and follow a similar pattern. Performance still tops a comparable Node/Python setup; I unfortunately am not a Go user beyond dabbling so can't comment there, but I suppose I'm just weighing in to say "I've not hit issues with this".
Often times, I Box something and tag it with a "review this" for later. If it somehow becomes a bottleneck, well, it's relatively simple to solve in most web-framework use-cases. Haven't really needed Rc, only needed Arc for shared data structures (rare).
Often times, I Box something and tag it with a "review this" for later. If it somehow becomes a bottleneck, well, it's relatively simple to solve in most web-framework use-cases. Haven't really needed Rc, only needed Arc for shared data structures (rare).
It may also come down to what else the web service needs to do.
If you're just doing a CRUD app, you're probably right.
But if you're wrapping some complex logic that itself makes sense to writ in Rust, then I can see why you might want to write the web interface to it in Rust as well.
If you're just doing a CRUD app, you're probably right.
But if you're wrapping some complex logic that itself makes sense to writ in Rust, then I can see why you might want to write the web interface to it in Rust as well.
For "frontend" web applications, you need so much abstraction that for me it's always about choosing between frameworks rather than languages. (Spring, Laravel, or Rails?)
Unless what you want to build is tiny and simple and you don't need a lot of features, or it's so massive that you can invest on building everything that you need.
Unless what you want to build is tiny and simple and you don't need a lot of features, or it's so massive that you can invest on building everything that you need.
"I have to understand the differences between a Box, an Rc and an Arc"
That's actually a problem I would say, most web dev use Java/C#/Go/Ruby/Python/Node/PHP etc... which all have a GC, so it's a big shift for 99% of people. It completely change the way that you design your app.
That's actually a problem I would say, most web dev use Java/C#/Go/Ruby/Python/Node/PHP etc... which all have a GC, so it's a big shift for 99% of people. It completely change the way that you design your app.
Just wrap everything in an ARC and you will have a GC :)
And now you have a slower Java.
Rust's IDE situation is just not good enough yet. rust-analyzer + emacs incurs constant high CPU usage for me.
I get the same with emacs (gccemacs nativecomp) but it works just fine in vim and vscode.
rust-analyzer with VSCode works fantastically well for me.
What's the advantage of using Rust for web development vs. JavaScript (for example) and using Rust for specific tasks as necessary? The Node/Rust interop is decent enough.
It's much simpler to use one language rather than two. And Rust code isn't much harder to write than JavaScript (especially if you're using TypeScript).
Rust also gets you:
1. Better performance
2. More importantly: much better safety guarantees. Rust web services tend to be set it and forget it. They don't break. they don't crash. They only rarely have bugs.
Rust also gets you:
1. Better performance
2. More importantly: much better safety guarantees. Rust web services tend to be set it and forget it. They don't break. they don't crash. They only rarely have bugs.
> Rust code isn't much harder to write than JavaScript
As someone that's coded in both... eeeehhhhhhh
Memory management in Rust can be a real bear. Just, for example, creating a closure that references a variable outside of its scope is not simple. You can make your life a lot easier by wrapping everything you reuse in Rc<> to make it reference counted, but then you're eating into the performance gains that are the initial selling point, and after a certain point you're just manually implementing the things that JavaScript does for you.
Don't get me wrong, I love Rust. But I wouldn't want to use it everywhere I use JS/TS today.
As someone that's coded in both... eeeehhhhhhh
Memory management in Rust can be a real bear. Just, for example, creating a closure that references a variable outside of its scope is not simple. You can make your life a lot easier by wrapping everything you reuse in Rc<> to make it reference counted, but then you're eating into the performance gains that are the initial selling point, and after a certain point you're just manually implementing the things that JavaScript does for you.
Don't get me wrong, I love Rust. But I wouldn't want to use it everywhere I use JS/TS today.
> creating a closure that references a variable outside of its scope is not simple
Well sure, but how often do you need to do that in a web API endpoint handler? In my experience: not often at all. Rust can be hard, but generally isn't for this use case.
> You can make your life a lot easier by wrapping everything you reuse in Rc<> to make it reference counted, but then you're eating into the performance gains that are the initial selling point
Frameworks like Rocket or Actix-web will handle this for you. In my experience it doesn't tend to affect performance that much. Remember: Node is single-threaded. Multi-threaded + atomics + optimised compiled code is still significantly faster.
Well sure, but how often do you need to do that in a web API endpoint handler? In my experience: not often at all. Rust can be hard, but generally isn't for this use case.
> You can make your life a lot easier by wrapping everything you reuse in Rc<> to make it reference counted, but then you're eating into the performance gains that are the initial selling point
Frameworks like Rocket or Actix-web will handle this for you. In my experience it doesn't tend to affect performance that much. Remember: Node is single-threaded. Multi-threaded + atomics + optimised compiled code is still significantly faster.
> Just, for example, creating a closure that references a variable outside of its scope is not simple.
It's a lot simpler and more performant than in other languages. Rust will tell you if the closure might outlive the variable you're referencing, and it's easy to pick the best option for addressing the issue (move semantics, Rc<>/Arc<>, lifetime specifiers etc.) while keeping best-in-class performance. This is a big part of what Rust is best at, and it's hard to get these advantages any other way.
It's a lot simpler and more performant than in other languages. Rust will tell you if the closure might outlive the variable you're referencing, and it's easy to pick the best option for addressing the issue (move semantics, Rc<>/Arc<>, lifetime specifiers etc.) while keeping best-in-class performance. This is a big part of what Rust is best at, and it's hard to get these advantages any other way.
Yeah, I've definitely had hard to find memory leak issues in JS code due to things like this, which rust prevents with a compiler error.
npm ironically also uses Rust https://www.rust-lang.org/static/pdfs/Rust-npm-Whitepaper.pd....
Only a troglodyte would use JavaScript for server-side programming. And you can’t use rust for front end work. So you’re kind of asking for what the advantage is of an apple over a backhoe - the comparison makes little sense.
> Only a troglodyte would use JavaScript for server-side programming.
As a troglodyte myself, I don't disagree with you, but you're being unnecessarily demeaning.
> And you can’t use rust for front end work.
You certainly can (for example https://yew.rs/), but as usual there are certain caveats and limitations.
As a troglodyte myself, I don't disagree with you, but you're being unnecessarily demeaning.
> And you can’t use rust for front end work.
You certainly can (for example https://yew.rs/), but as usual there are certain caveats and limitations.
30 minutes to build Rust in a container? Why does it take so long?
He's probably using Docker with Mac/Win, which runs a linux VM. The rust compiler doesn't like being run in a VM like this.
It's fast on Linux where containers are native.
It's fast on Linux where containers are native.
The last place I worked at had pretty similar build times for one rust service. Right before I left we ended up finding some low hanging fruit to trim that down to 15-20, but that's still pretty gnarly.
Build times can pile up pretty quickly as systems grow over time. I have to say with that code base the big sin was some extreme macro misuse. It's still possible to see times like that without heavy macro usage though.
That was a native linux build on a fairly modern i7 laptop.
Build times can pile up pretty quickly as systems grow over time. I have to say with that code base the big sin was some extreme macro misuse. It's still possible to see times like that without heavy macro usage though.
That was a native linux build on a fairly modern i7 laptop.
[deleted]
I agree and the security guarantee makes the other trade offs worth it
Web development without garbage collector sounds like a bad idea.
Rust wasn't designed for this.
Rust wasn't designed for this.
This is an argument I've never come across before and I'm curious - why does web development require the use of garbage collection? Recent blogs I've seen suggest that at very large scale, garbage collection in languages like Go have severe side-effects, although obviously there's very few of us running at that scale.
The question shouldn't be "why does web development require the use of garbage collection" but "why would you not use a language with a GC when you have the opportunity". Before Rust (and after the 90s or whenever hardware became sufficiently cheap) it would've been very odd to consider a non-GCed language for something like webdev. Even for things like high-frequency trading where reliable low latency is very important, some companies think using GCed languages like Java and inventing hacks to avoid GC pauses when necessary is a worthwhile tradeoff because of the productivity gain from having a GC.
Certainly Rust has done lots of cool stuff to make living without a GC easier. And maybe it has sufficient compensating advantages to make it worth using for things like webdev (although I wish more of its proponents would try different statically typed functional languages that share some of those advantages but don't make you manage memory manually). But lacking a GC is still pretty clearly a disadvantage outside of a few areas (namely, those where people often use C++).
Certainly Rust has done lots of cool stuff to make living without a GC easier. And maybe it has sufficient compensating advantages to make it worth using for things like webdev (although I wish more of its proponents would try different statically typed functional languages that share some of those advantages but don't make you manage memory manually). But lacking a GC is still pretty clearly a disadvantage outside of a few areas (namely, those where people often use C++).
> Web development without garbage collector sounds like a bad idea.
Before rust, all the mainstream non-gc'ed languages (i.e C/C++) were not recommended mainly due to potential security issues.
The only options left were gc'ed languages (e.g Python, Java, Go).
Now Rust enters which addresses a lot C/C++ issues but the ergonomics, lack of tooling & learning curve is too much for lot of basic web services.
For large scale web services, investing in Rust makes sense to make it more performant & resource efficient, especially a lot of $$ is riding on it.
Before rust, all the mainstream non-gc'ed languages (i.e C/C++) were not recommended mainly due to potential security issues.
The only options left were gc'ed languages (e.g Python, Java, Go).
Now Rust enters which addresses a lot C/C++ issues but the ergonomics, lack of tooling & learning curve is too much for lot of basic web services.
For large scale web services, investing in Rust makes sense to make it more performant & resource efficient, especially a lot of $$ is riding on it.
definitely not relevant to all web-dev, but Discord found that the garbage collection in go was causing bad performance spikes and switched to go for one of their read-state services: https://blog.discord.com/why-discord-is-switching-from-go-to...
This is such a great article. It's one of the examples that comes to mind when people ask me about great engineering blog posts. The TL;DR is the Go GC was causing some fairly large latency spikes under load. Since Rust doesn't do GC, because of its ownership model, these latency spikes didn't exist in their Rust implementation of the service.
Also, pflock you have a small typo there. You probably meant to say from Go to Rust, not Go to Go :)
Also, pflock you have a small typo there. You probably meant to say from Go to Rust, not Go to Go :)
Keep in mind this post is lolspeed porn, not a compelling argument against using a GC in your new project. If you're successful enough to have these problems, you can afford to rewrite in anything.
The author does seem to use Rc and Arc references, which collect garbage using reference counting.
could you provide any reasoning for that, please?