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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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?
> Rust can even run on the browser, by compiling to WebAssembly .
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?
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].
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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)
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 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.
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.
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.
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.
[+] [-] hugodutka|5 years ago|reply
> 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.
[+] [-] ibraheemdev|5 years ago|reply
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.
[+] [-] squeral|5 years ago|reply
[+] [-] devsquid|5 years ago|reply
[+] [-] akmittal|5 years ago|reply
[+] [-] bluejekyll|5 years ago|reply
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.
[+] [-] joelbluminator|5 years ago|reply
[+] [-] rethab|5 years ago|reply
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.
[+] [-] 40four|5 years ago|reply
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.
[+] [-] jkoudys|5 years ago|reply
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.
[+] [-] flohofwoe|5 years ago|reply
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.
[+] [-] kissgyorgy|5 years ago|reply
[+] [-] ufmace|5 years ago|reply
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.
[+] [-] gremlinsinc|5 years ago|reply
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.
[+] [-] _huayra_|5 years ago|reply
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/
[+] [-] darthrupert|5 years ago|reply
[+] [-] txdv|5 years ago|reply
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.
[+] [-] _cobe_bero__|5 years ago|reply
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
[+] [-] _cobe_bero__|5 years ago|reply
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.
[+] [-] ablekh|5 years ago|reply
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.
[+] [-] galfarragem|5 years ago|reply
[+] [-] Dowwie|5 years ago|reply
[+] [-] gremlinsinc|5 years ago|reply
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?
[+] [-] notRobot|5 years ago|reply
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?
[+] [-] shrumm|5 years ago|reply
[1] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
[+] [-] sbelskie|5 years ago|reply
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.
[+] [-] kthxb|5 years ago|reply
[+] [-] pansa2|5 years ago|reply
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.
[+] [-] Closi|5 years ago|reply
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?
[+] [-] tester34|5 years ago|reply
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.
[+] [-] ben-schaaf|5 years ago|reply
[+] [-] eloisius|5 years ago|reply
[+] [-] brohee|5 years ago|reply
[+] [-] m12k|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] sradman|5 years ago|reply
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.
[+] [-] kevingadd|5 years ago|reply
[+] [-] threeseed|5 years ago|reply
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.
[+] [-] jlg23|5 years ago|reply
[+] [-] arrayjumper|5 years ago|reply
[+] [-] k__|5 years ago|reply
[+] [-] akudha|5 years ago|reply
[+] [-] hknd|5 years ago|reply
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)
[+] [-] secondcoming|5 years ago|reply
[+] [-] speedgoose|5 years ago|reply
I would recommend Rust over Typescript, if you are going to spend time on types, use Rust it's more worth it.
[+] [-] k__|5 years ago|reply
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.
[+] [-] ronanyeah|5 years ago|reply
---
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
[+] [-] qaq|5 years ago|reply
[+] [-] georgesC|5 years ago|reply
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.
[+] [-] lipanski|5 years ago|reply
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.