Is Rust web yet?(arewewebyet.org)
arewewebyet.org
Is Rust web yet?
http://www.arewewebyet.org/
294 コメント
Figma does, and they cut their load time down by 3x. As a frequent user, I can attest to how snappy it feels despite the heavy computations it needs to do in the background. Evan Wallace, their CTO did a great write up on it [1].
[1] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
[1] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
I find it strange when people say "cut by 3 times"
What they did was cutting it to 30% or by 70%.
What they did was cutting it to 30% or by 70%.
It depends if you think additively or multiplicatively:
newLoadTime = oldLoadTime - (70% of oldLoadTime)
newLoadTime = oldLoadTime / 3
Personally I find the additive expression unintuitive and find the multiplicative expression easier to reason about. "cut by" does generally indicate an additive expression. It should really have been phrased as something like "reduced by a factor of 3"
newLoadTime = oldLoadTime - (70% of oldLoadTime)
newLoadTime = oldLoadTime / 3
Personally I find the additive expression unintuitive and find the multiplicative expression easier to reason about. "cut by" does generally indicate an additive expression. It should really have been phrased as something like "reduced by a factor of 3"
But it isn't a factor.
It is.
Factor, noun "a number or quantity that when multiplied with another produces a given number or expression."
It's not an exact integer factor, but I think the concept of factor is more general than that.
Factor, noun "a number or quantity that when multiplied with another produces a given number or expression."
It's not an exact integer factor, but I think the concept of factor is more general than that.
[deleted]
>It's not an exact integer factor
That would imply the phrase has to be "reduced by a factor of 1/3", which leads to the wrong impression. The better technically correct phrase would be "reduced by a divisor of 3"
That would imply the phrase has to be "reduced by a factor of 1/3", which leads to the wrong impression. The better technically correct phrase would be "reduced by a divisor of 3"
If you reduce it by a multiple > 1 of its total time it must be negative, i.e. it's giving you back CPU cycles every time you execute it. Quite impressive.
I’m also curious about how valuable writing rust that compiled to webasm is. Wouldn’t I still have to write a lot of un-rust-like code to manipulate the DOM? I could definitely see writing a core library in rust and wrapping it in a thin interface to use it in JS, though. Is that the idea?
The stand-out uses of WebAssembly have mostly been augmenting a JavaScript application that has strenuous computation needs in certain parts. As others have mentioned Figma, Twitch, etc. have used it to great effect without rewriting their entire app in Rust or another linear-memory based language.
https://webassembly.org/docs/use-cases/
TL;DR: - "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server - "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)
TL;DR: - "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server - "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)
Using webasm as a general purpose platform for the execution of untrusted code is also pretty interesting - this might be within server side code or non-browser desktop apps.
It's a way to do things in the browser that you normally can only do with JavaScript but with better performance and written in a different language
You can use existing e.g C# libraries on the client side (browser)
e.g you can develop parser in console application and then ship it to the browser and use it there to parse e.g code without changing a single line of code or having to do some bullshit or traspiling it to js.
Once it matures it will allow you to get rid of writing javascript and use java, c#, rust, c++ and many other to write frontend.
e.g you can develop parser in console application and then ship it to the browser and use it there to parse e.g code without changing a single line of code or having to do some bullshit or traspiling it to js.
Once it matures it will allow you to get rid of writing javascript and use java, c#, rust, c++ and many other to write frontend.
Basically, multithreaded adverts.
[deleted]
The main thing it can do that can’t be done with JS is not having to use JS.
More seriously, one of the main draws is being able to us the same language on both the front and back end, which might be beneficial to reduce the need to duplicate model or just to be able to develop on the front end in ones preferred language.
More seriously, one of the main draws is being able to us the same language on both the front and back end, which might be beneficial to reduce the need to duplicate model or just to be able to develop on the front end in ones preferred language.
Among other things, wasm has access to float32, int64 and vector types that JS does not. It also has operations like reinterpret_cast that you can't do in JS without a store/load pair using a scratch buffer.
JS does have BigInts though
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Parent referred to int64. BigInt and int64 are not the same thing.
JS doesn't have integers; all numbers are represented as doubles. One of the reasons having actual integers is important is performance, as integer operations are often faster than floating point operations. BigInt doesn't help with that.
JS doesn't have integers; all numbers are represented as doubles. One of the reasons having actual integers is important is performance, as integer operations are often faster than floating point operations. BigInt doesn't help with that.
My use case is having written a compiler/interpreter in rust wasm lets you easily set up a playground for the language.
It's purpose is not to replace JS, but to extend it. For example for the performamce critical parts of applications. It is already used in big JS libraries (such as Hyphenopoly, Google's Draco or Long.js) and in lots of custom applications like the Twitch.tv media player and many 3D visualizations.
One example is source maps.
I have a web app where every time there is an error on the client side it sends it back to the server. On normal JS it locks up the browser for 10+ seconds. In WASM it's instant.
Never found another use except for this.
I have a web app where every time there is an error on the client side it sends it back to the server. On normal JS it locks up the browser for 10+ seconds. In WASM it's instant.
Never found another use except for this.
>On normal JS it locks up the browser for 10+ seconds
Weird, I think I do the same thing (global exception catcher) and it works fine
Weird, I think I do the same thing (global exception catcher) and it works fine
> what is the use case for WebAssembly?
I think the core use case is "Being something that's not Javascript".
The desktop programming world gets benefit from having multiple languages that suit different use-cases, so why would the web not?
I think the core use case is "Being something that's not Javascript".
The desktop programming world gets benefit from having multiple languages that suit different use-cases, so why would the web not?
> what is the use case for WebAssembly?
Personally, it allows me to write tools that can run either on the command line or in the browser. Only the user-interface need be rewritten - internally both versions can share a lot of code.
WebAssembly makes it possible to do this using a language other than JavaScript. However, the languages I can use are still limited - AFAIK WebAssembly is currently only well-supported by C, C++ and Rust.
Personally, it allows me to write tools that can run either on the command line or in the browser. Only the user-interface need be rewritten - internally both versions can share a lot of code.
WebAssembly makes it possible to do this using a language other than JavaScript. However, the languages I can use are still limited - AFAIK WebAssembly is currently only well-supported by C, C++ and Rust.
> what is the use case for WebAssembly?
There is no access to the DOM and the POSIX-like WASI interface is limited so the main use case is reusing code with manual memory management (C, Rust, etc).
WebAssembly also targets server-side JavaScript runtimes like Node, Deno, and Cloudflare Workers.
There is no access to the DOM and the POSIX-like WASI interface is limited so the main use case is reusing code with manual memory management (C, Rust, etc).
WebAssembly also targets server-side JavaScript runtimes like Node, Deno, and Cloudflare Workers.
I saw that performance became more uniform with Rust/WASM. Not faster all over, but less slow in the worst cases.
At the very minimum you can reuse the code for input validation on the server side in the client. Given that those, if maintained separately, tend to diverge, in my experience, this is a net win.
Same questions, plus one more. Can anyone share a good resource that they have used to learn WebAssembly?
I used wasm for a computer vision related feature we built at work. It allowed us to reuse a bunch of things from opencv without having to reimplement those things in JS.
Where's the Rust Django? Is this false advertising?
Rocket still requires nightly. Rust folks should stop normalizing the use of nightly. Rust was "stabilized" almost 9 (edit 5,5 actually) years ago!
Do you have any idea why that is? I am pretty sure procedural macros in an expression context landed in stable 1 or 2 releases ago.
I believe they are waiting for releases of dependencies to not declare feature requirements. There's an issue linked in this subthread already for tracking it.
That is already done, and master builds on stable. They haven't cut a release yet because there's more they want in the release than just "whatever is on HEAD when we compile on stable."
Rocket's development process is quite slow, and they haven't but out a release since then.
Wasn't Rust "stabilized" with its 1.0 release in 2015?
Yes. But meta programming facilities aren't stabilized for obvious reasons (it ossifies the current implementation).
Most meta programming facilities are stabilized, most importantly procedural macros.
I'm not up to date with Rust tbh. Last time I checked Rocket used proc macros which were nightly only. But maybe there is some other issue.
Most procedural macros were stabilised in 2018, but some smaller features related to them were stabilised later. Rocket also used a ton of other nightly features beyond metaprogramming, which have either been stabilised by the compiler or replaced with stable solutions by Rocket.
I agree regarding the use of nightly Rust but fortunately it shouldn't be too long until a stable-compatible Rocket is released: https://github.com/SergioBenitez/Rocket/issues/19
Technically speaking, stable Rocket requires nightly Rust, but nightly (master) Rocket runs on stable Rust. The compiler has finally stabilised all the necessary features for Rocket 1.0, it's just up to Rocket to finish their next release.
As someone who has written quite a few lines in rust (rocket, specifically, while working on https://digester.app) I will agree that rust "is web", and yes, you can replace your Django.
But the development is experience and ecosystem is nowhere near (again, only speaking for rocket and I know a lot of work is being done to improve things) what you are used to from Django. For example, rocket's configuration system is quite limited (currently being reworked), poor cors support, limited test support, etc..
Again, not saying you can't do it, but it's not the same.
But the development is experience and ecosystem is nowhere near (again, only speaking for rocket and I know a lot of work is being done to improve things) what you are used to from Django. For example, rocket's configuration system is quite limited (currently being reworked), poor cors support, limited test support, etc..
Again, not saying you can't do it, but it's not the same.
Yeah it's a little disingenuous I think, there is basically nothing that matches the productiveness of Rails/Django when it comes to building webapps and without a clear reason why or strong community around it I'm not sure what the point would be. If you're building a CRUD app I don't think language performance is going to be the bottleneck. I think Rust looks awesome but as someone who uses multiple programming languages daily I feel like we're too often looking for one language that can do everything rather than just picking up the one that fits the problem area.
> there is basically nothing that matches the productiveness of Rails/Django when it comes to building webapps
That's a strong statement. Anyone care to back it up? I've never used Rails/Django.
That's a strong statement. Anyone care to back it up? I've never used Rails/Django.
I have used Rails professionally and I disagree with it. Personally I think Roda and Sinatra are more productive than Rails for most applications. Where Rails shines is the big plugin ecosystem, but many of those plugins are sadly not the great. And ignoring the plugin ecosystem Rails is pretty meh, not any worse or better than any of hundreds of frameworks out there. I would certainly not count it among the best ones.
i've been using django on-and-off since 2006 (0.95) and everything just works.
testing is well integrated, db access can be done through django's amazing ORM or, via raw sql.
you can get a fully functional REST API, with documentation, authentication, authorization, testing within a day's work (thanks django rest framework!).
also, there's so many django specific libraries out there, that if you need something (like, stripe support), you can just "pip install" it.
testing is well integrated, db access can be done through django's amazing ORM or, via raw sql.
you can get a fully functional REST API, with documentation, authentication, authorization, testing within a day's work (thanks django rest framework!).
also, there's so many django specific libraries out there, that if you need something (like, stripe support), you can just "pip install" it.
You can do all of those things with Node, PHP or Golang.
Do you really think it's possible to back it up? They're probably talking out of their ass and rarely used anything else.
Probably a bit too much hyperbole in my comment above you're right. But I've used a bunch of other languages and frameworks including the ones you mention in your other comment. My point was less about those specific tools and more about why try to do everything with one tool not Rails/Django fanboyism.
How about Phoenix? It's not quite there yet, but I think it's much closer than Rocket.
You might be surprised by just how slow and bloated a simple rails or Django app can be!
But the real benefit for me is reliability. With rust web apps, I feel a lot more confident that runtime errors have been properly handled. And of course you save some productivity because the type system means you don’t need to smother your code in unit tests like one normally does when they want to demonstrate their python or ruby code works.
But the real benefit for me is reliability. With rust web apps, I feel a lot more confident that runtime errors have been properly handled. And of course you save some productivity because the type system means you don’t need to smother your code in unit tests like one normally does when they want to demonstrate their python or ruby code works.
I love the fact that they have their own native implementations of clients for mysql, postgres and mongo.
In the Java world people just use jdbc and wrap it with a threadpool and expose it as "async", but in rust it is truly async down to the system call.
In the Java world people just use jdbc and wrap it with a threadpool and expose it as "async", but in rust it is truly async down to the system call.
There are several async drivers for Java, the most prominent probably https://vertx.io/docs/#data_access.
Go, Python, C# have native implementations as well, e.g. the de facto standard Postgres driver for Go (which is by the way super fast), https://github.com/JackC/pgx
Go, Python, C# have native implementations as well, e.g. the de facto standard Postgres driver for Go (which is by the way super fast), https://github.com/JackC/pgx
Orm, controllers, templates and routing is not nearly as complete as the rails stack and ecosystem. Same goes for Phoenix
Do you mean that Rust is not as complete as Phoenix, or that Phoenix is not as complete as Rails?
Is Rust marketable yet? Stackoverflow jobs (2020-10-30) that require:
Rust - 15/2462
C - 71/2462
Go - 105/2462
Kotlin - 109/2462
Typescript - 147/2462
C++ - 193/2462
C# - 221/2462
Java - 544/2462The only rust jobs I’ve seen so far are “crypto/blockchain”, but I’m just casually follow the development, anyone knows other niches adopting Rust?
embedded / iot / automotive, this currently stands on c ecosystem due to suppliers and billions of lines of legacy code
the failure of rust was it tried to start from scratch where better solution would be to seamlessly integrate into c,
maybe if gcc has support for compiling rust the future switchover on embedded would be easier
the failure of rust was it tried to start from scratch where better solution would be to seamlessly integrate into c,
maybe if gcc has support for compiling rust the future switchover on embedded would be easier
[deleted]
I've done some researching for Rust jobs in several European countries. It's basically everywhere well below 1% of all dev job offers.
It'll probably take a few more years still. I've started introducing rust into my "stack" at work for some new projects and I'm sure I'm not the only one in this situation, so when I decide to move to a different job there'll probably be one more Rust opening for somebody to take over.
The ecosystem needs to settle and stabilize a bit more before it reaches deep adoption in the industry as a whole. If you're a lean "disruptive" start up then you probably don't mind using more experimental technologies but big, established companies like to have a more long term vision. You don't want to have to rewrite half of your software 5 years from now because nobody uses FancyLang anymore.
The ecosystem needs to settle and stabilize a bit more before it reaches deep adoption in the industry as a whole. If you're a lean "disruptive" start up then you probably don't mind using more experimental technologies but big, established companies like to have a more long term vision. You don't want to have to rewrite half of your software 5 years from now because nobody uses FancyLang anymore.
Chicken and egg. Python wasn't marketable before 2005-ish, either. I hope you didn't bother learning that silly niche language.
Python was a top-10 language easily in 2005-ish. Nowadays Rust is only as half as popular as Go, a language that isnt even in the top 10. Rust will go the way of Scala, Haskell or Erlang, interesting but niche.
The exact year isn't really the point... Maybe it was 2000. The point is that Python existed all through the 90s and was not very popular for a long time. Rust has only been passed 1.0 for five years and it's already gotten a ton of attention, even from big players.
> The exact year isn't really the point..
So what's the point? Python was created in 1991, in 2000 was more popular than Rust is today. Rust was created in 2010, so it is older and in a world where it has to compete with more languages. Reality is different of what you wish to be true.
So what's the point? Python was created in 1991, in 2000 was more popular than Rust is today. Rust was created in 2010, so it is older and in a world where it has to compete with more languages. Reality is different of what you wish to be true.
Some dates for reference: Golang (2009), Rust (2010), Kotlin (2011), Typescript (2012)
[deleted]
[deleted]
I have been dabbling in Rust web development lately, coming from a Django/Flask background. I take issue with the article stating:
> Can I replace my Rails/Django/Flask already? Yup!
While I agree that you can try to replace Flask with Rust web frameworks, you can't do it for Rails or Django. Rust web frameworks do not let you easily test your application's database access layer nor provide advanced authorization, and lack other features that become necessary when your application becomes bigger.
If you don't need the performance that Rust provides, you should still go for Django or Rails. Otherwise you will end up reinventing them.
> Can I replace my Rails/Django/Flask already? Yup!
While I agree that you can try to replace Flask with Rust web frameworks, you can't do it for Rails or Django. Rust web frameworks do not let you easily test your application's database access layer nor provide advanced authorization, and lack other features that become necessary when your application becomes bigger.
If you don't need the performance that Rust provides, you should still go for Django or Rails. Otherwise you will end up reinventing them.
I am the author of the updated home page. Although the main content was provided by a previous maintainer of the website.
No one is saying that Rust dev will be as smooth as Django. In fact, there is another paragraph right below:
> While development might not be as smooth as something like Rails or Django, the Rust web development ecosystem and community is engaged and very helpful. A lot of work has been put into the web in the past few years, and we're getting there!
You can replace a Django app with Rust. While you might have to put in extra work to:
> test your application's database access layer
> provide advanced authorization
The main point that the author wanted to make is that Rust is suitable for scale web development. It might not be perfect, but we are getting there, and the ecosystem and community is very large, engaged, and helpful.
No one is saying that Rust dev will be as smooth as Django. In fact, there is another paragraph right below:
> While development might not be as smooth as something like Rails or Django, the Rust web development ecosystem and community is engaged and very helpful. A lot of work has been put into the web in the past few years, and we're getting there!
You can replace a Django app with Rust. While you might have to put in extra work to:
> test your application's database access layer
> provide advanced authorization
The main point that the author wanted to make is that Rust is suitable for scale web development. It might not be perfect, but we are getting there, and the ecosystem and community is very large, engaged, and helpful.
I would consider removing the reference to Django. Rust frameworks are great and make an excellent alternative to flask/sinatra/express, but they are nowhere close to as full-featured as Django/Rails/Laravel. Those frameworks are a whole other class of thing which I hope the Rust ecosystem will eventually aspire to, but it's not there yet.
I wish there were a Laravel for Rust. I've tried rocket/actix but laravel's ease to launch an app from cli, and organize code structure, configs, etc... makes life much easier. Go kind of has a few (Buffalo and Beego), waiting for a true MVC framework for rust.
I love Rust and I love the direction its pushing. But these kinds of websites are awful. If you can't get the nuances why Rails/Django/Many other frameworks are a better solution for writing a web server than I dunno what to tell you.
> But these kinds of websites are awful
Care to share why? It provides a lot of useful information and curated packages for common categories. It is actually widely used as a reference for package selection. Just because you disagree does not make it "awful"
Care to share why? It provides a lot of useful information and curated packages for common categories. It is actually widely used as a reference for package selection. Just because you disagree does not make it "awful"
It's awful because dishonesty is awful.
I'm enthusiastic about learning Rust myself, but it's not even remotely a replacement for Rails. Rails is, IMO, bar-none the fastest prototyping / solo dev tool for building CRUD apps that there has ever been. It made it possible to build a blog in under fifteen minutes in 2005. In 2020, it's even more productive and for an even wider variety of applications.
What Rust framework is even remotely similar?
I'm enthusiastic about learning Rust myself, but it's not even remotely a replacement for Rails. Rails is, IMO, bar-none the fastest prototyping / solo dev tool for building CRUD apps that there has ever been. It made it possible to build a blog in under fifteen minutes in 2005. In 2020, it's even more productive and for an even wider variety of applications.
What Rust framework is even remotely similar?
> Can I replace my Rails/Django/Flask already? Yup! Rust has mature and production ready frameworks
> If you can't get the nuances why Rails/Django/Many other frameworks are a better solution for writing a web server than I dunno what to tell you.
> If you can't get the nuances why Rails/Django/Many other frameworks are a better solution for writing a web server than I dunno what to tell you.
You can replace Rails with anything that's Turing complete right? We all know that. C, Assembly, Rust, anything can work.
I just don't see WHY.
If you're gonna say performance I'm gonna say who cares.
John Carmack once did [0].
[0] https://news.ycombinator.com/item?id=21907517
[0] https://news.ycombinator.com/item?id=21907517
Performance doesn't matter until it does. I've seen a malloc upgrade save millions of dollars.
Once you have millions of dollars in hosting costs, you can rewrite your app in rust. Most likely, though, your app is never going to cost more then $5 per month.
Another way of looking at it though is that by using a more efficient language and framework, you can grow farther on a single server, and that fundamentally simplifies things.
You should grow faster by focusing less on implementation and more on your core business competence. In old school PHP share-nothing architecture you can just throw more servers at it and call it a day until you need to start scaling databases.
But one misplaced comma and your whole site goes down.
I think you underestimate the costs of rewriting an app that has millions of dollars of hosting costs.
$5/month is a single teeny tiny EC2 instance (or if you’re on premise you can pretend that you’re saving money on hardware by ignoring maintenance costs). I think you’re exaggerating.
I'm not. Most projects are never going to see any significant traffic. In fact, most projects are never going to get finished and launched at all.
Depends what you're building I guess. Most Rails devs work on Cruddy / SAAS things like Basecamp where Rails is more than fine (or Django / PHP for that matter). If traffic is extreme caching can solve a lot of the problems.
Also, companies like Shopify/Github open source and merge to Rails much of their scaling solutions, it's not as if you start from scratch.
The reason for which I want to build my web stuff on Rust is safety. There are so many things that can go wrong on a server (especially on a server under attack) that I want to at least trust my language and framework.
Sadly, I have reached a stage at which there are very few languages I trust anymore to actually not explode in unpredictable manners when push comes to shove. Rust is one of them.
Sadly, I have reached a stage at which there are very few languages I trust anymore to actually not explode in unpredictable manners when push comes to shove. Rust is one of them.
> there are very few languages I trust anymore to actually not explode in unpredictable manners
Well, that's totally fine. To each his own. I push Ruby production code for 8 years now and I trust it.
Well, that's totally fine. To each his own. I push Ruby production code for 8 years now and I trust it.
Absolutely, to each their own.
You're going to hit a lot of other issues with a server before Rust's memory safety becomes a consideration. What's wrong with using Rails / Nginx behind a firewall?
It's not just memory safety. I've had so many misadventures with JavaScript (and I'm part of the team that writes the Firefox JavaScript VM, so I'm supposed to know better) or Python, for instance, that the simple idea of maintaining an application written in either language brings me down.
I fully realize that some people love these languages. I've written pretty sophisticated applications in these languages myself (including video games), and they're definitely great for exploring ideas. But at this stage of my career, for applications that matter to me, I value the time spent maintaining code more than the time spent writing it, and I find that the balance that works best for me is to use a strongly, statically-typed language such as Rust.
YMMV
I fully realize that some people love these languages. I've written pretty sophisticated applications in these languages myself (including video games), and they're definitely great for exploring ideas. But at this stage of my career, for applications that matter to me, I value the time spent maintaining code more than the time spent writing it, and I find that the balance that works best for me is to use a strongly, statically-typed language such as Rust.
YMMV
Can you give some concrete examples of where rust is beneficial? Is it just the static typing? Why not use something like Java, C# or even Haskell if so?
First, I want to clarify that I'm not advocating Rust for all use cases. It just happens so that Rust is pretty well matched for the kind of things I generally need.
Now, Haskell or (modern) Java or C# are good languages, too, and they're by far not the only ones.
If you wish examples of the kind of features I need:
1. I pretty systematically need to juggle with many threads; 2. I very often need to juggle with many processes, with non-trivial interactions (i.e. actual protocols); 3. I very often need to access the OS; 4. I pretty systematically need to juggle with sophisticated data structures and algorithms (think graph matching algorithms, or dynamic trees of dependencies between ongoing tasks); 5. I regularly need to handle distributed applications in which pieces interact through non-trivial protocols; 6. I pretty systematically need to ensure that the event loop remains responsive. 7. Whenever I interact with the rest of the world (either the OS or as a web client or server), I want to be sure of which piece of data is sanitized and which isn't.
Of course, every single of these task can be achieved in any language. It just happens so that:
1. Rust has the best support for threads that I know in an industrial language. 2. and 5. Rust's type system is the best I know to express protocols among industrial languages. I hear that Ada's type system is just as good, but I don't know Ada, so I cannot compare. I hear that Haskell's type system is currently being extended with linear types, so I'll need to test-drive that, too. 3. While there are other languages that are at similar level as Rust for such things, I don't know anyone that is strictly better. 4. and 7. Any language with a strong, static type system is good here, including Rust and all your examples. 6. Great support for coroutines is really useful. Many languages have it these days, including Rust.
Once again, to clarify, I'm not trying to convince everyone to switch to Rust. I'm just answering the assertion that the only reason to use Rust is performance. That's certainly not the case for me.
Now, Haskell or (modern) Java or C# are good languages, too, and they're by far not the only ones.
If you wish examples of the kind of features I need:
1. I pretty systematically need to juggle with many threads; 2. I very often need to juggle with many processes, with non-trivial interactions (i.e. actual protocols); 3. I very often need to access the OS; 4. I pretty systematically need to juggle with sophisticated data structures and algorithms (think graph matching algorithms, or dynamic trees of dependencies between ongoing tasks); 5. I regularly need to handle distributed applications in which pieces interact through non-trivial protocols; 6. I pretty systematically need to ensure that the event loop remains responsive. 7. Whenever I interact with the rest of the world (either the OS or as a web client or server), I want to be sure of which piece of data is sanitized and which isn't.
Of course, every single of these task can be achieved in any language. It just happens so that:
1. Rust has the best support for threads that I know in an industrial language. 2. and 5. Rust's type system is the best I know to express protocols among industrial languages. I hear that Ada's type system is just as good, but I don't know Ada, so I cannot compare. I hear that Haskell's type system is currently being extended with linear types, so I'll need to test-drive that, too. 3. While there are other languages that are at similar level as Rust for such things, I don't know anyone that is strictly better. 4. and 7. Any language with a strong, static type system is good here, including Rust and all your examples. 6. Great support for coroutines is really useful. Many languages have it these days, including Rust.
Once again, to clarify, I'm not trying to convince everyone to switch to Rust. I'm just answering the assertion that the only reason to use Rust is performance. That's certainly not the case for me.
Not the OP, but: Haskell's type system is great, and you can write a lot of functionality in not much code. It might be hard to find many developers who will feel confident picking it up. C# maybe, it's quite mature, and has the benefit of interop with F#. But both C# and Java suffer from the greatest indignity to programmers: null.
C# has non nullable reference types since C#8 which is a step in the right direction.
https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...
https://devblogs.microsoft.com/dotnet/embracing-nullable-ref...
safety isn't "security safety", the things a firewall protect you from can also be an issue with rust.
It's much more a safety that you do not crash, due to input, side effects, parallelism (locking) errors, mapping wrong types, derefercencing null in some edge case by accident, ...
Rust gives you a lot of guarantees here, that it is extremely fast is just the cherry on top.
It's much more a safety that you do not crash, due to input, side effects, parallelism (locking) errors, mapping wrong types, derefercencing null in some edge case by accident, ...
Rust gives you a lot of guarantees here, that it is extremely fast is just the cherry on top.
I didn't say it was security safety. What I'm saying that if you're running a web server, the problems that you face will most likely come from how you programmed and set up the server rather than which language you chose.
I'm pretty sure that "which language you chose" can have a huge impact on "how you programmed [...] the server".
What has a firewall to do with anything?
>The reason for which I want to build my web stuff on Rust is safety.
Any GC language (Java e.g.) will give you that if you don't use C extensions.
And if you do use them Rust wont fair any better (or if you use libraries that use unsafe).
Any GC language (Java e.g.) will give you that if you don't use C extensions.
And if you do use them Rust wont fair any better (or if you use libraries that use unsafe).
Any GC language will help, indeed. But there is much, much more to safety than deallocating memory.
>Any GC language will help, indeed. But there is much, much more to safety than deallocating memory.
Yes, but that's the main allure of Rust. As for the rest (e.g. resource releasing, avoiding concurency issues, avoding not-exhastive mathces, injection, etc.), other languages have their own ways as well, including Java.
If those are your main concerns (and not also top-speed) I don't think Rust is worth the extra cost (learning slope, slow compilation times, single implementation, fewer libs and developer tools, etc).
Yes, but that's the main allure of Rust. As for the rest (e.g. resource releasing, avoiding concurency issues, avoding not-exhastive mathces, injection, etc.), other languages have their own ways as well, including Java.
If those are your main concerns (and not also top-speed) I don't think Rust is worth the extra cost (learning slope, slow compilation times, single implementation, fewer libs and developer tools, etc).
> Yes, but that's the main allure of Rust.
Not really. That's often touted as the banner feature, but it's the expressive type system that really makes Rust a better candidate than, for instance, Java.
Not really. That's often touted as the banner feature, but it's the expressive type system that really makes Rust a better candidate than, for instance, Java.
You can use Scala 3 which is even more powerful than Rust and you get all the benefits + extra sauce.
Note that I'm not dissing other languages. Each language has their pros and cons. It just happens so that Rust is my current sweet spot for the kind of applications I currently need to write.
My main point in this particular discussion is that Rust has way fewer gotchas than most other languages used in the industry, including Python and JavaScript. Whether these gotchas are problems for your use cases, only you know. I know that such sleepless nights tracking such gotchas have killed my will to write and maintain large codebases in Python or JavaScript (or C++), at least for a few years.
My main point in this particular discussion is that Rust has way fewer gotchas than most other languages used in the industry, including Python and JavaScript. Whether these gotchas are problems for your use cases, only you know. I know that such sleepless nights tracking such gotchas have killed my will to write and maintain large codebases in Python or JavaScript (or C++), at least for a few years.
This sort of extremist view is typical of rust proponents and is also why rust has a bad reputation. Java, Go, C# are all extremely safe and performant languages.
You're likely to lose safety implementing a vanilla CRUD app in Rust instead of Django. Rust is mostly buying you memory safety; the rest of its safety features are helpful when building new kinds of applications, but Django CRUD applications follow a well-worn pattern, and the Django developers have done really good work making sure that those patterns are easy to implement securely (usually by default).
Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you. There aren't really Rust features that directly prevent SSRF attacks, or HTTP desync. In fact, my experience assessing Rust (and Go) web applications is that they intend to reincarnate web vulnerabilities that went mostly extinct in Django applications years ago; for instance, I'm virtually never going to find SQLI in a Django application, but Rust web applications are somewhat likely to build their own SQL queries. This will shock and upset some Rust developers to hear (all the popular Rust SQL interfaces force parameterized queries! they're thinking), but it's true.
I like Rust, and write more Rust than any other language lately. I'd say the same thing about practically any modern language compared to boring old Django, which is the Volvo of web frameworks.
I have nothing much to say about reliability and do recognize that writing in Python or Ruby means that you're also writing ridiculous batteries of unit tests to verify basic things like whether your setters and getters work properly, because the language essentially makes you check your own typos. I'm only talking about security.
Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you. There aren't really Rust features that directly prevent SSRF attacks, or HTTP desync. In fact, my experience assessing Rust (and Go) web applications is that they intend to reincarnate web vulnerabilities that went mostly extinct in Django applications years ago; for instance, I'm virtually never going to find SQLI in a Django application, but Rust web applications are somewhat likely to build their own SQL queries. This will shock and upset some Rust developers to hear (all the popular Rust SQL interfaces force parameterized queries! they're thinking), but it's true.
I like Rust, and write more Rust than any other language lately. I'd say the same thing about practically any modern language compared to boring old Django, which is the Volvo of web frameworks.
I have nothing much to say about reliability and do recognize that writing in Python or Ruby means that you're also writing ridiculous batteries of unit tests to verify basic things like whether your setters and getters work properly, because the language essentially makes you check your own typos. I'm only talking about security.
I'm ok with that, I'm not writing CRUD :)
Note that I'm not claiming that Rust is the solution to every problem under the sun. It just happens to be pretty much the sweet spot for problems I need to solve, which typically involve concurrency and/or distribution and/or new protocols and/or sophisticated graph algorithms and/or actual OS access.
Note that I'm not claiming that Rust is the solution to every problem under the sun. It just happens to be pretty much the sweet spot for problems I need to solve, which typically involve concurrency and/or distribution and/or new protocols and/or sophisticated graph algorithms and/or actual OS access.
Rust is great. It's just really hard to outdo Django for the kinds of apps Django was designed for.
This may be the first time I've ever disagreed with a comment you've made, but here we go!
> Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you.
There absolutely is. Rust's expressive type system is a more important feature than the memory-safety guarantees for general purpose programming. This has significant impact on the ability to express security constructs directly in the code. Witness, for instance, the widespread use of typing to distinguish unvalidated and validated user inputs, such as Rocket's RawStr type [0].
Applying that technique can mitigate SSRF attacks without even knowing the details. You can worry all you like about SQLI in Rust, but in the code I've seen it's no more a concern than any web app, and likewise it can be enforced in the type system in a way that sure seems superior to "hope the dev only writes boring Python".
I'd agree with the general premise that, all things being equal, the security of something that looks exactly like everything else is higher than some novel construct. But I strongly disagree that there's nothing a language can do to help developers write secure applications, and I'd suggest it starts with an expressive type system.
[0]: https://api.rocket.rs/v0.4/rocket/http/struct.RawStr.html
> Meanwhile, safety in a web application is domain-specific, and there isn't much a language can do to protect you.
There absolutely is. Rust's expressive type system is a more important feature than the memory-safety guarantees for general purpose programming. This has significant impact on the ability to express security constructs directly in the code. Witness, for instance, the widespread use of typing to distinguish unvalidated and validated user inputs, such as Rocket's RawStr type [0].
Applying that technique can mitigate SSRF attacks without even knowing the details. You can worry all you like about SQLI in Rust, but in the code I've seen it's no more a concern than any web app, and likewise it can be enforced in the type system in a way that sure seems superior to "hope the dev only writes boring Python".
I'd agree with the general premise that, all things being equal, the security of something that looks exactly like everything else is higher than some novel construct. But I strongly disagree that there's nothing a language can do to help developers write secure applications, and I'd suggest it starts with an expressive type system.
[0]: https://api.rocket.rs/v0.4/rocket/http/struct.RawStr.html
I think the idea of somehow using types to express safe vs. unsafe URLs is much less compelling as an SSRF mitigation than using client certificates or proxies to rule them out, which is what shops that are serious about SSRF already do. Meanwhile: I think if you go looking at Rust web applications, you're going to find that they in fact do nothing like this at all --- they're not using magic types as an SSRF mitigation.
Similarly: it's not at all my claim that Rust is somehow more susceptible as a language to SQLI attacks! The opposite thing is true: Rust, as a language, is far better situated to deal with them, because of expressive typing. But that's what could be, not what is. In practice, ironic or not, if you implement the same CRUD application in circa-2020 Rust and in Django, the Rust application is more likely to have SQLI.
The point is that unlike kernel code or browser components, where memory safety is most of the ballgame and Rust is a real game-changer, web application security is domain-specific. The language and its runtime are much less important to web security than what gets built on top of the language. And right now, even though Python is an objectively inferior language, more of the domain of web security is built more carefully on Django than what's available on Rust.
Similarly: it's not at all my claim that Rust is somehow more susceptible as a language to SQLI attacks! The opposite thing is true: Rust, as a language, is far better situated to deal with them, because of expressive typing. But that's what could be, not what is. In practice, ironic or not, if you implement the same CRUD application in circa-2020 Rust and in Django, the Rust application is more likely to have SQLI.
The point is that unlike kernel code or browser components, where memory safety is most of the ballgame and Rust is a real game-changer, web application security is domain-specific. The language and its runtime are much less important to web security than what gets built on top of the language. And right now, even though Python is an objectively inferior language, more of the domain of web security is built more carefully on Django than what's available on Rust.
If the question is simply, how can you maximize security of a CRUD app project you're starting in 2020, the answer is probably to build it on Django.
As to your points about what patterns are more likely in actual practice, I can't speak to that; I've only seen a handful of Rust web apps. But the ones I've seen absolutely do use type-foo to keep things straight.
> The language and its runtime are much less important to web security than what gets built on top of the language.
That's a great point. I would highlight, though, that what gets built (and how likely it is to have bugs, which is also pertinent!) is directly impacted by the language and runtime, so the two questions can't be neatly separated.
In the long run, will most users be writing the guts of, say, a session manager to support their CRUD app? No, of course not, they'll just reach for some shared resource. Is it easier to be confident that the Rust implementation of that library has a lower incidence of bugs? Today, no, because for the Django version you can rely on the major real-world use as evidence of reliability, but in the long run, almost certainly. Is it easier to be confident that the usage of the Rust version of the library is correct? Absolutely, since the invariants can be enforced by the compiler.
As to your points about what patterns are more likely in actual practice, I can't speak to that; I've only seen a handful of Rust web apps. But the ones I've seen absolutely do use type-foo to keep things straight.
> The language and its runtime are much less important to web security than what gets built on top of the language.
That's a great point. I would highlight, though, that what gets built (and how likely it is to have bugs, which is also pertinent!) is directly impacted by the language and runtime, so the two questions can't be neatly separated.
In the long run, will most users be writing the guts of, say, a session manager to support their CRUD app? No, of course not, they'll just reach for some shared resource. Is it easier to be confident that the Rust implementation of that library has a lower incidence of bugs? Today, no, because for the Django version you can rely on the major real-world use as evidence of reliability, but in the long run, almost certainly. Is it easier to be confident that the usage of the Rust version of the library is correct? Absolutely, since the invariants can be enforced by the compiler.
The session manager thing is a great example of what I'm talking about. A completely custom session manager in a Django app would be shocking. In a Rust app? Not so much.
I think we're mostly on the same page here.
I think we're mostly on the same page here.
If you care about web safety, there are a billion other things that can bite you that are not memory safety. Rust by itself will not protect you from an sql injection, timing attacks, rainbow attacks, poorly configured TLS, Unix path drilling. You might have coded an infinite loop that "zero-cost abstractions" has turned into a cpu hog so that a single malicious user can use to DDOS a node. Did you build in the ability to failover across nodes? Or will all of the tenants of that node get nuked when kubernetes misses it's health check and nukes it?
So if you actually care about these things, rust might be really poor, because you are spending time fighting the borrow checker instead of thinking about the security surface area of your system, and the language is optimizing for speed in a domain where the bottleneck is usually the network.
So if you actually care about these things, rust might be really poor, because you are spending time fighting the borrow checker instead of thinking about the security surface area of your system, and the language is optimizing for speed in a domain where the bottleneck is usually the network.
at work we care about web performance a lot, because we have a huge amount of traffic. so you could say anyone whobmanages a great deal of success may care about performance. yes you can scale wide but complexity and costs grow as you do. as well, there are plenty of non python/ruby web backends that offer way more performance without the productivity downsides of rust and c++
Site speed has a pretty big impact on e.g. conversion rates.
> If you're gonna say performance I'm gonna say who cares.
Whoever pays the electricity bill?
Whoever pays the electricity bill?
I agree. It will take some time until we have a Rust framework that is as robust and feature-rich as Django or Rails.
Rails was released 16 years ago (according to wikipedia). Rocket just got the first release that builds on stable rust. Thus: Give it 15 years, we'll be there!
I used Django from pretty much it's first public release and it was broadly feature complete back then.
The ecosystem between then and now is night and day, though, and that's an extremely important part of a framework.
In case of Django, I actually don’t feel much difference in this regard—it’s always been very much batteries included. It is natural for a project to have no dependencies but Django (and maybe psycopg2 bindings), business domain-specific dependencies excluded. Happily used it since before the first major release.
It had been in production use for a while prior to its public release, yeah?
IIRC, it was (like Rails) extracted from an existing web application.
Yes. I believe it was spun out of an internal project at Lawrence Journal-World.
> Rocket just got the first release that builds on stable rust.
As far as I can tell, Rocket is still on 0.4.5.
As far as I can tell, Rocket is still on 0.4.5.
Your comment and the comment you are replying to are both correct.
Rocket's current released version is 0.4.5, and that version builds with a stable Rust toolchain.
Rocket's current released version is 0.4.5, and that version builds with a stable Rust toolchain.
It looks to me like 0.4.5 still requires nightly:
error: failed to run custom build command for `rocket_codegen v0.4.5`
Caused by:
process didn't exit successfully: `/home/vlad/code/test-rocket/target/debug/build/rocket_codegen-f5b5d853ac3ddd89/build-script-build` (exit code: 101)
--- stderr
Error: Rocket (codegen) requires a 'dev' or 'nightly' version of rustc.
Installed version: 1.47.0 (2020-10-07)
Minimum required: 1.33.0-nightly (2019-01-13)
Indeed. Apparently the support for stable Rust was merged onto master months ago, but there hasn't been a release since then. 0.5 should be the first version that builds on stable Rust according to this thread: https://github.com/SergioBenitez/Rocket/issues/19
You can use 0.5.0-dev if you want stable rust.
I want to caveat this by first saying I’m a fan of Rust in general, but does one not see the irony in the article’s claim to the effect “yes, it’s ready as a Rails replacement”, yet requires you to use an unreleased dev version of a library to even build from a stable release of the language?
Yeah, and I don't know how anyone could claim its a Rails replacement. Diesel, warp, rocket et al are great but the DX and feature completeness aren't there yet.
That said, with Cargo using the unreleased version is as simple as changing `rocket = "0.4.5"` to `rocket = { git = "https://github.com/SergioBenitez/Rocket" }` so it's not like you even have to clone it manually. You can even specify branches if you urgently need a PR and patch entire workspaces with forked versions and so on.
That said, with Cargo using the unreleased version is as simple as changing `rocket = "0.4.5"` to `rocket = { git = "https://github.com/SergioBenitez/Rocket" }` so it's not like you even have to clone it manually. You can even specify branches if you urgently need a PR and patch entire workspaces with forked versions and so on.
Even if performance matter Go should be a better choice.
Go's performance is very close to rust in Web ecosystem and is very mature.
Or C# with ASP.NET Core which is much closer to rust in performance.
> Or C# with ASP.NET Core which is much closer to rust in performance.
I haven't noticed that C# is faster than Go, or that it's as fast as Rust/C++. Except in selected micro-benchmarks, of course.
C# is at best in the same bracket as Go: https://www.techempower.com/benchmarks/#section=data-r19&hw=...
I haven't noticed that C# is faster than Go, or that it's as fast as Rust/C++. Except in selected micro-benchmarks, of course.
C# is at best in the same bracket as Go: https://www.techempower.com/benchmarks/#section=data-r19&hw=...
The fastest .Net based library scores a 58%, while a framework based on Go scores 52%. The weights are arbitrary, so can't infer a lot from the 6% delta between .Net and Go - except that they compare favorably with each other in terms of performance.
The fastest .NET library is ASP.NET Core, which is a standard, mature, off the shelf framework.
Compared to the golang version using fasthttp, which is non-standard and makes compromises to achieve speed, and I'd avoid it for production.
Compared to the golang version using fasthttp, which is non-standard and makes compromises to achieve speed, and I'd avoid it for production.
In my experience ASP.NET and its frameworks are potentially much slower than raw C#. As much as C# is supposed to be a fast language, whenever I run into a C# web app it seems to be inexplicably slow.
I'm not sure why anyone would be downvoting your data point. I am pretty bothered at how much emphasis folks throw behind the TechEmpower benchmarks. If you really dig into the implementations for the top languages, it's easy to see how far from the real world, those apps are. In the case of C#/ASP.NET, as soon as you add EntityFramework (or Dapper, if that's your thing) and some real-world querying of a database. You're looking at a pretty big slow-down. I'm certain things can be done to speed it up though.
Is that free in any way?
The C# compiler roslyn, the dotnet runtime (Jit compiler, ...), and ASP NET Core are all MIT or Apache licensed and run officially supported on mac os, linux and windows.
It's free in all the ways
C# or ASP.NET Core never costed anything. The cost is in certain versions of Visual Studio, but that is not required. Besides Visual Studio, Visual Studio Code is popular too.
I can recommend Jetbrains Rider [1] for anything C#. I prefer it over Visual Studio even.
[1]: https://www.jetbrains.com/rider/
[1]: https://www.jetbrains.com/rider/
Is it also free to deploy? Can you deploy it on Linux?
Yes. It is also fairly straightforward to dockerize dotnet core apps[0].
[0] https://docs.docker.com/engine/examples/dotnetcore/
[0] https://docs.docker.com/engine/examples/dotnetcore/
That’s just not true. More mature, sure. But the language experience couldn’t be more different between the two, and that counts. I don’t wanna be wasting my time with quirkiness.
I like Rust and everything, but pretending it’s going to get the job done faster than Go is just that—pretending. If you don’t like Go’s developer experience, then fine (and understandable when the alternative is Rust), but it’s not wasting time IMO.
Writing a for loop every time you need to iterate over a collection is wasting time.
Have you tried https://github.com/elliotchance/pie
My ratio of writing to debugging has never been such that the difference between for and forEach ever mattered.
That being said, debugging complex go code bases 5 years ago (when I last was doing this daily) was less fun than other languages (their armory stocks a nice assortment of footguns and the debugging support was... minimal. Might have changed since then.)
I think he's referring to the "functional" stye APIs which let you write code that looks a lot like operating on java collections with streams. It's actually pretty great, I definitely miss it in other languages.
Did Delve exist 5 years ago? I find Delve to provide a great debugging experience for Go applications. Might be worth checking out if anyone found concern with that comment.
The first tagged release on Delve's GitHub is from 2014, but I have no idea if it was public at the time or not.
Is it possible that there are other factors that could take even more time than writing a little boilerplate? Maybe dueling with the borrow checker?
It's a tradeoff. I'd rather duel with the borrow checker a little bit every day then have a long debugging session figuring out where's a missing copy causing values taken from a map to be not available - that is a fun multi-hour challenge sometimes.
That’s perfectly reasonable if you’re writing lots of parallel code, but frankly 95% of web server code isn’t the sort of hairy parallel code that would benefit from a borrow checker on balance.
There are no threads in this scenario. You can easily lose ownership / crash on bad references when using golang maps in a single thread.
How do you get "bad references" in a Go map in a single thread? Are you thinking of nil pointers? That's a separate issue.
It’s not pretending. In fact, web application hosts are a great candidate for replacement with faster languages because it can have an immediate impact on infra costs.
Reducing infra costs are rarely the largest opportunity for an organization, and even then the majority of infra waste is typically unrelated to language. Moreover, trading iteration velocity (and/or rewriting your application) for some marginal infra cost improvement is not a very good approach.
[deleted]
[deleted]
> Rust web frameworks do not let you easily test your application's database access layer nor provide advanced authorization
Can you expand on this comment a bit? I find testing in Rust to be fantastic. Rocket makes for calling test functions simply via standard rust in tests, though you’ll need to build some test harness boot strap for your DB, but you generally end up doing that in any language for functional/end-to-end tests.
Can you expand on this comment a bit? I find testing in Rust to be fantastic. Rocket makes for calling test functions simply via standard rust in tests, though you’ll need to build some test harness boot strap for your DB, but you generally end up doing that in any language for functional/end-to-end tests.
I think this probably covers it:
> you’ll need to build some test harness boot strap for your DB
From what I've seen, it's totally possible to use Rust for web development. However, there are tons of web frameworks in various languages that provide way more out of the box than you can find in Rust. These frameworks have had tons of time to mature - Ruby on Rails is 16 years old, Django is 15 years old, Laravel is 9 years old, and so on.
I think (and hope) Rust will get there eventually, but I think it'll take some time. There's a lot of hype, but speaking as a web developer who's interested in Rust I think there will need to be a lot more tooling and a lot of educational content before it gains any significant market share. I got my start with C/C++ before I ever touched web stuff, but I never got too far into advanced language features. That combined with not having written a serious C program in years makes Rust something I'd really have to commit to learning, so even though I'd love to have a faster better-typed alternative to PHP I won't be writing any actual webapps in Rust in the near term.
Basically, I think most of the people writing webapps in Rust will be Rust people interested in the web rather than web people interested in Rust for a while. There are of course organizations that do more complex stuff on the web and will jump on this sooner, especially places that use microservices and don't have to move their whole platform over, but many people building simpler sites with smaller teams will wait until there's a substantially larger ecosystem.
From what I've seen, it's totally possible to use Rust for web development. However, there are tons of web frameworks in various languages that provide way more out of the box than you can find in Rust. These frameworks have had tons of time to mature - Ruby on Rails is 16 years old, Django is 15 years old, Laravel is 9 years old, and so on.
I think (and hope) Rust will get there eventually, but I think it'll take some time. There's a lot of hype, but speaking as a web developer who's interested in Rust I think there will need to be a lot more tooling and a lot of educational content before it gains any significant market share. I got my start with C/C++ before I ever touched web stuff, but I never got too far into advanced language features. That combined with not having written a serious C program in years makes Rust something I'd really have to commit to learning, so even though I'd love to have a faster better-typed alternative to PHP I won't be writing any actual webapps in Rust in the near term.
Basically, I think most of the people writing webapps in Rust will be Rust people interested in the web rather than web people interested in Rust for a while. There are of course organizations that do more complex stuff on the web and will jump on this sooner, especially places that use microservices and don't have to move their whole platform over, but many people building simpler sites with smaller teams will wait until there's a substantially larger ecosystem.
> you’ll need to build some test harness boot strap for your DB
You kinda answered your own question here. Rails and Django have built in support for end-to-end and functional tests, including database access in the same way as the normal app, all autogenerated. That is just table stakes for web frameworks these days.
You kinda answered your own question here. Rails and Django have built in support for end-to-end and functional tests, including database access in the same way as the normal app, all autogenerated. That is just table stakes for web frameworks these days.
I’m not super familiar with Django, but don’t you still have to run all your db upgrade scripts, etc? Does the Django framework handle that for you?
Django implicitly generates migrations from your class structure. It's a choice, but it works very well up to a point that 90% of simple web apps will never get to.
thomaslord and WJW did a great job saying what I would have said. Django already provides you the harness, and when you try to implement it yourself you will run into some gnarly technical problems. How do you make sure one test's database changes are not seen by a different test? Are you going to run tests sequentially and reset the DB before every single one? Or are you going to try to wrap your requests in a transaction that can be rolled back afterwards? Any approach you take, you are reinventing what Django already does.
As someone that’s maintained an E2E test harness in PHP including internal dispatching, having multiple DBs active in a test suite, having multiple active sites running and communicating with each other, handling integration tests to Elastic, Sphinx, and Memcached, I really don’t think it’s such a big deal to spend a day or 2 plumbing out your test harness for a “big” app.
A big app takes years of work, and along the way you be building utility functions to easily stand up test data. It’s not that hard and you don’t need it all at once.
A big app takes years of work, and along the way you be building utility functions to easily stand up test data. It’s not that hard and you don’t need it all at once.
That's an interesting take. My experience has been mainly with small to medium sized applications, and I just have not wanted to expend the resources to maintain a custom test harness.
Wouldn't rust fail for the same reason there is no c++ framework that cna take on django? Rust is a pretty complex framework.
But is it web scale? ;)
It has joins, so no ;)
Title needs to be updated.
Rust has been "web ready" for some time. C++ is "web ready", too.
But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems. And those alternatives offer much higher productivity and a much larger talent pool.
Rust is not even the fastest web framework (https://www.techempower.com/benchmarks/) . And the benefit over Java, C# or Go is really negligible. Who needs more than 300000 req/s and can't afford servers to scale?
So, another nice try from the Rust evangelists, but no thanks.
But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems. And those alternatives offer much higher productivity and a much larger talent pool.
Rust is not even the fastest web framework (https://www.techempower.com/benchmarks/) . And the benefit over Java, C# or Go is really negligible. Who needs more than 300000 req/s and can't afford servers to scale?
So, another nice try from the Rust evangelists, but no thanks.
Many people use Node.js and Javascript because they get to use one language on both server and web browser. Rust can probably do the same in future. Rust on server, Rust with WASM on web browsers and then Rust for local software.
Right, so you're saying we can take rust web backend seriously once Rust is popular in front ends? Cool, I agree, but that's just never going to happen.
Why should we do anything new? I've been seeing this attitude more and more where developers think they're entitled to be convinced to use some new technology as though their time and attention are so valuable it's someone else's responsibility to convince them to spend it.
What I think differentiates this from normal outreach and education that every project needs to do to build a community is the sense of entitlement and the declaration that they're outright hostile and argumentative and then expect to be engaged.
What I think differentiates this from normal outreach and education that every project needs to do to build a community is the sense of entitlement and the declaration that they're outright hostile and argumentative and then expect to be engaged.
> Why should we do anything new?
I think a problem exists when that something new is being pushed and hyped in order to create a self-fulfilling prophecy where everybody starts jumping on the bandwagon and an ecosystem is built.
I think a problem exists when that something new is being pushed and hyped in order to create a self-fulfilling prophecy where everybody starts jumping on the bandwagon and an ecosystem is built.
Seems like a natural defensive mechanism against the hype train, which is real and various industries make their living from churn. Because of the bias of vested interests many new things that are pushed are not really in the developers interest. Some are, and some are worth the effort, but many aren't and how do you know which without expending your limited resource of attention?
> Why should we do anything new?
From a management positions this is probably the most important question you can ask. Your most expensive resource is your programmers, and a few talented operations guys, and you need a good reason to expend those resources.
We work rather closely with other municipalities, and one in particular is very adoptive of new things. One of the things they adopted was kubernetes. But the thing is, we’re not Netflix, and kubernetes isn’t easy, and the result was they spend two years worth of man hours on something that didn’t make them anymore competitive than us because the advantages never really comes into play in our small enterprise organisations.
We spent those two years worth of manhours improving our Azure strategy, getting our operations guys up to speed on powershell and our developers on python, and actually moved our organisation forward in a manner that was useful.
Maybe Rust is useful, maybe it’s going to have a brighter web-future than .Net Core, but if you can’t show me how that is, or why I should adopt it, then it’s a really big risk that I’m happy to let other people take. We can always adopt it later.
Of course you probably meant to ask the question in a different light, and I think that point is very valid. I just can’t stress enough, how little something being all the hype actually means. What if Rust turns out to be another Ruby on Rails or “Node.JS for everything” craze? Then I won’t lose any sleep over never having thouched it, and if you look at our local job market, then there hasn’t been a single Rust focused job in my entire country for two years now. Not even as a “nice if also you know” listing. That doesn’t exactly install me with confidence that Rust is ever going to be important.
From a management positions this is probably the most important question you can ask. Your most expensive resource is your programmers, and a few talented operations guys, and you need a good reason to expend those resources.
We work rather closely with other municipalities, and one in particular is very adoptive of new things. One of the things they adopted was kubernetes. But the thing is, we’re not Netflix, and kubernetes isn’t easy, and the result was they spend two years worth of man hours on something that didn’t make them anymore competitive than us because the advantages never really comes into play in our small enterprise organisations.
We spent those two years worth of manhours improving our Azure strategy, getting our operations guys up to speed on powershell and our developers on python, and actually moved our organisation forward in a manner that was useful.
Maybe Rust is useful, maybe it’s going to have a brighter web-future than .Net Core, but if you can’t show me how that is, or why I should adopt it, then it’s a really big risk that I’m happy to let other people take. We can always adopt it later.
Of course you probably meant to ask the question in a different light, and I think that point is very valid. I just can’t stress enough, how little something being all the hype actually means. What if Rust turns out to be another Ruby on Rails or “Node.JS for everything” craze? Then I won’t lose any sleep over never having thouched it, and if you look at our local job market, then there hasn’t been a single Rust focused job in my entire country for two years now. Not even as a “nice if also you know” listing. That doesn’t exactly install me with confidence that Rust is ever going to be important.
You're in a position right now where you probably ought to continue using Python. It's a great tool for many jobs, the community is super helpful and very capable, and the ecosystem is tremendous. Tech decisions are hard to make and managers try to choose carefully. It sounds like your team already bought into some of the costly hype by adopting Kubernetes (and probably microservices). It takes restraint not to go further and rewrite everything in Rust.
It's been a while since microservices became a big deal, so the tech industry may be due for a cost-cutting correction where projects consolidate a constellation of microservices to efficient monolithic systems written in systems languages such as Rust or Go and use leaner hosting solutions. You can adopt Rust then, maybe.
> But why should one choose Rust when there're plenty of alternatives with much larger and much more stable ecosystems.
In my experience, and this is just a data point: because it is much simpler to write correct Rust code and to refactor large Rust code bases correctly than doing the same for Javascript, Ruby, Python, C++, C, Java, etc.
That Rust has great perf and uses little resources is just a bonus, but not something that most apps will care much about.
The downsides you mention about the ecosystem, libraries, frameworks, are real.
I disagree with your claim that there is no "talent pool" for Rust. The "talent pool" for javascript or C++ is _only_ "all javascript experts" or "all C++ experts" because if you are not very good at Javascript or C++, you can't really be trusted. A Javascript programmer can start being productive in Rust without issues quickly, but the same wouldn't be true if they had to program in C++ instead.
The "talent pool" for Rust is "all programmers with domain knowledge". If they are not experts in Rust, that doesn't matter. Smart people you want to hire all pick up Rust very quickly, and the amount of dangerous mistakes anyone can make by not being a Rust expert is very small.
Offer/demand wise, the demand for Rust jobs is much higher than the Rust jobs that are currently available. If you post a Rust job on reddit you'll get 100 CVs in a day...
---
IMO, your main point still holds: right now Rust web frameworks are not as feature full as Django, Rails, etc. and if Rust frameworks are missing features you need, picking it up for a professional project probably doesn't make sense. Unless... you are willing to implement those features yourself...
In my experience, and this is just a data point: because it is much simpler to write correct Rust code and to refactor large Rust code bases correctly than doing the same for Javascript, Ruby, Python, C++, C, Java, etc.
That Rust has great perf and uses little resources is just a bonus, but not something that most apps will care much about.
The downsides you mention about the ecosystem, libraries, frameworks, are real.
I disagree with your claim that there is no "talent pool" for Rust. The "talent pool" for javascript or C++ is _only_ "all javascript experts" or "all C++ experts" because if you are not very good at Javascript or C++, you can't really be trusted. A Javascript programmer can start being productive in Rust without issues quickly, but the same wouldn't be true if they had to program in C++ instead.
The "talent pool" for Rust is "all programmers with domain knowledge". If they are not experts in Rust, that doesn't matter. Smart people you want to hire all pick up Rust very quickly, and the amount of dangerous mistakes anyone can make by not being a Rust expert is very small.
Offer/demand wise, the demand for Rust jobs is much higher than the Rust jobs that are currently available. If you post a Rust job on reddit you'll get 100 CVs in a day...
---
IMO, your main point still holds: right now Rust web frameworks are not as feature full as Django, Rails, etc. and if Rust frameworks are missing features you need, picking it up for a professional project probably doesn't make sense. Unless... you are willing to implement those features yourself...
> C++ is "web ready", too
C++ is not a good fit for network accessible services. It is too easy (even with Modern C++) to cause memory based security problems (and I say this as someone who writes protocol stacks in C and C++ for a living).
Rust's security story is much better out of the box.
C++ is not a good fit for network accessible services. It is too easy (even with Modern C++) to cause memory based security problems (and I say this as someone who writes protocol stacks in C and C++ for a living).
Rust's security story is much better out of the box.
Actix-web makes some very aggressive use of unsafe. Many core Rust libraries do too. If you trust those authors (some very fresh out of school) to have zero mistakes, why would you not trust the C++ STL?
I am less worried about libraries than I am about usage of them.
I don't have personal knowledge of the use of unsafe in Actix-web, but yes I agree that it's not ideal and I would prefer to use an alternative. On the other hand, it is a library used by a number of projects and so security problems are more likely to be surfaced (and I get fixes for them for very little effort).
I'm more concerned with how easy it is to create security holes in your application (when built in a way encouraged by the framework), and it is definitely easier in C++ than Rust.
I don't have personal knowledge of the use of unsafe in Actix-web, but yes I agree that it's not ideal and I would prefer to use an alternative. On the other hand, it is a library used by a number of projects and so security problems are more likely to be surfaced (and I get fixes for them for very little effort).
I'm more concerned with how easy it is to create security holes in your application (when built in a way encouraged by the framework), and it is definitely easier in C++ than Rust.
In my understanding, they removed that aggressive usage, and this hasn’t been true for months.
Using the magic of Grep
Occurrences of unsafe in: Actix-web: 39 A few dependencies Regex: 136 Bytes: 118 Tinyvec: 8
That’s far from exhaustive. So I wouldn’t consider this implicitly safer than any particular C++ library that has been through some basic static analysis. If anything, there probably have been way more eyes on STL. I would be even less confident in this case since the author of Actix who probably actually knew what he was doing was harassed out of his own project by the friendly community.
I get the safety for performance trade off, but Rust evangelists pretend this trade off never happens, and it’s very pervasive in important libraries.
Occurrences of unsafe in: Actix-web: 39 A few dependencies Regex: 136 Bytes: 118 Tinyvec: 8
That’s far from exhaustive. So I wouldn’t consider this implicitly safer than any particular C++ library that has been through some basic static analysis. If anything, there probably have been way more eyes on STL. I would be even less confident in this case since the author of Actix who probably actually knew what he was doing was harassed out of his own project by the friendly community.
I get the safety for performance trade off, but Rust evangelists pretend this trade off never happens, and it’s very pervasive in important libraries.
You've now changed the goalposts from "aggressive usage" to "here's a count of a particular substring in the source code."
I would call dozens of uses in the core and hundreds in the dependencies aggressive usage. Statically determinant memory use is the main reason we’re not taking advantage of decades of C++ development, after all.
The use of unsafe on actix-web has gone down a lot and this is a thing of the past.
Not sure of your protocol stacks but I happen to write network accessible services in modern C++ for living as well. Without going into much details I'd say that I do not really share your point of view. Not sure when was the last time I had any memory related problem with modern C++.
I appreciated your comment until the snarky last sentence.
> Who needs more than 300000 req/s and can't afford servers to scale?
Exactly companies who can afford to scale. If you could switch from Python to Rust and reduce your server costs by 10x, why wouldn't you?
Exactly companies who can afford to scale. If you could switch from Python to Rust and reduce your server costs by 10x, why wouldn't you?
Can you trivially write a CRUD service with Swagger docs and JWT authentication using Rust? And how does performance compare to a FastAPI app?
My company is writing services that use OpenAPI (aka Swagger) heavily. I don't believe we are doing JWT currently. https://github.com/oxidecomputer/dropshot
I've never used FastAPI, but https://www.techempower.com/benchmarks/#section=data-r19 (which is the first thing TechEmpower shows me) says that for this specific test (and maybe others are different, you should look into it!), FastAPI does 52,080 RPS, and actix-core does 651,144.
I've never used FastAPI, but https://www.techempower.com/benchmarks/#section=data-r19 (which is the first thing TechEmpower shows me) says that for this specific test (and maybe others are different, you should look into it!), FastAPI does 52,080 RPS, and actix-core does 651,144.
One person's trivial 1-day of effort is another person's month. There's a solid jsonwebtoken library that could be used in a custom token authentication middleware, if the one in the ecosystem is unsatisfactory. It's not trivial to learn a web framework and how to write custom middleware, but if you know where to look for actix-web there is an example: https://github.com/actix/actix-extras/blob/master/actix-web-...
When Rocket lands Async/Await and other major reworks in flight maybe. Actix-Web is fast but ergonomics of writing Actix web apps are def. substandard compared to other mature ecosystems.
Is there a web framework / ecosystem built on a statically-typed, non-JVM language that comes close to the feature set of either Django/Rails?
After spending too much time chasing down dynamic-typing related bugs in both of those frameworks, I find myself missing a lot of their feature set when I look at other frameworks. However, I'm tired of doing "defensive programming" in Python to essentially statically assert argument types and unit test things that a statically-typed language would disallow by construction.
This stuff in Rust, Go, and even Nim [0] look interesting, but the consensus seems to be the value proposition of Rails or Django is still hard to beat unfortunately.
[0] https://nim-lang.org/
After spending too much time chasing down dynamic-typing related bugs in both of those frameworks, I find myself missing a lot of their feature set when I look at other frameworks. However, I'm tired of doing "defensive programming" in Python to essentially statically assert argument types and unit test things that a statically-typed language would disallow by construction.
This stuff in Rust, Go, and even Nim [0] look interesting, but the consensus seems to be the value proposition of Rails or Django is still hard to beat unfortunately.
[0] https://nim-lang.org/
just curious why non jvm?
The biggest one first: Operationally maintaining the JVM is a nightmare. It can be fast, but that isn't guaranteed and its not trivial to find out why, and easy for developers to mess up. It uses significantly more memory than anything else which will be your largest cost driver when running large services, compute is cheap, RAM is not.
Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software (given maybe only Flash beats the JVM in the history of boths existence) but the defaults for running a lot of things like groovy aren't secure (there is a debug port you can directly manipulate the memory of the running process without authentication). Commonly people use these debug ports in production, not just leave the defaults but actively choose to let them run. This is a very common pattern in Java based services usually caused by my first point. I am not aware of any other language or framework that offers remote memory access as a feature.
Then there are the dependencies and package ecosystem. I believe the "built on the JVM" languages like Kotlin have gotten a lot better at this, but as soon as you start tapping into the pure Java "enterprise grade" libraries you're most likely bringing in way more than you bargained for both in terms of complexity, maintainability, and security. A lot of those libraries are simply poorly built.
Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software (given maybe only Flash beats the JVM in the history of boths existence) but the defaults for running a lot of things like groovy aren't secure (there is a debug port you can directly manipulate the memory of the running process without authentication). Commonly people use these debug ports in production, not just leave the defaults but actively choose to let them run. This is a very common pattern in Java based services usually caused by my first point. I am not aware of any other language or framework that offers remote memory access as a feature.
Then there are the dependencies and package ecosystem. I believe the "built on the JVM" languages like Kotlin have gotten a lot better at this, but as soon as you start tapping into the pure Java "enterprise grade" libraries you're most likely bringing in way more than you bargained for both in terms of complexity, maintainability, and security. A lot of those libraries are simply poorly built.
> Operationally maintaining the JVM is a nightmare
The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that. Secondly, with new GCs like ZGC and Shenandoah, the number of knobs to tune (at least with respect to the GC) has decreased dramatically to only a couple.
> Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software
This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore.
The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that. Secondly, with new GCs like ZGC and Shenandoah, the number of knobs to tune (at least with respect to the GC) has decreased dramatically to only a couple.
> Security is probably the next biggest one. Vulnerabilities in the JVM are a problem but you'll have that in most software
This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore.
> The JVM gives you practically every knob you need to achieve maximal performance for your workload. I don't know of any other environment that does that.
That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world. The fact that you need to know at least 16 flags for the JVM with obscure syntaxes to get a basically stable Tomcat server (not Tomcat flags, those are another nightmare) is precisely the problem with Java.
> This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore
You've got to be trolling on this one. I'm definitely not talking about browser-side rendering. Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world. The fact that you need to know at least 16 flags for the JVM with obscure syntaxes to get a basically stable Tomcat server (not Tomcat flags, those are another nightmare) is precisely the problem with Java.
> This is a non-issue for backend systems. Barely anyone uses Java for browser-side rendering anymore
You've got to be trolling on this one. I'm definitely not talking about browser-side rendering. Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
> That's because no other environment needs to. No other environment eager loads a quarter gig of ram to say hello world.
This is just hyperbole and you know it. The JVM with the turn of a few knobs is able to accommodate high throughput batch workloads, as well as lower latency workloads, especially with the advent of ZGC and Shenandoah, all while supporting multi-TB heap sizes.
Look at what hacks the Discord and Twitch teams had to endure to get around golang's workload specific GC for example, and it will show why the JVM is written the way it is.
> Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
Those were not JVM-specific issues, and would have happened regardless in any hosting environment or even compiler if we're talking about running single binaries. You need a good upgrade path process laid out.
This is just hyperbole and you know it. The JVM with the turn of a few knobs is able to accommodate high throughput batch workloads, as well as lower latency workloads, especially with the advent of ZGC and Shenandoah, all while supporting multi-TB heap sizes.
Look at what hacks the Discord and Twitch teams had to endure to get around golang's workload specific GC for example, and it will show why the JVM is written the way it is.
> Weak backend systems are exactly how Fortune 500 systems get breached over and over and over. This was exactly the cause of the Equifax breach and so many others. You should never think that is ok.
Those were not JVM-specific issues, and would have happened regardless in any hosting environment or even compiler if we're talking about running single binaries. You need a good upgrade path process laid out.
> The JVM gives you practically every knob you need to achieve maximal performance
While this is true, finding folks that deeply understand how those knobs work, (and what the potential pitfalls are of twisting each knob might be) is not as easy as finding a Java/Kotlin/Scala/Clojure/JRuby developer. The out-of-the-box JVM experience can take one quite a long way. It's that last mile to real performance that can be the nightmare.
While this is true, finding folks that deeply understand how those knobs work, (and what the potential pitfalls are of twisting each knob might be) is not as easy as finding a Java/Kotlin/Scala/Clojure/JRuby developer. The out-of-the-box JVM experience can take one quite a long way. It's that last mile to real performance that can be the nightmare.
Well, you need operations people and people with experience anyway. We've seen the blog posts by companies like Discord and others that needed to implement difficult workarounds in their golang code bases. The problem is always there, not thinking about it won't make it go away. I'd argue that golang "solution" was a big hack, and that having a proper mature solution like the JVM would have saved time and effort.
I haven't used the JVM in a long time, but judging by the web framework benchmarks I've checked out this morning e.g. [0], it seems like there are many Go frameworks that beat those on the JVM.
I agree with other commenters on this thread that in general such benchmarks may not mean a lot when compute is so cheap and the autoscaling infrastructure is awesome, but I often work on embedded platforms or other resource constrained devices where adding the JVM is a nonstarter (not that Django or Rails is an option either in those cases).
[0] https://github.com/the-benchmarker/web-frameworks
I agree with other commenters on this thread that in general such benchmarks may not mean a lot when compute is so cheap and the autoscaling infrastructure is awesome, but I often work on embedded platforms or other resource constrained devices where adding the JVM is a nonstarter (not that Django or Rails is an option either in those cases).
[0] https://github.com/the-benchmarker/web-frameworks
Note that those benchmarks use a non-standard golang HTTP library (fasthttp I believe), which even according to it's author makes certain compromises and can be tricky to deal with, and can fail in edge cases (I'd avoid it for production). Whereas the Java versions are much more standard and safer to use.
Secondly, something seems off if a php framework is getting top place, unless it's doing some AOT compilation.
Secondly, something seems off if a php framework is getting top place, unless it's doing some AOT compilation.
C# or maybe Node with typescript.
Is C# usable from Mono? I've kinda shyed away from C# due to not running Windows myself (and running it on the platforms at work is impossible), but I haven't had the time to try it with Mono.
I would personally avoid Mono, but I would use .NET Core. Core is not built for Windows alone.
https://stackoverflow.com/questions/37738106/net-core-vs-mon...
https://stackoverflow.com/questions/37738106/net-core-vs-mon...
You are incredibly out of date. No one uses mono any more. It's .net core. The official version which works on multiple platforms.
Just last night I debugged some C# on Mac via Visual Studio for Mac. The debugger actually worked!
I must admit that I've been tinkering with this debugger for about 11 years. (Used to be MonoDevelop, then Xamarain Studio.) It used to be very unstable. Now it's usable.
YMMV
I must admit that I've been tinkering with this debugger for about 11 years. (Used to be MonoDevelop, then Xamarain Studio.) It used to be very unstable. Now it's usable.
YMMV
.NET Core has been running on multiple platforms for several years now, and many companies use it. I believe Bing itself is hosted on it as well. It's free and open source. They've been doing great work with performance.
We use Mypy to type check python, and I really like that system. Catches a lot of errors. Not as many as a full static typing system, but still a lot, and you can always drop back into dynamic typing when you want.
Wow thanks! Does it just insert these checks automatically (`assert type(my_param) == int`)? I remember being so disappointed when I saw PEP484 and realizing that it didn't enforce anything.
mypy is only a static checker, there are no runtime-checks inserted. You run it as a command-line tool and it will fail the build if the types do not resolve, like a compiler or linting tool.
For runtime-checking based on PEP484 type hints, one can complement this with a library like Pydantic/Enforce.py/typeguard/typesentry. Enforcement of the types is typically opt-in per function call, often by adding a decorator.
For runtime-checking based on PEP484 type hints, one can complement this with a library like Pydantic/Enforce.py/typeguard/typesentry. Enforcement of the types is typically opt-in per function call, often by adding a decorator.
asp.net core comes to mind
Can I add "ML-typed" to your spec? That's what would finally make me jump from Python/Flask
There's Crystal: https://crystal-lang.org/
I'm a big fan of WASM to run my cross-platform code in browsers, but everytime I see it pitched as wholesale replacement for Javascript frameworks which sit on top of the DOM I flinch a bit.
This is essentially the reverse of "with Electron you can now create native applications entirely in Javascript". Yes it works, but only with a lot of overhead that wouldn't exist by doing it the "straightforward" way.
A much smarter approach is to create hybrid JS/WASM applications, manage the UI in Javascript, move isolated standalone features (cross-platform code or performance-sensitive code) into WASM modules, and call into those WASM modules from JS.
This is essentially the reverse of "with Electron you can now create native applications entirely in Javascript". Yes it works, but only with a lot of overhead that wouldn't exist by doing it the "straightforward" way.
A much smarter approach is to create hybrid JS/WASM applications, manage the UI in Javascript, move isolated standalone features (cross-platform code or performance-sensitive code) into WASM modules, and call into those WASM modules from JS.
Will we see the next generation of electron applications using WASM for the bulk, and JS for the UI?
Heh, good point. In my last sentence I was thinking about web apps running in browsers, not about Electron (but of course there's a lot of overlap).
For native applications, maybe a better idea is to drive the UI with native code, and use WASM to run "untrusted" external code (for instance extensions/plugins), because a WASM runtime is a lot smaller than a complete browser engine like Electron.
For native applications, maybe a better idea is to drive the UI with native code, and use WASM to run "untrusted" external code (for instance extensions/plugins), because a WASM runtime is a lot smaller than a complete browser engine like Electron.
I’d be surprised, given that one of the big arguments for using Electron is that you get to write it in JS.
If you write Rust for WASM you could just use a native UI framework and target that instead!
If you write Rust for WASM you could just use a native UI framework and target that instead!
IMHO the USP of Electron isn't even that you can write the logic in Javascript, but that it's the option that "sucks least" for creating cross-platform UI applications.
A lot of people want to avoid the Javascript ecosystem because of fragmentation, churn and a range of other reasons. e.g. https://www.destroyallsoftware.com/talks/wat
I suppose they consider working with other languages, ecosystems and communities a smarter approach. Perhaps they have good reasons.
I suppose they consider working with other languages, ecosystems and communities a smarter approach. Perhaps they have good reasons.
Yeah I see the point, but you need to consider the downsides too.
It's hard to get the binary size of WASM modules down to the size of minified Javascript, especially for code that calls into the browser anyway (e.g. for manipulating the DOM). Depending on what the code does it's not impossible, and sometimes WASM even comes out smaller, but this takes a lot of optimization and tweaking, and often developers are blind to this sort of problem (it mostly affects the users after all).
One cannot simply hand-wave those points away just because Javascript sucks (even ignoring the fact that JS hate is often completely irrational, I don't like the language either, but sheesh, C++ or Rust are not that much better).
It's hard to get the binary size of WASM modules down to the size of minified Javascript, especially for code that calls into the browser anyway (e.g. for manipulating the DOM). Depending on what the code does it's not impossible, and sometimes WASM even comes out smaller, but this takes a lot of optimization and tweaking, and often developers are blind to this sort of problem (it mostly affects the users after all).
One cannot simply hand-wave those points away just because Javascript sucks (even ignoring the fact that JS hate is often completely irrational, I don't like the language either, but sheesh, C++ or Rust are not that much better).
I agree with you about that specific downside you mentioned.
Plus there's some other downsides such as likelihood that you might have to mix small amounts of Javascript as a second language into a WASM heavy solution based on another language.
However those are tradeoffs, and depending on the situation those tradeoffs can be very acceptable. A lot of enterprise software for instance isn't particularly concerned with those issues, and benefits strongly from the other very very significant benefits that can come from the other side of the tradeoff of avoiding the javascript ecosystem (not just language, but culture, tooling, churn and etc). Those benefits can include a range of things but I will just point out one theme which is increased stability and maintainability .. expressed in thing like type safety and refactoring tools, longer release cycles, less reliance on packages in favour of batteries included comprehensive language libraries, less pain with package upgrades, less pain with the canoninical way to use your framework de jour changing each year, less pain with prior art patterns being (gradually) rediscovered (and renamed) , and generally a culture that prioritises reliability and maintainability over the new hotness (or hotmess, depending on perspective!).
There's other situations, such as building the absolute fastest load time for a customer page, that tradeoff might not be appropriate. However to be fair there are other techniques for managing that, such as server side rendering and client hydrating of SPAs. Or gasp server rendered sites hehe with just a sprinkling of client interactivity if needed.
(Actually I think SPAs are usually not great at fast time to responsiveness, but that's really another discussion and lets not get sidetracked. The main point is the drawbacks are tradeoffs, and for many systems they are appropriate tradeoffs.)
Plus there's some other downsides such as likelihood that you might have to mix small amounts of Javascript as a second language into a WASM heavy solution based on another language.
However those are tradeoffs, and depending on the situation those tradeoffs can be very acceptable. A lot of enterprise software for instance isn't particularly concerned with those issues, and benefits strongly from the other very very significant benefits that can come from the other side of the tradeoff of avoiding the javascript ecosystem (not just language, but culture, tooling, churn and etc). Those benefits can include a range of things but I will just point out one theme which is increased stability and maintainability .. expressed in thing like type safety and refactoring tools, longer release cycles, less reliance on packages in favour of batteries included comprehensive language libraries, less pain with package upgrades, less pain with the canoninical way to use your framework de jour changing each year, less pain with prior art patterns being (gradually) rediscovered (and renamed) , and generally a culture that prioritises reliability and maintainability over the new hotness (or hotmess, depending on perspective!).
There's other situations, such as building the absolute fastest load time for a customer page, that tradeoff might not be appropriate. However to be fair there are other techniques for managing that, such as server side rendering and client hydrating of SPAs. Or gasp server rendered sites hehe with just a sprinkling of client interactivity if needed.
(Actually I think SPAs are usually not great at fast time to responsiveness, but that's really another discussion and lets not get sidetracked. The main point is the drawbacks are tradeoffs, and for many systems they are appropriate tradeoffs.)
So in summary I'd say that HN highly disagrees with the author...
Speaking of Rust's WebAssembly runtime option, I would argue that, unless one is heavily biased toward using Rust, ASP.NET's Blazor WebAssembly host option has a more attractive value proposition overall, due to a much more comprehensive developer and tooling ecosystems.
I'm quite impressed by Microsoft's Blazor and .NET Core teams working on improving Blazor's performance and decreasing the system bundle's download size. Blazor's performance in upcoming .NET 5 is reported to be already 2-3x better than in .NET 3. I expect that ongoing work on ahead-of-time (AOT) compilation to WebAssembly, including an ability to freely mix AOT- and JIT-compiled code (expected to be shipped as part of .NET 6) will further improve Blazor's competitive position vs. Rust's WebAssembly from the performance perspective.
I'm quite impressed by Microsoft's Blazor and .NET Core teams working on improving Blazor's performance and decreasing the system bundle's download size. Blazor's performance in upcoming .NET 5 is reported to be already 2-3x better than in .NET 3. I expect that ongoing work on ahead-of-time (AOT) compilation to WebAssembly, including an ability to freely mix AOT- and JIT-compiled code (expected to be shipped as part of .NET 6) will further improve Blazor's competitive position vs. Rust's WebAssembly from the performance perspective.
The problem with blazor is that the only thing that is in webassembly is the bytecode interpreter and not your code. More is currently problematic because too much C# code relies on reflection making AOT difficult and webassembly not having garbage collection integration yet.
Thank you for mentioning this. Your first sentence is true, but only for the current JIT-compiled option. Even in this case, Blazor is still functionally (i.e., excluding performance aspect) comparable with Rust WebAssembly option (and any other WASM-targeted language options, for that matter). Assuming that relevant AOT challenges would be solved as planned, it would make Blazor an option fully (i.e., including performance-wise) comparable with Rust WebAssembly.
That is not correct, or not the full story.
Blazor has two separate modes, 'Server Side' and 'Web Assembly'.
What you're describing is the server side mode.
The second mode, called Web Assembly, compiles your code to WASM that is executed in the browser.
https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
Also, "The .NET 5.0 core framework libraries have been annotated to indicate what works in the WebAssembly runtime, so developers now get a warning in the code editor when attempting to call an unsupported method." from https://www.theregister.com/2020/10/15/microsoft_emits_net_5...
Blazor has two separate modes, 'Server Side' and 'Web Assembly'.
What you're describing is the server side mode.
The second mode, called Web Assembly, compiles your code to WASM that is executed in the browser.
https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
Also, "The .NET 5.0 core framework libraries have been annotated to indicate what works in the WebAssembly runtime, so developers now get a warning in the code editor when attempting to call an unsupported method." from https://www.theregister.com/2020/10/15/microsoft_emits_net_5...
Nope the server version has no Webassembly at all. The Webassembly version lets a .NET IL interpreter in WA running your code.
I spent some of my time building or trying to build various web apps in both Rust and Crystal. The Rust web experience of several years ago was very frustrating and it was partially due to the lacking ecosystem but also due to the nature of the language. The safety guarantees that the language provides are great if you care about that, but they can be quite a pain when you just want to get something out. The majority of web projects fall in the last category. The language ergonomics have improved since (you don't have to do so much pointer juggling any more) but it's still no way near other languages that might only cover these guarantees partially or not at all. Language ergonomics is a very important aspect because it can limit both the development speed of your project but also the speed at which the ecosystem develops.
The performance aspect (aside from WebAssembly, where it has few contenders) is something that can be partially matched by other technologies.
By comparsion, developing for the web in Crystal is quite enjoyable. The language has great ergonomics (I'd say even better than Ruby). The web ecosystem might not be mature but it's blooming and it has you covered in the main areas. Most importantly, if you're missing something, it's very easy to build it yourself. The standard library contains a lot of web goodies, including a very decent HTTP client, a server, easy to use and fast JSON and XML parsers, an OAuth2 client (yes!). The language feels like it was built for the web, which I can't say about Rust.
In the end, what matters is your use case and the trade-offs you are willing to make (development speed vs. performance vs. safety guarantees). If I would have to build a load balancer, I might consider Rust. For a normal web app, I'd personally go with something like Crystal, Ruby, Python, Node.
The performance aspect (aside from WebAssembly, where it has few contenders) is something that can be partially matched by other technologies.
By comparsion, developing for the web in Crystal is quite enjoyable. The language has great ergonomics (I'd say even better than Ruby). The web ecosystem might not be mature but it's blooming and it has you covered in the main areas. Most importantly, if you're missing something, it's very easy to build it yourself. The standard library contains a lot of web goodies, including a very decent HTTP client, a server, easy to use and fast JSON and XML parsers, an OAuth2 client (yes!). The language feels like it was built for the web, which I can't say about Rust.
In the end, what matters is your use case and the trade-offs you are willing to make (development speed vs. performance vs. safety guarantees). If I would have to build a load balancer, I might consider Rust. For a normal web app, I'd personally go with something like Crystal, Ruby, Python, Node.
My company Clausehound has completely moved its legal tech contract analysis and version control platform onto rust, and launched a couple months ago. It's been fantastic. We're a similar setup to a lot of the top links on there (actix-web over juniper for graphql resolving with sqlx). While the speed is incredible, the biggest improvement has been the types system. I've never had such an easy experience being able to pick and choose libraries based on shared traits - eg we could authorize on jwt using jsonwebtoken, load fairly complex migrated relational data into our nice models, and even wrote the crate phpass so we could keep some accounts created back when we were a WordPress blog working.
The strict typing in graphql has made dataloaders orders of magnitude faster. The same code that makes our business logic clear makes it easy to figure out if graphql needs to resolve all those nodes with individual sql queries, one against the parent node, build some `IN (?,?,?,?)` prepared statement, or resolve from cache. String manipulation is definitely a bit harder, but otherwise the experience as a web app developer has been amazing.
The strict typing in graphql has made dataloaders orders of magnitude faster. The same code that makes our business logic clear makes it easy to figure out if graphql needs to resolve all those nodes with individual sql queries, one against the parent node, build some `IN (?,?,?,?)` prepared statement, or resolve from cache. String manipulation is definitely a bit harder, but otherwise the experience as a web app developer has been amazing.
Would you agree that the resources in the linked article are a good starting point to learn about your specific rust stack, or do you have additional resources you would recommend?
Yeah, I probably have been a lazy member of the greater dev community because I learned a lot of these things but never blogged about it myself. Juniper for graphql is a big missing piece from that page -- gql is big enough as an alternative to REST that it ought to be at least considered, while RESTful services typically come baked-in because they rely so much on standard HTTP (so their use with eg actix-web is obvious). What I really found amazing was how we could write one struct, e.g. an Organization, and easily build them from JWT claims, SQL queries, graphql payloads, or POST params. With many other framework libraries, I'd really agonize over graphql vs rest, but because the types are so rigidly defined, it's very easy to write the definitions once and use them everywhere, so RESTful endpoints are simple to setup where there's a client demand for them.
An extremely cool new one is serde_pickle support (python's favourite binary serialization), which we're using to load tiny word-vectorization dictionaries in WASM. This lets lawyers collaborate concurrently on the same contract, and farms out the laptops/phones they're working on's GPU cycles to auto-draft the contract (e.g. type 8 words, and can see "85% chance this a non-disparagement clause -- here's some example language you can use. Here's some case law saying when it's enforceable and when it's not").
An extremely cool new one is serde_pickle support (python's favourite binary serialization), which we're using to load tiny word-vectorization dictionaries in WASM. This lets lawyers collaborate concurrently on the same contract, and farms out the laptops/phones they're working on's GPU cycles to auto-draft the contract (e.g. type 8 words, and can see "85% chance this a non-disparagement clause -- here's some example language you can use. Here's some case law saying when it's enforceable and when it's not").
I'm new to Rust and trying to do some tasks with Rust's rusoto library, but it seems like too verbose and lacking documents as well as examples of how one can do things with it. Comparing to boto3 library, it's a steep learning curve to me.
I am playing with Rust on a side project. I use graphql with juniper on the server side, and WebAssembly on the client side, together with Vue. I love it. It's still more complex and verbose than a full javascript project, and the compilation time are long but I enjoy it.
I would recommend Rust over Typescript, if you are going to spend time on types, use Rust it's more worth it.
I would recommend Rust over Typescript, if you are going to spend time on types, use Rust it's more worth it.
Any resources on how to get started?
I tought about using Rust instead of JavaScript for frontend for some time.
On the one hand, Rust is a step back, because there is quite some things you have to do more than with JavaScript.
On the other hand, Rust has an interesting type system that could save you in the long run and things like pattern-matching and expressions everywhere is even a direct usability improvement over JavaScript.
So it's not, Rust is more low-level than JavaScript, that's why it's bad for frontend, but more, Rust is different from JavaScript some parts are harder, some are easier.
I tought about using Rust instead of JavaScript for frontend for some time.
On the one hand, Rust is a step back, because there is quite some things you have to do more than with JavaScript.
On the other hand, Rust has an interesting type system that could save you in the long run and things like pattern-matching and expressions everywhere is even a direct usability improvement over JavaScript.
So it's not, Rust is more low-level than JavaScript, that's why it's bad for frontend, but more, Rust is different from JavaScript some parts are harder, some are easier.
I went with the official documentation of rust and rust-wasm. It was okay.
I would recommend to use the best tool for your problem. If you want to display a button and manage click events, don't use Rust it's not worth it.
I would recommend to use the best tool for your problem. If you want to display a button and manage click events, don't use Rust it's not worth it.
Worth it in which way? Due to the types?
So the vast ecosystem and ready functionality offered by typescript or other high level languages is worth less than what exactly?
So the vast ecosystem and ready functionality offered by typescript or other high level languages is worth less than what exactly?
Dealing with types is boring so if I'm going to spend time on this, it should have enough benefits. In my humble opinion the rust typing system is more interesting than what typescript can offer.
The main advantage for me is the monad. Sure you could use monads in typescript or even vanilla javascript but in Rust, everything uses monads.
The vast javascript ecosystem is available to rust in the browser too. Server side it's not as big and I agree javascript has a point there. But now, if you look at the ecosystem of libraries with proper and up-to-date typescript definitions, well it's not that great.
The main advantage for me is the monad. Sure you could use monads in typescript or even vanilla javascript but in Rust, everything uses monads.
The vast javascript ecosystem is available to rust in the browser too. Server side it's not as big and I agree javascript has a point there. But now, if you look at the ecosystem of libraries with proper and up-to-date typescript definitions, well it's not that great.
Saying that it can replace Django is quite an overstatement! The only framework which can be compared in features is Rails and Spring, nothing else even comes close! Not to mention the productivity benefits... Rust is a good language, but with these compile times for a complex Django-like web application? No thanks.
Not to mention Django (and flask) come with a ton of modules to get you up and running.
Not sure I personally feel comfortable building my own authentication modules. The rocket example was similar to one I did in flask but with flask I didn’t feel like I was creating my own auth. Rocket guards and JWT left me feeling like it was much easier to make a huge mistake.
Not sure I personally feel comfortable building my own authentication modules. The rocket example was similar to one I did in flask but with flask I didn’t feel like I was creating my own auth. Rocket guards and JWT left me feeling like it was much easier to make a huge mistake.
Yeah, but those compile times catch bugs everyone misses in your Django app.
People think speed is the only advantage, reducing runtime debugging and providing a more secure, more correct front end, free null pointer issues and free of memory leaks and runtime type errors - rust just has the added bonus of being fast.
You're right some of the tools aren't quite there and if you move a rails-y app over to rust, you have a job ahead of you to assemble some libraries, but it is doable - the point is that you can put rust in production at web scale now.
People think speed is the only advantage, reducing runtime debugging and providing a more secure, more correct front end, free null pointer issues and free of memory leaks and runtime type errors - rust just has the added bonus of being fast.
You're right some of the tools aren't quite there and if you move a rails-y app over to rust, you have a job ahead of you to assemble some libraries, but it is doable - the point is that you can put rust in production at web scale now.
It is absolutely an overstatement and people should be more careful with misrepresenting what the Rust language and ecosystem offers. Rust has its strengths just as Python does. None of the authors of the web frameworks are aspiring to build a Django or Flask like experience.
What about laravel?
Rails doesn't even have it's own authentication built in?
Seems laravel, might be closer to django, and with jetstream - it has an admin area baked in, which others don't.
Laravel is also just as, if not more performant (if you mix in swoole).
Rails doesn't even have it's own authentication built in?
Seems laravel, might be closer to django, and with jetstream - it has an admin area baked in, which others don't.
Laravel is also just as, if not more performant (if you mix in swoole).
love how it claims that "it's freaking fast", yet has no performance metrics on the page. granted they might be hidden behind a link a or two, but i'm going hunting for something when you should have it right there on the page to back up your claims.
Let's remember that while actix web rank very high in techempower up, most of it's performance lead come because of it's async connection with postgres. Other languages will catch up in this regards in a few years (e.g loom for Spring)
I’m sure I’m not the only one wondering, but why would someone want to write web code in Rust.
To be fair, as a web developer by day, I still haven’t gotten around to trying to write any Rust in my free time. I am curious though. But after browsing the docs of actix-web and rocket, it seems a bit of a reach to say you could use these solutions in place of monolithic frameworks Django or Rails.
Maybe if they had said they could take the place of an Express/ Slim / Flask app I wouldn’t have rolled my eyes as hard. Wouldn’t these battle tested ‘micro’ frameworks be a better comparison?
Anyway, since I really know next to nothing about Rust, what would be the benefits for me to pick say, Actix-web over Slim to start a new project?
I get the feeling the best reason would be I’m already an experienced Rust developer and want to leverage that domain knowledge. Or maybe a team that already writes a lot of Rust wants to keep consistency over their repos.
To be fair, as a web developer by day, I still haven’t gotten around to trying to write any Rust in my free time. I am curious though. But after browsing the docs of actix-web and rocket, it seems a bit of a reach to say you could use these solutions in place of monolithic frameworks Django or Rails.
Maybe if they had said they could take the place of an Express/ Slim / Flask app I wouldn’t have rolled my eyes as hard. Wouldn’t these battle tested ‘micro’ frameworks be a better comparison?
Anyway, since I really know next to nothing about Rust, what would be the benefits for me to pick say, Actix-web over Slim to start a new project?
I get the feeling the best reason would be I’m already an experienced Rust developer and want to leverage that domain knowledge. Or maybe a team that already writes a lot of Rust wants to keep consistency over their repos.
The best part about Rust is the type system. For one example, in a web app I'm building for a client, we have two types to represent invoice ids: one for the invoice id that came back in a response from the API, and one for an invoice id that a user is asking for. They are distinct because we know that an InvoiceId refers to an actual invoice in the system, and a UnverifiedInvoiceId might not. Both of them are distinct from a CustomerId or any other id.
This might sound like it could get cumbersome fast, but it's actually really simple in practice, due to clever uses of traits. UnverifiedInvoiceId implements rocket::FromParam, so I can deserialize it from a URL parameter. InvoiceId is only created in the serde::Deserialize implementation of an invoice-returning API response.
So a (significantly simplified) endpoint in the app might look like:
This might sound like it could get cumbersome fast, but it's actually really simple in practice, due to clever uses of traits. UnverifiedInvoiceId implements rocket::FromParam, so I can deserialize it from a URL parameter. InvoiceId is only created in the serde::Deserialize implementation of an invoice-returning API response.
So a (significantly simplified) endpoint in the app might look like:
#[get("/invoices/<unverified_invoice_id>")]
pub fn get_invoice_by_id(
unverified_invoice_id: UnverifiedInvoiceId,
api_conn: ApiConnection,
) -> HtmlResponse {
// API "search" methods take unverified user input as parameters
let invoice = api_conn.fetch_invoice_by_id(unverified_invoice_id);
// API "lookup" methods take verified ids
let line_items = api_conn.fetch_invoice_line_items(invoice.id);
render_invoice(invoice, line_items);
}
One time I made an authentication system for an application that had some types like PlainTextAccountPassword and HashedAccountPassword. The storage backend for accounts accepted a HashedAccountPassword only. This way it would be less likely that a maintainer would end up storing a plain text password.
It is possible to do something like this in nearly any language with a type system.
It is possible to do something like this in nearly any language with a type system.
Yeah, easy to make a class for that in Python and you basically have a new type. It can even check itself, although I'm not sure that's a great idea :) .
None of this is unique to Rust - I can do this in typescript:
Serde -> Zod (https://github.com/vriad/zod)
Diesel -> Prisma
Yet you expose yourself to concepts that are unique to Rust that do not enhance the developer experience (such as lifetimes). I don't need to worry about lifetimes in typescript and can just focus on shipping code.
Lifetimes is just one example, but there are others that create more friction than they provide benefit IMO.
Serde -> Zod (https://github.com/vriad/zod)
Diesel -> Prisma
Yet you expose yourself to concepts that are unique to Rust that do not enhance the developer experience (such as lifetimes). I don't need to worry about lifetimes in typescript and can just focus on shipping code.
Lifetimes is just one example, but there are others that create more friction than they provide benefit IMO.
Business logic is where Rust would shine and rust feels nicer to work in than java.
Wouldn't Kotlin and Typescript provide many of these benefits on a much more mature ecosystem?
I agree that Express/Slim/Flask is a better comparison.
But, to answer your core question, there are a few different reasons:
* Performance. The simple, straightforward Rust code will often be much faster than the usual suspects here. Sometimes, I/O is your bottleneck, but sometimes it's not. Maybe you only move some backend services over. npm is an example of a company that did this; some high performance services were implemented in Rust because Node was struggling.
* Consistency. Resource usage tends to be very flat. This helps with things like capacity planning, but also reliability (which is a later bullet point).
* Cost. This is directly related to performance, but also on a different axis: memory usage. We've seen people switch code to Rust, and while the performance doesn't change things for end users, the extra overhead means smaller servers, or less servers, which translates directly into $$$. There are some big, not super public success stories here I wish I could tell you about, but a public example is Rubygems. They had a lambda doing some log processing, and the performance benefit of Rust made things fast enough to move it onto lambda's free tier. Infinity savings! (Though of course it was actually from $12,000/year -> $0)
* Reliability. Back to the npm use-case, they had a lot of ops issues with Node. The Rust code ran for something like a year, year and a half, before ever having a single production issue. Static typing helps here, less variable resource usage helps here.
* Static types. Some people have come to prefer developing in a language with static types. Rust doesn't have a monopoly here, but it is among very few languages that have many of its features, and many of them don't check those previous boxes.
Of course, things aren't a panacea either. The ecosystem isn't as mature, even if this web page says it is. Async is great, but not perfect. Some people really do not like static types. Etc.
But, to answer your core question, there are a few different reasons:
* Performance. The simple, straightforward Rust code will often be much faster than the usual suspects here. Sometimes, I/O is your bottleneck, but sometimes it's not. Maybe you only move some backend services over. npm is an example of a company that did this; some high performance services were implemented in Rust because Node was struggling.
* Consistency. Resource usage tends to be very flat. This helps with things like capacity planning, but also reliability (which is a later bullet point).
* Cost. This is directly related to performance, but also on a different axis: memory usage. We've seen people switch code to Rust, and while the performance doesn't change things for end users, the extra overhead means smaller servers, or less servers, which translates directly into $$$. There are some big, not super public success stories here I wish I could tell you about, but a public example is Rubygems. They had a lambda doing some log processing, and the performance benefit of Rust made things fast enough to move it onto lambda's free tier. Infinity savings! (Though of course it was actually from $12,000/year -> $0)
* Reliability. Back to the npm use-case, they had a lot of ops issues with Node. The Rust code ran for something like a year, year and a half, before ever having a single production issue. Static typing helps here, less variable resource usage helps here.
* Static types. Some people have come to prefer developing in a language with static types. Rust doesn't have a monopoly here, but it is among very few languages that have many of its features, and many of them don't check those previous boxes.
Of course, things aren't a panacea either. The ecosystem isn't as mature, even if this web page says it is. Async is great, but not perfect. Some people really do not like static types. Etc.
I'll admit, the performance benchmarks on actix-web are very impressive!
Thanks for the detailed response, I have an eyebrow raised :)
Thanks for the detailed response, I have an eyebrow raised :)
Does Rust significantly outperform Java and C#?
Yes, probably by a factor of 2-10x in most situations. Also memory footprint is going to be far lower too, so cheaper servers/leasing of resources. It's great for webapps (or restful backends) on embedded systems in particular. As always though I've seen people far more likely to be bottlenecked on I/O and database requests than on raw computing power. Usually even python and ruby are waiting on something else :) . Amdahl's Law is always worth keeping in mind.
Generally. As always, devil is in the details. Rust usually has a very similar performance profile to C and C++.
The memory usage part is where Rust is clearly at a stark advantage in that comparison.
The memory usage part is where Rust is clearly at a stark advantage in that comparison.
I'll try to focus on a reason that Steve hasn't touched in his response -- investing in one's future.
I'm a generalist who wants to use great tools for my work. I've built a variety of systems, not just web applications, with Rust. The more I use the language, the more I learn and develop greater capabilities to do more unfamiliar work. I am on the fence right now about diving into video streaming/processing but already have a foundational knowledge that will lend useful to a Rust-based solution. Embedded product development, too. And mobile. Rust is being used everywhere, now, with success.
So, while you may get away with using slim for your web app, using Rust instead is a way of acquiring the skillset that is applicable across all software development. One may do web dev today, but security engineering tomorrow. Whatever the domain, Rust expertise carries over. Using Rust for web development is how you invest in a software engineering future. As a manager, one may argue that this is up to the programmer to do so in their own time, and not company time. Well, in response to that I recommend reading Steve's comment as to why you can't afford not to use Rust going forward. :)
I'm a generalist who wants to use great tools for my work. I've built a variety of systems, not just web applications, with Rust. The more I use the language, the more I learn and develop greater capabilities to do more unfamiliar work. I am on the fence right now about diving into video streaming/processing but already have a foundational knowledge that will lend useful to a Rust-based solution. Embedded product development, too. And mobile. Rust is being used everywhere, now, with success.
So, while you may get away with using slim for your web app, using Rust instead is a way of acquiring the skillset that is applicable across all software development. One may do web dev today, but security engineering tomorrow. Whatever the domain, Rust expertise carries over. Using Rust for web development is how you invest in a software engineering future. As a manager, one may argue that this is up to the programmer to do so in their own time, and not company time. Well, in response to that I recommend reading Steve's comment as to why you can't afford not to use Rust going forward. :)
I come from a Node.js background and picked up Rust about a year ago, after dabbling with Haskell, Elixir and Purescript.
---
Things I like:
- Modern type system. Sum types, Option type etc
- Strict compiler. If it compiles, it works.
- Great error messages.
- Mature package tooling. Cargo is at least as good as npm.
- Mature GraphQL packages.
- Decent cloud support. Github actions, Container guides.
---
I've been running it in production for a while, usually as a remote schema for Hasura: https://github.com/ronanyeah/rust-hasura
Deploy pipeline:
- Push to github
- Github action builds binary
- Github action pushes binary to AWS ECS in a container
- This triggers a rebuild of the AWS Fargate service which restarts with new Rust code
---
Things I like:
- Modern type system. Sum types, Option type etc
- Strict compiler. If it compiles, it works.
- Great error messages.
- Mature package tooling. Cargo is at least as good as npm.
- Mature GraphQL packages.
- Decent cloud support. Github actions, Container guides.
---
I've been running it in production for a while, usually as a remote schema for Hasura: https://github.com/ronanyeah/rust-hasura
Deploy pipeline:
- Push to github
- Github action builds binary
- Github action pushes binary to AWS ECS in a container
- This triggers a rebuild of the AWS Fargate service which restarts with new Rust code
Only for certain kinds of workloads, definitely not for what I do with JavaEE/JakartaEE/LifeRay, ASP.NET (SharePOint, Sitecore) projects, alongside RDMS like DB2, SQL Server and Oracle.
Has anybody else actually clicked through some of the links to the topics that are supposedly ready?
Authentication/Authorization - for me, this means something like Rails Devise, which gets you a full set of routes, controllers, and views for user management, including correct session management, account creation, password reset, all using best-practices for handling passwords, session tokens, and reset workflows. Instead, we get a few cookie and JWT widgets. Nowhere near ready.
CMS - they list 3 static site generators. A static site generator is all well and good, but it's nowhere near being a CMS. They not only don't have a CMS, but don't even seem to know what a CMS is or that they need one and that a static site generator is not a substitute.
Database - it at least does have some okay ORMs. But do any web frameworks integrate with them to the extent that you can set up test databases and run test suites with them automatically? Do any of them support validations? Last I checked, Diesel's support for associations is pretty bare-bones.
I've tried out Rocket. It's all right for making relatively basic API apps. And it still doesn't build on Stable yet, though that's hopefully coming soon. I like Rust for a lot of things, but it has a long way to go before it can compete with full-fledged web frameworks.
Authentication/Authorization - for me, this means something like Rails Devise, which gets you a full set of routes, controllers, and views for user management, including correct session management, account creation, password reset, all using best-practices for handling passwords, session tokens, and reset workflows. Instead, we get a few cookie and JWT widgets. Nowhere near ready.
CMS - they list 3 static site generators. A static site generator is all well and good, but it's nowhere near being a CMS. They not only don't have a CMS, but don't even seem to know what a CMS is or that they need one and that a static site generator is not a substitute.
Database - it at least does have some okay ORMs. But do any web frameworks integrate with them to the extent that you can set up test databases and run test suites with them automatically? Do any of them support validations? Last I checked, Diesel's support for associations is pretty bare-bones.
I've tried out Rocket. It's all right for making relatively basic API apps. And it still doesn't build on Stable yet, though that's hopefully coming soon. I like Rust for a lot of things, but it has a long way to go before it can compete with full-fledged web frameworks.
Have you tried laravel?
One thing I hate about rails is devise.
laravel new app --jetstream
gets me an app with admin area, profile page, teams, my choice of livewire (like phoenix liveview), or vue + inertiajs (spa w/out vue-router i.e. using laravel's native router), I also get 2 factor built into the auth layer.
Might be 8 hours of work just to get rails to have all that laravel brings from the scaffold command for a new project.
One thing I hate about rails is devise.
laravel new app --jetstream
gets me an app with admin area, profile page, teams, my choice of livewire (like phoenix liveview), or vue + inertiajs (spa w/out vue-router i.e. using laravel's native router), I also get 2 factor built into the auth layer.
Might be 8 hours of work just to get rails to have all that laravel brings from the scaffold command for a new project.
> Is Rust web yet?
Only if you REALLY need it, like if you're embedding a web server into an existing Rust service. Otherwise, it's going to be very time consuming to do things that are straightforward in other languages.
(TLDR: A Rust++, or "Objective Rust" that simplifies some memory issues could make Rust web ready.)
For the past few months, my occasional hobby has been trying to learn Rust. BUT, I've also spent a considerable amount of time getting up to speed in NodeJS.
Regarding running Rust in the browser with WebAssembly: I've spent DAYS trying to figure out how to hook callbacks into the DOM cleanly. I basically went through the "Game of Life" walkthough, (https://rustwasm.github.io/docs/book/), and then ported all of the JavaScript sides into Rust. Trying to make registering a callback from the DOM as clean as implementing a button click handler in C# is just a nightmare.
The problem is that Rust just isn't good for complicated object graphs. This is where almost any language that's garbage collected, or uses some form of automatic reference counting, shines. And, if you're building a "normal" web application, Rust isn't going to have tangible performance advantage over Java / C# / NodeJS / Python. (Meaning, if you aren't running at Google Scale, there's no tangible performance advantage for Rust.)
Part of what happens in Rust is that it's very hard for a struct to reference itself so it can register event callbacks. You're forced to either make all users of the struct use reference counting, or you have to encapsulate a reference counted type used with callbacks. In a garbage collected language, this kind of hurdle isn't needed. In reference counted languages, registering event handlers just requires a weak reference to yourself to avoid cyclic loops. This is because GC / ARC languages assume the same memory model for all objects; which isn't the case in Rust.
Anyway, to make Rust easier to work with, it needs a way to trade some of the raw, "0-cost-abstraction" advantages for the advantages that come with GC / ARC languages. Need raw performance? Use pure Rust. Just need to get it done? Use a higher-level syntax.
Only if you REALLY need it, like if you're embedding a web server into an existing Rust service. Otherwise, it's going to be very time consuming to do things that are straightforward in other languages.
(TLDR: A Rust++, or "Objective Rust" that simplifies some memory issues could make Rust web ready.)
For the past few months, my occasional hobby has been trying to learn Rust. BUT, I've also spent a considerable amount of time getting up to speed in NodeJS.
Regarding running Rust in the browser with WebAssembly: I've spent DAYS trying to figure out how to hook callbacks into the DOM cleanly. I basically went through the "Game of Life" walkthough, (https://rustwasm.github.io/docs/book/), and then ported all of the JavaScript sides into Rust. Trying to make registering a callback from the DOM as clean as implementing a button click handler in C# is just a nightmare.
The problem is that Rust just isn't good for complicated object graphs. This is where almost any language that's garbage collected, or uses some form of automatic reference counting, shines. And, if you're building a "normal" web application, Rust isn't going to have tangible performance advantage over Java / C# / NodeJS / Python. (Meaning, if you aren't running at Google Scale, there's no tangible performance advantage for Rust.)
Part of what happens in Rust is that it's very hard for a struct to reference itself so it can register event callbacks. You're forced to either make all users of the struct use reference counting, or you have to encapsulate a reference counted type used with callbacks. In a garbage collected language, this kind of hurdle isn't needed. In reference counted languages, registering event handlers just requires a weak reference to yourself to avoid cyclic loops. This is because GC / ARC languages assume the same memory model for all objects; which isn't the case in Rust.
Anyway, to make Rust easier to work with, it needs a way to trade some of the raw, "0-cost-abstraction" advantages for the advantages that come with GC / ARC languages. Need raw performance? Use pure Rust. Just need to get it done? Use a higher-level syntax.
People are making a mistake of evaluating Rust web development exclusively on the basis of performance. If you're doing web development professionally, using Rust will make you more productive and happy. The first few months onboarding with the language are challenging, but working with Rust is a very rewarding experience. The thing about Rust web dev expertise is that once you reach parity in capabilities with that of another language, there's no reason not to use Rust even where performance isn't absolutely necessary. There's no going back once you've gone down the Rust path because you'll be able to build better solutions with even greater velocity than if you were doing so with a dynamic language. Again, the first few months working with Rust are challenging, but it pays off!
So, is there a way for me to use an easy cli command like:
laravel new myapp --jetstream
And have SaaS style teams, admin area, authentication, 2-factor, tailwind layouts, and vue+inertia all configured for me, so I literally just need to build the unique feature parts and not worry about auth/sessions/etc?
laravel new myapp --jetstream
And have SaaS style teams, admin area, authentication, 2-factor, tailwind layouts, and vue+inertia all configured for me, so I literally just need to build the unique feature parts and not worry about auth/sessions/etc?
The open source ecosystem isn't there yet. Actix web and rocket are best positioned to get there soonest. There comes a point where people invest effort into convenience projects such as command line boilerplate generation, but I don't think anyone using Rust right now has this as a priority. Rust crates and modules design make re-use and importing functionality straightforward and explicit. I am not aware of an admin area, but that may very well be what people contribute next. Actix web has the most robust ecosystem at the moment. You'll struggle less than I did because of it (I was an early adopter).
I wrote a tutorial on making a web app and I have some thoughts in general about rust in the final chapter.
https://dev.to/krowemoh/a-web-app-in-rust-17-conclusion-1njd
For the most part you could replace most things with rust but you'll be rolling your own solutions for things that other frameworks already supply. Actix was great to use and has enough middleware that I feel comfortable using it.
I don't see any reason outside of desire though to use rust and actix, python and flask are basically the same thing but easier to write. Luckily I like the language and it is fun so for now I'll continue using it.
It could be rust will be better once you have business logic where the borrow checker could really shine, just making a simple crud is too much glue work such that any programming language would work.
https://dev.to/krowemoh/a-web-app-in-rust-17-conclusion-1njd
For the most part you could replace most things with rust but you'll be rolling your own solutions for things that other frameworks already supply. Actix was great to use and has enough middleware that I feel comfortable using it.
I don't see any reason outside of desire though to use rust and actix, python and flask are basically the same thing but easier to write. Luckily I like the language and it is fun so for now I'll continue using it.
It could be rust will be better once you have business logic where the borrow checker could really shine, just making a simple crud is too much glue work such that any programming language would work.
We all know Rust web frameworks can't go head to head with Rails or Django; in other words, they're probably not the best fit for typical CRUD applications. But what I wonder is if there's yet a Rust web framework or set of libraries that would be a good fit for the type of stateful real-time web application where Phoenix is such a good fit right now. That is, a framework based on something like the actor model, with fault tolerance and clustering, with WebSocket-based channels built atop those actors, and possibly topped off with a real-time thin-client system like Phoenix LiveView. Those things, plus a statically-typed AOT-compiled language with great runtime efficiency like Rust, would be a killer combination.
I don't understand how people are jumping head first into a new technology that is so young. It reminds me of the different js frameworks fads.
Why would you use that in production, with no decent level of certainties about the status of the project long term?
Web is high level scripting, and lower level languages can be used by those high level languages to provide the required speed. The performance of those languages do increase over time with new hardware and discoveries. You can hardly do better than the concise syntax of php or python, depending on your preferences, in terms of performance vs code length.
To me programming has always been about obeying the KISS principle. Does using rust for the web corresponds to that principle? I'm unconvinced. Compare rust code to php code. php might be slower to process big operations, but big operations shouldn't be left to php anyway. php is a high level scripting language. Contribute to php and writing an extension would be a better way to go in my opinion. This or another scripting language.
Web is high level scripting, and lower level languages can be used by those high level languages to provide the required speed. The performance of those languages do increase over time with new hardware and discoveries. You can hardly do better than the concise syntax of php or python, depending on your preferences, in terms of performance vs code length.
To me programming has always been about obeying the KISS principle. Does using rust for the web corresponds to that principle? I'm unconvinced. Compare rust code to php code. php might be slower to process big operations, but big operations shouldn't be left to php anyway. php is a high level scripting language. Contribute to php and writing an extension would be a better way to go in my opinion. This or another scripting language.
Would you rather have an expert in Rust doing web programming in Rust, or a novice in JS doing web programming in JS?
The best language to use is the one you know how to use best. If you know all languages equally well that you're free to choose the ideal language for every project, then sure, that's the way to go.
The best language to use is the one you know how to use best. If you know all languages equally well that you're free to choose the ideal language for every project, then sure, that's the way to go.
For web dev, I would rather have an expert in rust obviously, but I would also rather have an expert in php who expressly choose php over rust for the sake of the kiss principle. Plus he would probably be satisfied with a lower starting salary :-)
But you are right, reality often goes differently than what's thought to be ideal, which is why "perfect" solutions sometimes doesn't gets adopted in favor of a less perfect solution, which leaves the old "perfect" solution forgotten by history.
But you are right, reality often goes differently than what's thought to be ideal, which is why "perfect" solutions sometimes doesn't gets adopted in favor of a less perfect solution, which leaves the old "perfect" solution forgotten by history.
Forgive my ignorance (I haven't done front end web dev in almost a decade), but what is the use case for WebAssembly? What does it enable websites to do that (1) needs to be done within browsers and (2) can't be done with JS?
Also, are there any prominent websites that use WebAssembly? It's shipped with all browsers, but what percentage of users ever make use of it?