5 ms·

> Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well s

by xavxav 4y ago

> Is the Async crew mostly writing web servers and other things that operate using TCP and HTTP? Lower level (eg IP, Eth, network hardware drivers) isn't well supported by rust libs. Nor is higher - we have Flask analogs, but no Django analogs. Something I have never understood is why people want to write web-apps in Rust. I love the language, but honestly, a managed language (like js/ruby/go) is always going to be better suited to the world of web-apps. I feel like this imposes an undue burden on Rust to do everything for everyone which has to break down somewhere

steveklabnik 4y ago
The answer to this question is often one of a few different things: reliability (“we didn’t touch our service for 18 months after deployment and it never ran into issues”), low resource usage (“we decommissioned X servers which saves us $Y/year”), and high performance are common responses.
- otterley 4y ago
  Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.
  - Cyph0n 4y ago
    For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)
  - steveklabnik 4y ago
    It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.
    - deleted 4y ago
      [deleted]
    - otterley 4y ago
      I agree - however, once you cross the border into C linkage/FFI, you’re losing both Go’s and Rust’s safety features. That seems like a wash to me. Besides, people are doing a splendid job writing pure Go libraries. It helps that Go has some fantastic observability tooling to help performance-minded engineers minimize unnecessary heap allocations. Finally, the Go runtime just isn’t that big. A few megabytes, I think. That’s well below the noise floor for most server environments, and it’s far smaller than, say, a Python or Java runtime.
      - steveklabnik 4y ago
        Yes, you're not wrong. I have gotten some threads crossed; I forgot this one is about the server side context. Yes, these sorts of things are often less of an issue than in other contexts. Sometimes it still matters though. Just really depends on what you're doing.
  - the__alchemist 4y ago
    FYSA I upvoted this for teaching me that cool and useful expression!
gbear605 4y ago
For me, I’m currently running a Rust webapp and a Python webapp on a server; both are of similar complexities, and I’m probably a bit better at Python. I keep on having to fix the Python app, because of both OS upgrades and problems with the implementation. The Rust app has been working without any issues for the last three years. For a relatively simple web server, where I don’t need to collaborate with anyone, I’m choosing Rust.
- Taywee 4y ago
  I've got a similar thing. I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded. Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery.
spullara 4y ago
100% agree. It drives me nuts when people use the wrong tool for the job.
- the__alchemist 4y ago
  I'm suspicious this occurs when there are too few tools in a given box. See also: NodeJS.
- therockhead 4y ago
  Are you confident it’s the wrong tool though? Curious have you tried web apps with framework such as Actix ?
  - spullara 4y ago
    If I would write it in C/C++, I would instead write it in Rust. Otherwise I would pick something more appropriate for the job. As far as performance, Java and Rust are neck and neck getting their asses kicked by Javascript (for web apps)! https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db https://www.techempower.com/benchmarks/#section=data-r20&hw=...
    - ssokolow 4y ago
      And yet real-world Rust projects consistently have significantly lower memory footprints than real-world Java projects (with people often commenting on the memory savings they observed from porting away from Java, even just to Node.js) as well as being free of some of Java's most common runtime exceptions.
      - spullara 4y ago
        It doesn't matter for webapps. At all. Further, they don't understand the defaults the JVM uses for maximum throughput. It uses most of your memory on purpose as it expects it is the only process running on your server. Generally you can set the max memory usage to be much lower and get basically the same performance. But who thinks anymore you know?
sonthonax 4y ago
I’ve written quite a lot of rust GRPC web services. The reason being that we wrote a lot of propriety derivatives library code in Rust that we needed to Interface with. We could have wrapped this in python, but to be honest, it just wouldn’t have been worth the effort. I ended up writing something that faced external clients in rust, that had to do traditional web app things, and it was okay. The pros were that you could write idiomatic interfaces to things like auth that wouldn’t look out of place in a Django app. The cons however, was that writing these Interfaces took some non trivial rust knowledge, especially since we did a lot of async rust.
mcronce 4y ago
Better suited in what way? I've written HTTP APIs in all of the above - plus Python and PHP - and choose Rust for new ones 99% of the time. Just recently I had a need for a fairly simple webapp. Whipped up the back end in Rust in, like, an hour; only had to bolt on a couple tests for the single complex bit of business logic, because I have a high degree of confidence that the compiler has me covered for everything else. Now it sits there quietly using 4.9 MiB of physical memory and 1.5 millicores on two of my servers, primarily serving a k8s healthcheck every couple seconds.
- mwcampbell 4y ago
  If you accept the divide between back-end and front-end (and the need to have separate developers for each), this is fine. But I, for one, prefer full-stack server-side frameworks such as Rails, Django, and Phoenix, where the server side does HTML generation, HTML form processing (with CSRF protection), authentication with session cookies, etc. Bonus points if, like Phoenix or ASP.NET Core, the framework has integrated support for real-time applications using WebSockets. AFAIK, Rust doesn't have anything quite this comprehensive, though such a framework could certainly be developed.
  - mcronce 4y ago
    Nope, as far as I know there's no serverside HTML generation crate. Granted, I haven't looked, but I feel like it would have come up on /r/Rust sometime. Everything else you mentioned is out there, although I didn't love the websocket experience the one time I needed them for something.
    - steveklabnik 4y ago
      Most rust web frameworks are server side, and generate HTML, so I’m not sure what you were looking at, but it absolutely exists. Most rust web stuff is server side generated.
      - mcronce 4y ago
Klonoar 4y ago
>Something I have never understood is why people want to write web-apps in Rust. The vast, vast majority of web apps are the same CRUD endpoints and background job queue processing. I would label Rust as mature enough in this regard; I've written quite a few of these and am not left wanting in any regard (short of a clone of Django's automagic admin, but few things get close to this anyway...). When you accept the fact that you're taking in some data, shoving it into the DB, and returning a response, the rest of the Rust ecosystem becomes pretty damn nice - deployment is an absolute breeze compared to some of the other ecosystems (Ruby/Python). I don't need to mess with Docker, I don't need to deal with broken package managers, I can just replace a binary and call restart. It's amazing.
- the__alchemist 4y ago
  Common things webapps use that Rust frameworks don't provide: - High-level DB migrations - Auth - Email - Admin - Templating You get these immediately with eg Django, but not in Rust. I'm not trying to be contrarian; I'm confused, and have never heard an answer about this point.
  - Klonoar 4y ago
    No worries, I don't think you're being contrarian - I think projects that properly do this stuff have trouble rising above the micro-framework-style projects. https://github.com/secretkeysio/jelly-actix-web-starter https://github.com/secretkeysio/jelly-actix-web-starter I put all of this together some time ago, explicitly modeled after Django. This repo isn't up to date with actix-web 4 as I've been too busy with other (paying) work, but it absolutely exists. I've used this for services in production with no issues. I really do need to get time to finish and push the updates though. Mine isn't even the first, I'm pretty sure there are others working in this space. Just needs the right people pushing it.
    - the__alchemist 4y ago
      Oh wow! Very appropriate. Looking forward to seeing this fleshed out when you get more time. Will give it a shot on my next project.
tiew9Vii 4y ago
I don’t find the overhead of Rust to bad for web apps. Saying that I used to write web apps using EJB’s, JSP’s, Apache Struts although have also used NodeJS, various Jamstacks and PHP frameworks, Rails and a bunch of others extensively. At the web level the biggest pain I have is the dev workflow isn’t as nice as the Jamstacks with hot reloading so you can see visual changes immediately in the browser. If doing backend for front end this pain goes away if front end is some NodeJs / php or other app. Why is my preference now Rust? It’s fast and low on system resources. It means I can run my apps at a fraction of the cost compared to other languages. I can package my app in a Docker container that’s single digit MB’s. It’s not that to low level to be an inconvenience and high enough level to be reasonably productive. Being strongly typed and being able to find bugs with the compiler also helps.
Winsaucerer 4y ago
I've been experimenting with Rust for web apps instead of Go, so I haven't used it in anger yet, and have started working on a blog post to get my thoughts straight. My experiments are for web apps that focus on server side rendering with just a little javascript through HTMX and AlpineJS. The main thing I'm finding an issue with Rust so far are things that I could find packages for in Go. The main one is having an oidc helper library that can take various oidc services (github, twitter, etc), and provide me a standardised 'account'. Apart from that, I'm finding the experience nicer overall. Examples: * I have better/easier control over errors in ways that don't clutter up the readability of my handlers. I can easily define global rules about how errors from different systems (database, IO, etc) should be returned to the client. * Compile time checks for things that would fail at runtime in Go, and therefore require more extensive tests base to catch when refactoring --sqlx and askama are examples enabling this (askama is particularly nice for this -- more work to get things to the stage of compiling) * When it finally compiles, it usually just works, due to aforementioned fewer ways for failure at runtime * Can express/encode some functionality much more succinctly than Go * Macros for auto-generating code (though I haven't needed this in Rust yet), where with Go I'd make a small external tool for auto generating code. I use generated code a lot in Go, and even with the new 1.18 release, I see that continuing. With more time for the ecosystem to grow, I can see Rust being just as useful. Apart from the ecosystem and the nice fact that you don't need .await's in Go, I can see Rust being really good for this sort of thing.

by xavxav 4y ago

steveklabnik 4y ago

The answer to this question is often one of a few different things: reliability (“we didn’t touch our service for 18 months after deployment and it never ran into issues”), low resource usage (“we decommissioned X servers which saves us $Y/year”), and high performance are common responses.

otterley 4y ago
Isn't Go pretty close to optimal here, though? C/Rust may use somewhat fewer resources, but when you look at Go's efficiency over, say, scripted languages like Python, Ruby, or JavaScript, further optimization seems like it's gilding the lily.
- Cyph0n 4y ago
  For most use cases, I agree. But Rust is a better option when you also need one or more of the following: a) tight control over allocations b) deterministic performance c) strong data race protection d) zero overhead C interop (e.g., processing audio using ffmpeg)
- steveklabnik 4y ago
  It depends on what you mean by “optimal.” For many cases, sure, it’s not an issue, but Go has a big runtime that needs to exist. And its expectations mean that C FFI is not zero overhead, which is why you see so many pure Go packages, but isn’t appropriate in many of Rust’s use cases, which require zero overhead.
  - deleted 4y ago
    [deleted]
  - otterley 4y ago
    I agree - however, once you cross the border into C linkage/FFI, you’re losing both Go’s and Rust’s safety features. That seems like a wash to me. Besides, people are doing a splendid job writing pure Go libraries. It helps that Go has some fantastic observability tooling to help performance-minded engineers minimize unnecessary heap allocations. Finally, the Go runtime just isn’t that big. A few megabytes, I think. That’s well below the noise floor for most server environments, and it’s far smaller than, say, a Python or Java runtime.
    - steveklabnik 4y ago
      Yes, you're not wrong. I have gotten some threads crossed; I forgot this one is about the server side context. Yes, these sorts of things are often less of an issue than in other contexts. Sometimes it still matters though. Just really depends on what you're doing.
- the__alchemist 4y ago
  FYSA I upvoted this for teaching me that cool and useful expression!

gbear605 4y ago

For me, I’m currently running a Rust webapp and a Python webapp on a server; both are of similar complexities, and I’m probably a bit better at Python. I keep on having to fix the Python app, because of both OS upgrades and problems with the implementation. The Rust app has been working without any issues for the last three years. For a relatively simple web server, where I don’t need to collaborate with anyone, I’m choosing Rust.

Taywee 4y ago
I've got a similar thing. I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded. Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery.

spullara 4y ago

100% agree. It drives me nuts when people use the wrong tool for the job.

the__alchemist 4y ago
I'm suspicious this occurs when there are too few tools in a given box. See also: NodeJS.
therockhead 4y ago
Are you confident it’s the wrong tool though? Curious have you tried web apps with framework such as Actix ?
- spullara 4y ago
  If I would write it in C/C++, I would instead write it in Rust. Otherwise I would pick something more appropriate for the job. As far as performance, Java and Rust are neck and neck getting their asses kicked by Javascript (for web apps)! https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db https://www.techempower.com/benchmarks/#section=data-r20&hw=...
  - ssokolow 4y ago
    And yet real-world Rust projects consistently have significantly lower memory footprints than real-world Java projects (with people often commenting on the memory savings they observed from porting away from Java, even just to Node.js) as well as being free of some of Java's most common runtime exceptions.
    - spullara 4y ago
      It doesn't matter for webapps. At all. Further, they don't understand the defaults the JVM uses for maximum throughput. It uses most of your memory on purpose as it expects it is the only process running on your server. Generally you can set the max memory usage to be much lower and get basically the same performance. But who thinks anymore you know?

sonthonax 4y ago

I’ve written quite a lot of rust GRPC web services. The reason being that we wrote a lot of propriety derivatives library code in Rust that we needed to Interface with. We could have wrapped this in python, but to be honest, it just wouldn’t have been worth the effort. I ended up writing something that faced external clients in rust, that had to do traditional web app things, and it was okay. The pros were that you could write idiomatic interfaces to things like auth that wouldn’t look out of place in a Django app. The cons however, was that writing these Interfaces took some non trivial rust knowledge, especially since we did a lot of async rust.

mcronce 4y ago

Better suited in what way? I've written HTTP APIs in all of the above - plus Python and PHP - and choose Rust for new ones 99% of the time. Just recently I had a need for a fairly simple webapp. Whipped up the back end in Rust in, like, an hour; only had to bolt on a couple tests for the single complex bit of business logic, because I have a high degree of confidence that the compiler has me covered for everything else. Now it sits there quietly using 4.9 MiB of physical memory and 1.5 millicores on two of my servers, primarily serving a k8s healthcheck every couple seconds.

mwcampbell 4y ago
If you accept the divide between back-end and front-end (and the need to have separate developers for each), this is fine. But I, for one, prefer full-stack server-side frameworks such as Rails, Django, and Phoenix, where the server side does HTML generation, HTML form processing (with CSRF protection), authentication with session cookies, etc. Bonus points if, like Phoenix or ASP.NET Core, the framework has integrated support for real-time applications using WebSockets. AFAIK, Rust doesn't have anything quite this comprehensive, though such a framework could certainly be developed.
- mcronce 4y ago
  Nope, as far as I know there's no serverside HTML generation crate. Granted, I haven't looked, but I feel like it would have come up on /r/Rust sometime. Everything else you mentioned is out there, although I didn't love the websocket experience the one time I needed them for something.
  - steveklabnik 4y ago
    Most rust web frameworks are server side, and generate HTML, so I’m not sure what you were looking at, but it absolutely exists. Most rust web stuff is server side generated.
    - mcronce 4y ago

Klonoar 4y ago

>Something I have never understood is why people want to write web-apps in Rust. The vast, vast majority of web apps are the same CRUD endpoints and background job queue processing. I would label Rust as mature enough in this regard; I've written quite a few of these and am not left wanting in any regard (short of a clone of Django's automagic admin, but few things get close to this anyway...). When you accept the fact that you're taking in some data, shoving it into the DB, and returning a response, the rest of the Rust ecosystem becomes pretty damn nice - deployment is an absolute breeze compared to some of the other ecosystems (Ruby/Python). I don't need to mess with Docker, I don't need to deal with broken package managers, I can just replace a binary and call restart. It's amazing.

the__alchemist 4y ago
Common things webapps use that Rust frameworks don't provide: - High-level DB migrations - Auth - Email - Admin - Templating You get these immediately with eg Django, but not in Rust. I'm not trying to be contrarian; I'm confused, and have never heard an answer about this point.
- Klonoar 4y ago
  No worries, I don't think you're being contrarian - I think projects that properly do this stuff have trouble rising above the micro-framework-style projects. https://github.com/secretkeysio/jelly-actix-web-starter https://github.com/secretkeysio/jelly-actix-web-starter I put all of this together some time ago, explicitly modeled after Django. This repo isn't up to date with actix-web 4 as I've been too busy with other (paying) work, but it absolutely exists. I've used this for services in production with no issues. I really do need to get time to finish and push the updates though. Mine isn't even the first, I'm pretty sure there are others working in this space. Just needs the right people pushing it.
  - the__alchemist 4y ago
    Oh wow! Very appropriate. Looking forward to seeing this fleshed out when you get more time. Will give it a shot on my next project.

tiew9Vii 4y ago

I don’t find the overhead of Rust to bad for web apps. Saying that I used to write web apps using EJB’s, JSP’s, Apache Struts although have also used NodeJS, various Jamstacks and PHP frameworks, Rails and a bunch of others extensively. At the web level the biggest pain I have is the dev workflow isn’t as nice as the Jamstacks with hot reloading so you can see visual changes immediately in the browser. If doing backend for front end this pain goes away if front end is some NodeJs / php or other app. Why is my preference now Rust? It’s fast and low on system resources. It means I can run my apps at a fraction of the cost compared to other languages. I can package my app in a Docker container that’s single digit MB’s. It’s not that to low level to be an inconvenience and high enough level to be reasonably productive. Being strongly typed and being able to find bugs with the compiler also helps.

Winsaucerer 4y ago

I've been experimenting with Rust for web apps instead of Go, so I haven't used it in anger yet, and have started working on a blog post to get my thoughts straight. My experiments are for web apps that focus on server side rendering with just a little javascript through HTMX and AlpineJS. The main thing I'm finding an issue with Rust so far are things that I could find packages for in Go. The main one is having an oidc helper library that can take various oidc services (github, twitter, etc), and provide me a standardised 'account'. Apart from that, I'm finding the experience nicer overall. Examples: * I have better/easier control over errors in ways that don't clutter up the readability of my handlers. I can easily define global rules about how errors from different systems (database, IO, etc) should be returned to the client. * Compile time checks for things that would fail at runtime in Go, and therefore require more extensive tests base to catch when refactoring --sqlx and askama are examples enabling this (askama is particularly nice for this -- more work to get things to the stage of compiling) * When it finally compiles, it usually just works, due to aforementioned fewer ways for failure at runtime * Can express/encode some functionality much more succinctly than Go * Macros for auto-generating code (though I haven't needed this in Rust yet), where with Go I'd make a small external tool for auto generating code. I use generated code a lot in Go, and even with the new 1.18 release, I see that continuing. With more time for the ecosystem to grow, I can see Rust being just as useful. Apart from the ecosystem and the nice fact that you don't need .await's in Go, I can see Rust being really good for this sort of thing.