36 ms·

Rust Is Surprisingly Good as a Server Language

309 points by signa11 6y ago

0xDEEPFAC 6y ago
You guys think Rust is good - you should check out Ada++ (you'll have to build GCC yourself though) http://www.adapplang.com http://www.adapplang.com
- Elinvynia 6y ago
  Does it provide the same/better safety guarantees as Rust? The website has extremely limited information about the language.
  - DoingIsLearning 6y ago
    I can't confirm what is the motivation behind Ada++, but actual Ada2012 standard and in particular the Ada SPARK (2014) subset is in many ways objectively superior to Rust with regards to memory safety. One major issue with Ada is that commercial grade compilers are not cheap and for the most part the language was unable to get rid of the stereotype of being an Aerospace/Defense language only. Some discussion on the topic: https://www.quora.com/How-secure-is-Ada-the-programming-language https://www.quora.com/How-secure-is-Ada-the-programming-lang...? https://ada2012.org/comparison.html https://ada2012.org/comparison.html https://www.adacore.com/about-spark https://www.adacore.com/about-spark
    - imtringued 6y ago
      Does Ada have a substructural type system [0]? If not, then it's not even in the same league as Rust. [0] https://en.wikipedia.org/wiki/Substructural_type_system https://en.wikipedia.org/wiki/Substructural_type_system
      - DoingIsLearning 6y ago
        From the Ada standard: https://en.wikibooks.org/wiki/Ada_Programming/Types/access https://en.wikibooks.org/wiki/Ada_Programming/Types/access More importantly the previous discussion on Ada SPARK 2014 'safe pointers' may also be an interesting read for proponents of a Substructural Type System: https://news.ycombinator.com/item?id=15874273 https://news.ycombinator.com/item?id=15874273
- throw_m239339 6y ago
  There is so little information on the page you linked that I doubt this project is production ready in any shape and form. Ada webdev is already though as it is, I doubt that project can compare to rust.
  - 0xDEEPFAC 6y ago
    It is an Ada compiler with modified syntax. The GNAT Ada compiler is used by defense contractors, air traffic controllers, and NVIDIA for some of their internal research. Its production ready.
cft 6y ago
I took an example of a server straight from the Rust async book, and to my surprise, it performed very well for a long time serving real internet requests till I actually had to modify it: https://rust-lang.github.io/async-book/01_getting_started/05_http_server_example.html https://rust-lang.github.io/async-book/01_getting_started/05... My server processes JSON requests and returns JSON and also serves a couple of static files that I simply read with include_bytes!("../files/index.html") Once you understand Rust async model (which I recommend as a mental exercise for any programmer), it's all very simple.
golergka 6y ago
I started learning Rusit and using it for hobby projects in 2014, but I have to agree: for a full-blown product development it's just not there yet. Static typing your code up to the point where you can assume it's correct if it compiles and managing memory manually without the need for a garbage collector, these two things alone just light up my inner nerd with excitement. But as an engineer who has to deliver a product in time and in a maintainable shape (which means "hiring considerations"), I just can't excuse using Rust instead of NodeJS or Python. Web servers that work on request/response model are ideally suited for garbage collection, and just as OP says, they're IO bound, not CPU bound. All these wonderful things that Rust offers are just not that important in the real world. But if I ever have to write a small (in terms of requirements and potential LOC, not load), atomic, CPU-bound microservice that will probably not require a lot of maintenance work, Rust will be my first choice.
- rubber_duck 6y ago
  I think Rust is past the hiring hurdle and you would probably get the opposite effect - I suspect you would get more higher quality applicants just looking for a chance to work with it. Seen a similar story with a team choosing RoR over Clojure years back.
  - golergka 6y ago
    Higher quality, but all seniors with salary expectations to match. Using a senior developer to maintain a couple of services is both a misuse of his salary and a good way to bore him to death.
- jfkebwjsbx 6y ago
  People is downvoting you, but you are correct. Rust is ideal for CPU-bound problems were performance is critical. For typical web services, not so much. It is hard to justify the extra development cost, even if hiring were easy (which it isn't in the majority of the world).
jph 6y ago
I'm building with Rust, Rocket, Diesel, and agree with much of the original article. I can also add more: in my direct personal experience, the lead people creating Rocket and Diesel are superb about responsiveness, ongoing communication, and enabling people (e.g. me) to help diagnose issues and fix the them. I'm continually thankful for the quality of participation among the people in the ecosystem. On the technical side, there are definitely some learning curves among Rocket, Diesel, and other tools. A typical example is that different crates have their own implementations of concepts such as a UUID, and the developer must handle conversions, and also ensure that various dependency versions all align, and also can't (yet) easily use the current UUID crate, and also can't (yet) build using stable Rust. All of these aspects will be fixed soon, likely within a month or so as the crates stabilize. If you try Rust, I highly recommend trying rust-analyzer, which provides near-real-time code advice as a plugin to most major editors.
- thepratt 6y ago
  Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.
  - jph 6y ago
    Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.
    - estebank 6y ago
      Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly. Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.
Nican 6y ago
There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pretty simple. But having all the tools around it to build a production level service is a different story.
- pestaa 6y ago
  What is your take on TypeScript, what is it you don't like?
  - jamil7 6y ago
    Not the OP but my take is that Typescript has done great things for improving JS but it's still JS and carries a lot of it's baggage with it. There is only so far you can take it while maintaining compatibility and the type system is overly complicated in places because of this. It also doesn't really give you the same guarantees that something like Rust does, I don't believe the two type systems are that comparable. On top of that unless you use all TS packages types are maintained and installed separately adding to an already tricky to maintain dependency graph that comes with Node development.
  - Nican 6y ago
    I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs. 1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2] 4. Sometimes libraries does not use async correctly, and breaks stack traces. 5. Sometimes TypeScript's generic errors can be as bad as C++. My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people. [1] https://github.com/hapijs/hapi/issues/4111 https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)
chrismorgan 6y ago
On the set_expires thing, the docs are at https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#method.set_expires https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#..., and “Tm” is a clickable link. Rocket 0.4 is using version 0.1 of the time crate, and the snippet in this article that looks into the time crate docs is looking at completely the wrong thing, time::Time::now from 0.2, which gets the time of day (which also, I think, helps explain the deprecation reason, because time of day in UTC is extremely seldom useful and can easily be obtained otherwise, while a full date + time in UTC is useful), rather than time::now from 0.1, which gets a timestamp. Discussion of this article on /r/rust: https://old.reddit.com/r/rust/comments/hpzmeu/rust_is_surprisingly_good_as_a_server_language/ https://old.reddit.com/r/rust/comments/hpzmeu/rust_is_surpri...
privacyonsec 6y ago
what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.
- privacyonsec 6y ago
  I really don't understand the down votes :) yes I've been working on python applications and live patching code for emergency, our app was deployed and running on 64 different machines. I'm not talking about coding in production or whatever, of course once the workaround is done on production a proper solution is implemented and deployed. why restarting ? when you can reload the new code of the app while it's running ? no service interruption worked for us for years ! but yeah, I agree, better having 4 eyes while patching on prod :)
- brobinson 6y ago
  I've been writing Python for a few years now (at my job), and most of the situations where I've used breakpoint() to debug something would literally not have been possible in Rust because they would have been compile time errors instead of runtime errors.
- jamil7 6y ago
  This really only works in the case that you have one server running a python app that you can ssh into. Any deployments more complicated than that and it starts to break down.
- chrismorgan 6y ago
  I don’t think I’ve ever seen anyone try live-patching a Python server. Modifying the code and restarting the server, sure. Modifying Django templates and having the updates show immediately, sure.¹ But modifying the code and restarting the server is logically equivalent to modifying the Rust code, rebuilding it and restarting it. Any finer live-patching in Python is risky, largely only safe to do at defined boundaries. Modifying code is a hazardous operation, because it depends on how things use it. Patching module.function only helps places that import module and call module.function, for example, not places that use `from module import function`. So, simplifying drastically, you can mostly only really modify singletons, and singletons that have been designed to be modified in this way. In Rust, you can define such boundaries, and manipulate things like configuration when you’ve decided you want them to be modifiable, perhaps within a debugger, or more likely via some exposed API (maybe a web API). To be sure, Rust is less flexible: all such extension points must be designed in, rather than often working by accident (though the Python way is very likely to blow up in your face from time to time). But in the end I don’t think it’s such a big difference. (On reflection, I suppose I have seen a debugger used in the scope of a particular request within Django, to give you a pdb prompt instead of just the 500 error page. But that’s then just used for inspecting what’s broken, and most such brokennesses would have been caught by the Rust compiler. Still, something equivalent to that could be nice to have in a Rust development web server; I don’t believe any such thing exists at present, but it could in theory and might be interesting to make. It would still definitely be more limited than pdb. Maybe when we have a Miri-powered REPL something interesting will happen in this space. It’s not a fundamentally impossible space.) ¹ If that works, by the way, you should set up the cached template loader, as it’ll speed template rendering up a lot. That used to be something you’d have to do manually, but now the default template loaders configuration includes caching if debug is False.
akoncius 6y ago
https://stu2b50.dev/posts/tag/culture https://stu2b50.dev/posts/tag/culture on tag page it’s possible to see drafts :)
tanilama 6y ago
I think as of today, if the server side of programming we are talking about is really web application, languages don't matter. Pick one you are familiar with, the language the toolchain and the overall ecosystem, it should just work.
lmm 6y ago
Why wouldn't you just use OCaml, Haskell, F#, or Scala, where you've got much more mature web framework options? Don't get me wrong, Rust is fine, but if you don't need its memory management then why make trouble for yourself?
- deleted 6y ago
  [deleted]
- riquito 6y ago
  It's in the preface > The project is simple enough that I can't imagine being too limited by any language's ecosystem. And I've been itching to write something substansive [sic] in Rust...
- vghaisas 6y ago
  I think it's also a bit of a chicken and egg problem: If no one uses Rust for web servers then its ecosystem won't ever mature. If there are people willing to deal with some rough edges, that's great and will help the ecosystem mature.
- Lio 6y ago
  Rust is interesting in that it may eventually end up as a very useful language for WASM work. Rust has the advantage that when compiled to WASM it won't require a runtime library. So the prospect of Rust as a fast, low overhead, use anywhere language is tempting. Since Rust is a relatively new language it's worth checking to see how it's maturing over time against small low risk projects exactly as the author has done. Rust may not be a perfect fit right now but that may change. So it's very valid to test one's assumptions from time to time. Or to put it another way, working in one of the languages you've mentioned wouldn't answer the question "how suitable is Rust for web server work right now?"
  - jfkebwjsbx 6y ago
    All that applies to several other very mature languages that can target WASM, like C. Nevertheless, WASM is not ideal for server work. It is intended for the frontend.
IAmEveryone 6y ago
Reading this I can't help but be lost trying to come up with any alternative solution for this specific use case that is worse than what they describe? A bunch of mostly static blogs can be hand-edited HTML, or some ancient perl script, or any of the existing static site generators. If it absolutely needs to involve server-side logic, it could be completely accomplished within a single call to ```rails init```, and the resulting project would incorporate a few $billion worth of collective experience commonly refered to as "best practice". It would be far easier to modify and far less likely to contain vulnerabilities. Performance would be worse by a factor of maybe x100, or "why are you asking these weird questions?" when converted to the real world, according to a representative survey of end users. There's a good argument for replacing individual components on, say, the critical path for rendering people's twitter feed with lower-level implementations. But it strikes me as unlikely that such endeavours would care about the ability of their ORM to quickly generate the migration scripts to drop or add some database columns. So I can't quite see the benefit of cramming the rails model into Rust? Rails is spectacular in how it allows you to quickly iterate, adapt your data model, try some ideas, and so on. Those are qualities that just logically do not transfer to a world of static typing and manual memory management.
GolDDranks 6y ago
Not the point of the article, so sorry about offtopic, but the workflow described in the first chapter feels a bit off. If they wanted dynamism, then writing a server is the way to go, but it seems that the easier fix to their problems as described there, would have been setting an automated CD pipeline that would build and deploy their blog every time you make a change.
johnfn 6y ago
I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. The long compile times completely kill any enjoyment or flow that I normally get out of productive programming. Even worse, I found myself anxious to introduce new dependencies, because each new crate would add a few more seconds to the compile time, which immediately correlates to less coding enjoyment. I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. I have a theory: there must be two groups of engineers. One group loves fast compile times and quickly validating hypotheses. The other group must value thinking about their code a lot more than running it, and so compile times aren't that important. My guess is that, while the second group hangs around and loves Rust, Rust has completely driven away the first group (including myself) to the degree that they don't use the language enough to even fill out the surveys. Anyways, I know it has a wide swath of use cases, mostly in systems programming. I'm just bummed that if I ever do any of them, I won't really enjoy it. :-( [EDIT:] Gotta go to sleep, it's far too late here. I really appreciate all the thoughtful replies. Rust's amazing community is another reason it annoys me that I can't fully get into the language as I'd like to.
- FridgeSeal 6y ago
  I find that the strong type system and editor plugins like Rust Analyzer have me covered for “does this do what I expect?”, which means I do way less write-run-check than I would I say, Python.
- byteofbits 6y ago
  As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day. I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to. There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I work on REST API systems - so nothing too crazy).
colesantiago 6y ago
Is there anything like Rails for Rust?
- vghaisas 6y ago
  I don't think any Rust web framework provides as much as Rails does, but you can see the current state of them here: https://www.arewewebyet.org/topics/frameworks/ https://www.arewewebyet.org/topics/frameworks/
eximius 6y ago
I wonder if there is a need or appetite for large libraries like Apache commons or Guava in Java which cut down on dependency count. It's an alternative to a myriad of small, unaudited libraries. Rust does have some projects going to audit those small libraries, though.
pantulis 6y ago
In my opinion, the section which the author called "the ugly" makes it clear that it's not that surprisingly good as a application server language. A file upload is a basic feature that has already been solved yet Rust code contains a lot of boilerplate when compared with Python. Remember the mantra from the 2010's when the dynamic typing craze? Rust is not about optimizing developer time, it's about guaranteeing safety for base sysstems software. All this permanent reasoning about ownership, borrowing and so on makes it the greatest contender against C++ (hence Mozilla and Microsoft support) but in terms of productivity you'd be best served with a higher level, GC-collected platform for an application.
- sanxiyn 6y ago
  The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.
  - zozbot234 6y ago
    > And file upload can be solved by just more code. Yes, but it's a papercut. How many other papercuts are there, compared to more developed ecosystems for this domain? That's not an easy question to address.
    - pantulis 6y ago
      Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust. Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.
      - monadic2 6y ago
        Conversely, active record can’t generate the SQL you can learn in a few minutes in a database class. I’d much rather have highly precise sql serialization and deserialization code and emphasis on minimal client overhead in a systems language than the ability to rapidly spike a data model and query it in the space of a PowerPoint slide.
rwmj 6y ago
Why wouldn't you want a garbage collected language for developing web services? Developer time is at a premium, lots of RAM, likely a single environment managing multiple requests so the GC gets a global overview, and because of network variability you're unlikely to be doing anything with realtime constraints.
- IshKebab 6y ago
  GC pauses in some languages are not good (Go put a lot of effort into fixing this). That's about it, but Rust is good for reasons other than its lack of GC. The type system is very robust, which means fewer runtime errors. The standard library is pretty great, even if parts of it are third party de facto standards (serde, crossbeam, etc.). It's much more expressive than Go. Much faster than Python.
- sanxiyn 6y ago
  The point of the article is that surprisingly, lack of GC does not hurt developer time.
  - joppy 6y ago
    A simple web server barely needs GC - allocate anything and everything needed during a single request from the same pool, and free the pool once the request is handled. The lack of GC can hurt developer time for other kinds of work, where the lifetime of data structures are not scoped to “within a request”.
echelon 6y ago
I've built a few web services in Rust, and I've been incredibly pleased by the existing ecosystem as well as how easy it is to develop concurrent solutions for CPU-intensive tasks. https://vo.codes https://vo.codes is a text to speech service written in Rust and it performs really well. Any service failures are simply my poor proxy implementation - the core TTS service itself scales very predictably.
csomar 6y ago
I'm working with Rust as a backend right now and can echo the Diesel experience. The issue is that there is not really much of a choice, it is either Diesel or not. So you have to stick with that. Another problem is that most OS projects in Rust are maintained by 1-2 persons who are not working on the project fulltime. That's not the case for JavaScript/Node as there are order of magnitudes more projects and people working in these platforms. His last example could be improved a lot with the "?" keyword. That would remove lots of wrapping and simplify the code greatly. So it's not that bad really.
marvinblum 6y ago
I had a similar idea for my blog [1], with almost identical goals, but I wrote it in Go. Rust is on my to-learn list, but I find it harder to read from the code samples in the article and what I saw on other websites. I guess I will stick to Go for business logic. When would you guys chose Rust over something else, like Go? [1] https://marvinblum.de/blog/how-i-built-my-website-using-emvi-as-a-headless-cms-RGaqOqK18w https://marvinblum.de/blog/how-i-built-my-website-using-emvi...
- nkozyra 6y ago
  Go comes with more tools to do what you want with stdlib. It'll be easier to do this with go than learning rust and the required dependency. So that's one answer: forcing yourself to learn more about a languages environment and ecosystem. Another answer might be: "I already know/prefer rust." I'd be surprised if there were much/any performance benefit.
  - marvinblum 6y ago
    I thought about getting back into game development. Nothing fancy, just some 2D experiements. I haven't looked into Vulcan/OpenGL bindings for Go in a while, but I remember that it wasn't really recommended. Maybe I'll give Rust a shot one day to do that.
fooyc 6y ago
It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Rust is ground breaking in some areas, but also completely lacks innovation in others. But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? [1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- steveklabnik 6y ago
  > This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Already in Rust many libraries can be written completely agnostic of the underyling executor. Some cannot; we have a bit more interface work to do, but there's nothing inherent about this, it's solely a standardization issue that's being worked on. Sounds like they ran into the latter more than the former, which is unfortunate, but should be better in the future. > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? It is not!
- mlindner 6y ago
  One of the core facets of Rust is that you don't pay for what you don't use. If everything was async by default then code that wasn't async would pay the cost of it. Async isn't free.
- CJefferson 6y ago
  I would love to see some quality benchmarking of a non-trivial threaded solver in Rust. As strongly suspect it will perform "well enough" (hopefully much better than async in Python, and hopefull javascript too), which is good enough for me to be able to escape async.
- estebank 6y ago
jxub 6y ago
To the author: "per say" should be "per se". Good article anyway.
kristianpaul 6y ago
“ honestly some of the Rust ecosystem reminds me of the NPM. My end release build needs to compile 267 different libraries, before getting to my code, and that's for my simple little blogging engine.” <- Thats something i had to agree with With lately , i guess is part of the good and bad of having a growing community. So spend time picking the crates that make you feel more safe
ragnese 6y ago
I'm glad to see this post here. Just because I hear/read a lot of people outright dismiss Rust's potential here with arguments that kind of miss the point: 1. You don't need CPU performance for most web stuff. It's all IO bound. 2. Related to #1, garbage collectors are fine and you don't need the Rust model. 3. Rust is so hard to learn that it isn't worth it unless you need the performance. There's so much more to Rust than the performance. It hits a really nice sweet spot between being expressive and letting you take as much control as you want/need. Sometimes GC'd languages are a pain in the butt because I just want a damned destructor and I would like to be able to guess when/if it's gonna run. And, frankly, Rust isn't that hard. It's an imperative language. It's not Haskell.
- koheripbal 6y ago
  Can someone elaborate on why #2 is wrong on the server level? My systems are not performance bottleneck'd and as a Java dev I'm more worried about the potential for memory bugs (which I admit I will create) if I stray away from automatic garbage collection.
  - ragnese 6y ago
    It's not wrong. I didn't mean to imply that. I just mean that saying non-GC languages are about performance overhead of the garbage collector is missing the point. Sometimes, it's convenient and easier to reason about stuff when you can predict when something is actually dropped from memory. And in Rust, you wouldn't create those memory bugs you're worried about. (Well, you can, but you have to go out of your way to take the safety off :)) That's kind of Rust's whole "shtick"
    - koheripbal 6y ago
      You can absolutely create memory leaks in Rust [1]. That's a bigger problem for server applications than CPU / Memory performance issues, because the latter can be traced more easily. As a (mediocre) dev and head of a team (some are great, and some are as bad as me), I'm far more worried about bugs than performance. [1] https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust https://stackoverflow.com/questions/55553048/is-it-possible-...
finder83 6y ago
I've taken the deep dive into Rust API service development the past few weeks. I really enjoy the experience of developing in Rust, but not so much the experience of using Rust web frameworks, somewhat in line with the author. In particular, even having a relatively small set of feature requirements it has been difficult finding a web framework that supports: Middleware, Websockets, easy routing, and async handlers. Actix probably supports all of those, but I don't much like development in it and prefer to avoid the drama of Actix. Surprisingly, none of the other libraries I've looked at support all of those (except possibly Gotham, but I ran into other issues with it). I'm not sure what my takeaway is, other than that web frameworks still have a ways to go, and development on each of these web frameworks seems slow, I think because of the lack of companies picking them up. I also get the impression that people are somewhat obsessed with doing it the "Rust way", rather than just getting a simple completed web framework out the door. However, I love working in Rust, and think I may reach a point where I'm actually more productive in it than something like Typescript. There's just a large learning curve. But it's fun.
grok22 6y ago
I find the title surprisingly annoying. What the heck is "surprisingly good"? As compared to what? (I know, I know; reading the article would've clarified). And what the fuck is a "server language"? The title made me want to not read the article just to come to know of yet another new developer come in contact with something they haven't used before and make obvious or irrelevant pronouncements like they discovered something new. Or maybe I am just growing old :-).

309 points by signa11 6y ago

You guys think Rust is good - you should check out Ada++ (you'll have to build GCC yourself though) http://www.adapplang.com http://www.adapplang.com

Elinvynia 6y ago
Does it provide the same/better safety guarantees as Rust? The website has extremely limited information about the language.
- DoingIsLearning 6y ago
  I can't confirm what is the motivation behind Ada++, but actual Ada2012 standard and in particular the Ada SPARK (2014) subset is in many ways objectively superior to Rust with regards to memory safety. One major issue with Ada is that commercial grade compilers are not cheap and for the most part the language was unable to get rid of the stereotype of being an Aerospace/Defense language only. Some discussion on the topic: https://www.quora.com/How-secure-is-Ada-the-programming-language https://www.quora.com/How-secure-is-Ada-the-programming-lang...? https://ada2012.org/comparison.html https://ada2012.org/comparison.html https://www.adacore.com/about-spark https://www.adacore.com/about-spark
  - imtringued 6y ago
    Does Ada have a substructural type system [0]? If not, then it's not even in the same league as Rust. [0] https://en.wikipedia.org/wiki/Substructural_type_system https://en.wikipedia.org/wiki/Substructural_type_system
    - DoingIsLearning 6y ago
      From the Ada standard: https://en.wikibooks.org/wiki/Ada_Programming/Types/access https://en.wikibooks.org/wiki/Ada_Programming/Types/access More importantly the previous discussion on Ada SPARK 2014 'safe pointers' may also be an interesting read for proponents of a Substructural Type System: https://news.ycombinator.com/item?id=15874273 https://news.ycombinator.com/item?id=15874273
throw_m239339 6y ago
There is so little information on the page you linked that I doubt this project is production ready in any shape and form. Ada webdev is already though as it is, I doubt that project can compare to rust.
- 0xDEEPFAC 6y ago
  It is an Ada compiler with modified syntax. The GNAT Ada compiler is used by defense contractors, air traffic controllers, and NVIDIA for some of their internal research. Its production ready.

cft 6y ago

I took an example of a server straight from the Rust async book, and to my surprise, it performed very well for a long time serving real internet requests till I actually had to modify it: https://rust-lang.github.io/async-book/01_getting_started/05_http_server_example.html https://rust-lang.github.io/async-book/01_getting_started/05... My server processes JSON requests and returns JSON and also serves a couple of static files that I simply read with include_bytes!("../files/index.html") Once you understand Rust async model (which I recommend as a mental exercise for any programmer), it's all very simple.

golergka 6y ago

I started learning Rusit and using it for hobby projects in 2014, but I have to agree: for a full-blown product development it's just not there yet. Static typing your code up to the point where you can assume it's correct if it compiles and managing memory manually without the need for a garbage collector, these two things alone just light up my inner nerd with excitement. But as an engineer who has to deliver a product in time and in a maintainable shape (which means "hiring considerations"), I just can't excuse using Rust instead of NodeJS or Python. Web servers that work on request/response model are ideally suited for garbage collection, and just as OP says, they're IO bound, not CPU bound. All these wonderful things that Rust offers are just not that important in the real world. But if I ever have to write a small (in terms of requirements and potential LOC, not load), atomic, CPU-bound microservice that will probably not require a lot of maintenance work, Rust will be my first choice.

rubber_duck 6y ago
I think Rust is past the hiring hurdle and you would probably get the opposite effect - I suspect you would get more higher quality applicants just looking for a chance to work with it. Seen a similar story with a team choosing RoR over Clojure years back.
- golergka 6y ago
  Higher quality, but all seniors with salary expectations to match. Using a senior developer to maintain a couple of services is both a misuse of his salary and a good way to bore him to death.
jfkebwjsbx 6y ago
People is downvoting you, but you are correct. Rust is ideal for CPU-bound problems were performance is critical. For typical web services, not so much. It is hard to justify the extra development cost, even if hiring were easy (which it isn't in the majority of the world).

jph 6y ago

I'm building with Rust, Rocket, Diesel, and agree with much of the original article. I can also add more: in my direct personal experience, the lead people creating Rocket and Diesel are superb about responsiveness, ongoing communication, and enabling people (e.g. me) to help diagnose issues and fix the them. I'm continually thankful for the quality of participation among the people in the ecosystem. On the technical side, there are definitely some learning curves among Rocket, Diesel, and other tools. A typical example is that different crates have their own implementations of concepts such as a UUID, and the developer must handle conversions, and also ensure that various dependency versions all align, and also can't (yet) easily use the current UUID crate, and also can't (yet) build using stable Rust. All of these aspects will be fixed soon, likely within a month or so as the crates stabilize. If you try Rust, I highly recommend trying rust-analyzer, which provides near-real-time code advice as a plugin to most major editors.

thepratt 6y ago
Does having to develop against rust nightly over stable not worry you when attempting to productionize a service? I understand new features get shipped behind feature flags/language pragmas, but it seems like a massive looming risk.
- jph 6y ago
  Developing based on Rust nightly has caused some learning curve gotchas, such as discovering a POSIX bug in the Rust install script, or needing to write a custom Docker Alpine Rust nightly container, or needing to write small system scripts to ensure that nightly is the same version on our various build machines. So far we've seen about 2/3 of nights fail for our code. The failure is totally obvious. So we revert to the previous night that we know works.
  - estebank 6y ago
    Depending on the level of maturity of the nightly features you rely on, for CI there is an env variable that makes the stable compiler think it is nightly. We use this flag at day job to use latest stable but be able to enable a handful of quasi stable nightly features (custom testing frameworks mainly and getting rocket to play nice). This is a double edged sword: it is the same as a pinned nightly in the sense that it is a static target, but differs in that bugs affecting stable and beta have been backported where any arbitrary nightly has no assurances one way or another, but bugs affecting nightly features aren't backported to the stable release and only fixed on nightly. Also, for the love all that is holy do not publish a crate relying on that flag to enable the nightly features, it breaks the languages stability assurances and by extension the ecosystem.

Nican 6y ago

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pretty simple. But having all the tools around it to build a production level service is a different story.

pestaa 6y ago
What is your take on TypeScript, what is it you don't like?
- jamil7 6y ago
  Not the OP but my take is that Typescript has done great things for improving JS but it's still JS and carries a lot of it's baggage with it. There is only so far you can take it while maintaining compatibility and the type system is overly complicated in places because of this. It also doesn't really give you the same guarantees that something like Rust does, I don't believe the two type systems are that comparable. On top of that unless you use all TS packages types are maintained and installed separately adding to an already tricky to maintain dependency graph that comes with Node development.
- Nican 6y ago
  I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs. 1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2] 4. Sometimes libraries does not use async correctly, and breaks stack traces. 5. Sometimes TypeScript's generic errors can be as bad as C++. My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people. [1] https://github.com/hapijs/hapi/issues/4111 https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)

chrismorgan 6y ago

On the set_expires thing, the docs are at https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#method.set_expires https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#..., and “Tm” is a clickable link. Rocket 0.4 is using version 0.1 of the time crate, and the snippet in this article that looks into the time crate docs is looking at completely the wrong thing, time::Time::now from 0.2, which gets the time of day (which also, I think, helps explain the deprecation reason, because time of day in UTC is extremely seldom useful and can easily be obtained otherwise, while a full date + time in UTC is useful), rather than time::now from 0.1, which gets a timestamp. Discussion of this article on /r/rust: https://old.reddit.com/r/rust/comments/hpzmeu/rust_is_surprisingly_good_as_a_server_language/ https://old.reddit.com/r/rust/comments/hpzmeu/rust_is_surpri...

privacyonsec 6y ago

what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.

privacyonsec 6y ago
I really don't understand the down votes :) yes I've been working on python applications and live patching code for emergency, our app was deployed and running on 64 different machines. I'm not talking about coding in production or whatever, of course once the workaround is done on production a proper solution is implemented and deployed. why restarting ? when you can reload the new code of the app while it's running ? no service interruption worked for us for years ! but yeah, I agree, better having 4 eyes while patching on prod :)
brobinson 6y ago
I've been writing Python for a few years now (at my job), and most of the situations where I've used breakpoint() to debug something would literally not have been possible in Rust because they would have been compile time errors instead of runtime errors.
jamil7 6y ago
This really only works in the case that you have one server running a python app that you can ssh into. Any deployments more complicated than that and it starts to break down.
chrismorgan 6y ago
I don’t think I’ve ever seen anyone try live-patching a Python server. Modifying the code and restarting the server, sure. Modifying Django templates and having the updates show immediately, sure.¹ But modifying the code and restarting the server is logically equivalent to modifying the Rust code, rebuilding it and restarting it. Any finer live-patching in Python is risky, largely only safe to do at defined boundaries. Modifying code is a hazardous operation, because it depends on how things use it. Patching module.function only helps places that import module and call module.function, for example, not places that use `from module import function`. So, simplifying drastically, you can mostly only really modify singletons, and singletons that have been designed to be modified in this way. In Rust, you can define such boundaries, and manipulate things like configuration when you’ve decided you want them to be modifiable, perhaps within a debugger, or more likely via some exposed API (maybe a web API). To be sure, Rust is less flexible: all such extension points must be designed in, rather than often working by accident (though the Python way is very likely to blow up in your face from time to time). But in the end I don’t think it’s such a big difference. (On reflection, I suppose I have seen a debugger used in the scope of a particular request within Django, to give you a pdb prompt instead of just the 500 error page. But that’s then just used for inspecting what’s broken, and most such brokennesses would have been caught by the Rust compiler. Still, something equivalent to that could be nice to have in a Rust development web server; I don’t believe any such thing exists at present, but it could in theory and might be interesting to make. It would still definitely be more limited than pdb. Maybe when we have a Miri-powered REPL something interesting will happen in this space. It’s not a fundamentally impossible space.) ¹ If that works, by the way, you should set up the cached template loader, as it’ll speed template rendering up a lot. That used to be something you’d have to do manually, but now the default template loaders configuration includes caching if debug is False.

akoncius 6y ago

https://stu2b50.dev/posts/tag/culture https://stu2b50.dev/posts/tag/culture on tag page it’s possible to see drafts :)

tanilama 6y ago

I think as of today, if the server side of programming we are talking about is really web application, languages don't matter. Pick one you are familiar with, the language the toolchain and the overall ecosystem, it should just work.

lmm 6y ago

Why wouldn't you just use OCaml, Haskell, F#, or Scala, where you've got much more mature web framework options? Don't get me wrong, Rust is fine, but if you don't need its memory management then why make trouble for yourself?

deleted 6y ago
[deleted]
riquito 6y ago
It's in the preface > The project is simple enough that I can't imagine being too limited by any language's ecosystem. And I've been itching to write something substansive [sic] in Rust...
vghaisas 6y ago
I think it's also a bit of a chicken and egg problem: If no one uses Rust for web servers then its ecosystem won't ever mature. If there are people willing to deal with some rough edges, that's great and will help the ecosystem mature.
Lio 6y ago
Rust is interesting in that it may eventually end up as a very useful language for WASM work. Rust has the advantage that when compiled to WASM it won't require a runtime library. So the prospect of Rust as a fast, low overhead, use anywhere language is tempting. Since Rust is a relatively new language it's worth checking to see how it's maturing over time against small low risk projects exactly as the author has done. Rust may not be a perfect fit right now but that may change. So it's very valid to test one's assumptions from time to time. Or to put it another way, working in one of the languages you've mentioned wouldn't answer the question "how suitable is Rust for web server work right now?"
- jfkebwjsbx 6y ago
  All that applies to several other very mature languages that can target WASM, like C. Nevertheless, WASM is not ideal for server work. It is intended for the frontend.

IAmEveryone 6y ago

Reading this I can't help but be lost trying to come up with any alternative solution for this specific use case that is worse than what they describe? A bunch of mostly static blogs can be hand-edited HTML, or some ancient perl script, or any of the existing static site generators. If it absolutely needs to involve server-side logic, it could be completely accomplished within a single call to ```rails init```, and the resulting project would incorporate a few $billion worth of collective experience commonly refered to as "best practice". It would be far easier to modify and far less likely to contain vulnerabilities. Performance would be worse by a factor of maybe x100, or "why are you asking these weird questions?" when converted to the real world, according to a representative survey of end users. There's a good argument for replacing individual components on, say, the critical path for rendering people's twitter feed with lower-level implementations. But it strikes me as unlikely that such endeavours would care about the ability of their ORM to quickly generate the migration scripts to drop or add some database columns. So I can't quite see the benefit of cramming the rails model into Rust? Rails is spectacular in how it allows you to quickly iterate, adapt your data model, try some ideas, and so on. Those are qualities that just logically do not transfer to a world of static typing and manual memory management.

GolDDranks 6y ago

Not the point of the article, so sorry about offtopic, but the workflow described in the first chapter feels a bit off. If they wanted dynamism, then writing a server is the way to go, but it seems that the easier fix to their problems as described there, would have been setting an automated CD pipeline that would build and deploy their blog every time you make a change.

johnfn 6y ago

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of errors it can pick up on, and rust-analyzer is leagues beyond where RLS was. But... the compile times are an absolute non-starter for me. I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. The long compile times completely kill any enjoyment or flow that I normally get out of productive programming. Even worse, I found myself anxious to introduce new dependencies, because each new crate would add a few more seconds to the compile time, which immediately correlates to less coding enjoyment. I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. I have a theory: there must be two groups of engineers. One group loves fast compile times and quickly validating hypotheses. The other group must value thinking about their code a lot more than running it, and so compile times aren't that important. My guess is that, while the second group hangs around and loves Rust, Rust has completely driven away the first group (including myself) to the degree that they don't use the language enough to even fill out the surveys. Anyways, I know it has a wide swath of use cases, mostly in systems programming. I'm just bummed that if I ever do any of them, I won't really enjoy it. :-( [EDIT:] Gotta go to sleep, it's far too late here. I really appreciate all the thoughtful replies. Rust's amazing community is another reason it annoys me that I can't fully get into the language as I'd like to.

FridgeSeal 6y ago
I find that the strong type system and editor plugins like Rust Analyzer have me covered for “does this do what I expect?”, which means I do way less write-run-check than I would I say, Python.
byteofbits 6y ago
As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day. I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to. There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I work on REST API systems - so nothing too crazy).

colesantiago 6y ago

Is there anything like Rails for Rust?

vghaisas 6y ago
I don't think any Rust web framework provides as much as Rails does, but you can see the current state of them here: https://www.arewewebyet.org/topics/frameworks/ https://www.arewewebyet.org/topics/frameworks/

eximius 6y ago

I wonder if there is a need or appetite for large libraries like Apache commons or Guava in Java which cut down on dependency count. It's an alternative to a myriad of small, unaudited libraries. Rust does have some projects going to audit those small libraries, though.

pantulis 6y ago

In my opinion, the section which the author called "the ugly" makes it clear that it's not that surprisingly good as a application server language. A file upload is a basic feature that has already been solved yet Rust code contains a lot of boilerplate when compared with Python. Remember the mantra from the 2010's when the dynamic typing craze? Rust is not about optimizing developer time, it's about guaranteeing safety for base sysstems software. All this permanent reasoning about ownership, borrowing and so on makes it the greatest contender against C++ (hence Mozilla and Microsoft support) but in terms of productivity you'd be best served with a higher level, GC-collected platform for an application.

sanxiyn 6y ago
The point of the article is that lack of good support for file upload IS a productivity hit, but ownership reasoning IS NOT a productivity hit. And file upload can be solved by just more code. This indeed matches my experience.
- zozbot234 6y ago
  > And file upload can be solved by just more code. Yes, but it's a papercut. How many other papercuts are there, compared to more developed ecosystems for this domain? That's not an easy question to address.
  - pantulis 6y ago
    Or take the ORM as an example. Doesn't even begin to compare with 2012's ActiveRecord from Rails land. Not to be surprised, as Rails used a lot of dynamic magic that is simply not doable in Rust. Granted, it's more than enough for a lot of use cases but it wouldn't seem to me like the most appropriate approach for, say, and e-commerce platform in terms of maintainability and time to market. Of course, the performance speedup would be huge on the other hand.
    - monadic2 6y ago
      Conversely, active record can’t generate the SQL you can learn in a few minutes in a database class. I’d much rather have highly precise sql serialization and deserialization code and emphasis on minimal client overhead in a systems language than the ability to rapidly spike a data model and query it in the space of a PowerPoint slide.

rwmj 6y ago

Why wouldn't you want a garbage collected language for developing web services? Developer time is at a premium, lots of RAM, likely a single environment managing multiple requests so the GC gets a global overview, and because of network variability you're unlikely to be doing anything with realtime constraints.

IshKebab 6y ago
GC pauses in some languages are not good (Go put a lot of effort into fixing this). That's about it, but Rust is good for reasons other than its lack of GC. The type system is very robust, which means fewer runtime errors. The standard library is pretty great, even if parts of it are third party de facto standards (serde, crossbeam, etc.). It's much more expressive than Go. Much faster than Python.
sanxiyn 6y ago
The point of the article is that surprisingly, lack of GC does not hurt developer time.
- joppy 6y ago
  A simple web server barely needs GC - allocate anything and everything needed during a single request from the same pool, and free the pool once the request is handled. The lack of GC can hurt developer time for other kinds of work, where the lifetime of data structures are not scoped to “within a request”.

echelon 6y ago

I've built a few web services in Rust, and I've been incredibly pleased by the existing ecosystem as well as how easy it is to develop concurrent solutions for CPU-intensive tasks. https://vo.codes https://vo.codes is a text to speech service written in Rust and it performs really well. Any service failures are simply my poor proxy implementation - the core TTS service itself scales very predictably.

csomar 6y ago

I'm working with Rust as a backend right now and can echo the Diesel experience. The issue is that there is not really much of a choice, it is either Diesel or not. So you have to stick with that. Another problem is that most OS projects in Rust are maintained by 1-2 persons who are not working on the project fulltime. That's not the case for JavaScript/Node as there are order of magnitudes more projects and people working in these platforms. His last example could be improved a lot with the "?" keyword. That would remove lots of wrapping and simplify the code greatly. So it's not that bad really.

marvinblum 6y ago

I had a similar idea for my blog [1], with almost identical goals, but I wrote it in Go. Rust is on my to-learn list, but I find it harder to read from the code samples in the article and what I saw on other websites. I guess I will stick to Go for business logic. When would you guys chose Rust over something else, like Go? [1] https://marvinblum.de/blog/how-i-built-my-website-using-emvi-as-a-headless-cms-RGaqOqK18w https://marvinblum.de/blog/how-i-built-my-website-using-emvi...

nkozyra 6y ago
Go comes with more tools to do what you want with stdlib. It'll be easier to do this with go than learning rust and the required dependency. So that's one answer: forcing yourself to learn more about a languages environment and ecosystem. Another answer might be: "I already know/prefer rust." I'd be surprised if there were much/any performance benefit.
- marvinblum 6y ago
  I thought about getting back into game development. Nothing fancy, just some 2D experiements. I haven't looked into Vulcan/OpenGL bindings for Go in a while, but I remember that it wasn't really recommended. Maybe I'll give Rust a shot one day to do that.

fooyc 6y ago

It's sad that we still have to make async I/O explicit in the code to obtain some efficient concurrency in 2020. Async/await is a huge improvement over callback hell, but this doesn't fix everything. The "function color" problem still exists [1], and seems to be more than binary in rust. This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Rust is ground breaking in some areas, but also completely lacks innovation in others. But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? [1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

steveklabnik 6y ago
> This quote from the article is incredibly sad: "each async library, comes its own ecosystem of libraries, which only work with that async library". Already in Rust many libraries can be written completely agnostic of the underyling executor. Some cannot; we have a bit more interface work to do, but there's nothing inherent about this, it's solely a standardization issue that's being worked on. Sounds like they ran into the latter more than the former, which is unfortunate, but should be better in the future. > But is it actually _necessary_ to resort to async I/O in Rust, given that the type system appears to make thread-based concurrency safe ? It is not!
mlindner 6y ago
One of the core facets of Rust is that you don't pay for what you don't use. If everything was async by default then code that wasn't async would pay the cost of it. Async isn't free.
CJefferson 6y ago
I would love to see some quality benchmarking of a non-trivial threaded solver in Rust. As strongly suspect it will perform "well enough" (hopefully much better than async in Python, and hopefull javascript too), which is good enough for me to be able to escape async.
estebank 6y ago

jxub 6y ago

To the author: "per say" should be "per se". Good article anyway.

kristianpaul 6y ago

“ honestly some of the Rust ecosystem reminds me of the NPM. My end release build needs to compile 267 different libraries, before getting to my code, and that's for my simple little blogging engine.” <- Thats something i had to agree with With lately , i guess is part of the good and bad of having a growing community. So spend time picking the crates that make you feel more safe

ragnese 6y ago

I'm glad to see this post here. Just because I hear/read a lot of people outright dismiss Rust's potential here with arguments that kind of miss the point: 1. You don't need CPU performance for most web stuff. It's all IO bound. 2. Related to #1, garbage collectors are fine and you don't need the Rust model. 3. Rust is so hard to learn that it isn't worth it unless you need the performance. There's so much more to Rust than the performance. It hits a really nice sweet spot between being expressive and letting you take as much control as you want/need. Sometimes GC'd languages are a pain in the butt because I just want a damned destructor and I would like to be able to guess when/if it's gonna run. And, frankly, Rust isn't that hard. It's an imperative language. It's not Haskell.

koheripbal 6y ago
Can someone elaborate on why #2 is wrong on the server level? My systems are not performance bottleneck'd and as a Java dev I'm more worried about the potential for memory bugs (which I admit I will create) if I stray away from automatic garbage collection.
- ragnese 6y ago
  It's not wrong. I didn't mean to imply that. I just mean that saying non-GC languages are about performance overhead of the garbage collector is missing the point. Sometimes, it's convenient and easier to reason about stuff when you can predict when something is actually dropped from memory. And in Rust, you wouldn't create those memory bugs you're worried about. (Well, you can, but you have to go out of your way to take the safety off :)) That's kind of Rust's whole "shtick"
  - koheripbal 6y ago
    You can absolutely create memory leaks in Rust [1]. That's a bigger problem for server applications than CPU / Memory performance issues, because the latter can be traced more easily. As a (mediocre) dev and head of a team (some are great, and some are as bad as me), I'm far more worried about bugs than performance. [1] https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust https://stackoverflow.com/questions/55553048/is-it-possible-...

finder83 6y ago

I've taken the deep dive into Rust API service development the past few weeks. I really enjoy the experience of developing in Rust, but not so much the experience of using Rust web frameworks, somewhat in line with the author. In particular, even having a relatively small set of feature requirements it has been difficult finding a web framework that supports: Middleware, Websockets, easy routing, and async handlers. Actix probably supports all of those, but I don't much like development in it and prefer to avoid the drama of Actix. Surprisingly, none of the other libraries I've looked at support all of those (except possibly Gotham, but I ran into other issues with it). I'm not sure what my takeaway is, other than that web frameworks still have a ways to go, and development on each of these web frameworks seems slow, I think because of the lack of companies picking them up. I also get the impression that people are somewhat obsessed with doing it the "Rust way", rather than just getting a simple completed web framework out the door. However, I love working in Rust, and think I may reach a point where I'm actually more productive in it than something like Typescript. There's just a large learning curve. But it's fun.

grok22 6y ago

I find the title surprisingly annoying. What the heck is "surprisingly good"? As compared to what? (I know, I know; reading the article would've clarified). And what the fuck is a "server language"? The title made me want to not read the article just to come to know of yet another new developer come in contact with something they haven't used before and make obvious or irrelevant pronouncements like they discovered something new. Or maybe I am just growing old :-).