
Rust Is Surprisingly Good as a Server Language - signa11
https://stu2b50.dev/posts/rust-is-surpris76171
======
johnfn
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.

~~~
byteofbits
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).

~~~
johnfn
That's really interesting. Compiling only a few times a day is mind boggling
to me - in a normal day I'd probably average hundreds to a thousand
compilation cycles!

The main thing that I use compiling for is to validate little off-by-one
things. Like, is substring() exclusive on the second parameter? What about
range syntax and the slice operator? What if I wrote + 1 instead of - 1
somewhere, or did < instead of <=? I could spend a few minutes combing
documentation, or just compile it and check immediately. Well, assuming
compilation is fast anyways.

~~~
wiz21c
>> in a normal day I'd probably average hundreds to a thousand compilation
cycles!

Maybe it's time to switch to an interpreter ? :-)

~~~
logicchains
Or a language like Go, C or Nim that can compile tens of thousands of lines of
code in a few seconds.

~~~
pjmlp
Or OCaml, Java, C#, F#, Eiffel, Delphi,...

~~~
LandR
I've worked in a C# code base where compiling the solution took 40 minutes.

~~~
koyote
Wow, one of our solutions is nearly 100 projects (legacy) and the compile time
for the whole solution is sub-5 minutes. I'd love to see what kind of solution
would take 40 minutes to compile! (or maybe I don't :)).

That being said, C# is clever enough to only need to recompile the assemblies
affected by your code change, so often you can get away with 10 second compile
times even for large solutions.

~~~
LandR
IIRC our solution was around 450 projects. Visual Studio just woudn't open the
whole solution.

So you had to work in individual projects at a time, slowly going through and
changing stuff project by project.

VS wouldn't even build it either, really. YOu had to build via batch file that
did various ms build magic. I would make changes, set of a build and go to
lunch, then come back and fix the errors.

Once you checked the code into source control it would trigger a build which
would sometimes take upwards of an hour :( I hated that code base.

It got even worse when they added Coded UI tests. Wait an hour for a build and
then a random Coded UI test would fail and the advice from the people who
wrote the Coded UI was "just run another build!", yeah, flakey tests on a code
bases that tests an hour to run...

~~~
pjmlp
Now imagine with the current Rust compile times, compiling those 450 projects
from scratch, I bet the 40m would turn into hours.

------
jph
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
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.

~~~
kibwen
Not that as of Rust 1.45, coming out this Thursday, Rocket will be able to
target stable Rust:
[https://github.com/SergioBenitez/Rocket/issues/19#issuecomme...](https://github.com/SergioBenitez/Rocket/issues/19#issuecomment-630650328)

I believe Diesel has been on stable for a long time now, so for this use case
I don't think anyone will need to worry about using the nightly releases.

~~~
thepratt
That's good news! Wasn't aware of the pin change for rocket.

~~~
estebank
One more thing: I build my final binaries with stable (when possible), but
develop with recent a nightly. There are some features that require nightly
(custom testing frameworks come to mind) but don't affect the final binary
(only tests) _and_ I get the new goodies (better diagnostics, speed bumps,
fixes) up to 12 weeks ahead of schedule.

Rustup makes having nightly and stable in the same machine painless, and I got
in the habit of running cargo +stable build and cargo +nightly test. BTW, you
don't _have_ to do this, it just makes my experience a bit nicer.

------
Nican
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.

~~~
Cthulhu_
Rewriting is very expensive, and the advocate will need to make a VERY strong
case for Rust if they're asking your company to invest in replacing it - and
alternatives have to be suggested as well, including other languages and a
good list of things wrong with Node / TS. Consider developer availability as
well.

I don't think a strong enough argument can be made. I'm sure you CAN write web
services in Rust, and that in very specific cases it'll have some benefits
over Node, but honestly very few people work in an area like that.

Disclaimer: I've settled on using Go to rewrite an existing application. The
original app was written in PHP; nothing wrong with PHP per se, but the
existing codebase is a mess and the PHP version is hard to keep up to date
because of LTS versions of operating systems + very slow and careful updates
at our customers (it's network infrastructure). For me, switching to a
compiled language that produces a self-contained executable was a compelling
argument. I have to admit that I do kinda pine for something like Java again
though.

~~~
tabs_masterrace
Swift / Vapor is amazing as well. They just released version 4, which
streamlined and tidied up lots of things, can't recommend it enough. There's
just something solid about Swift's strictness and compile time checks, that
make it easy to be sure you're handling all possible code paths, and you can
be reasonable confident it works and won't break all the time. Also very lean
on dependencies, mostly unopinionated, and performance/mem-usage is top tier
too. Only con is probably, you're bound to Xcode (and therefore macOS) for
development, I guess you could try to set it up in VSCode, but haven't heard
of it and experience will probably be not so good.

~~~
dpacmittal
That con is a pretty big one. Macs have less than 10% desktop market share.

~~~
gganley
In this case Swift is being used on the server, so that could be an officially
supported platform[0] which if I recall correctly is macOS, Ubuntu, CentOS,
Amazon Linux 2, and Windows as of Swift 5.3.

~~~
pjmlp
Swift on Linux is pretty much WIP, with an ecosystem that is Mac first and
hardly considers another platforms.

On Windows with luck 5.3 will be the first version that the compiler actually
works, let alone existing libraries that barely work on Linux.

------
cft
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...](https://rust-lang.github.io/async-
book/01_getting_started/05_http_server_example.html)

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.

------
pantulis
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
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.

~~~
joppy
Ownership reasoning is not a productivity history in a web server, where the
lifetime of pretty much everything is a single request which is handled and
then disposed of. This is pretty much the simplest case for ownership. In a
different application (say, one running a GUI with many objects which live for
indeterminate amounts of time and can be shared across views), ownership
reasoning can be extremely complicated.

I’m not saying having to reason about ownership is bad, I’m just saying that
this is not a good test for whether ownership reasoning is difficult or not.

~~~
zozbot234
The thing with ownership reasoning in Rust is that you can opt out of it
whenever it makes sense to do so. If you really have "objects which live for
indeterminate amounts of time and can be shared across views", that's not an
increase in complexity; you just acknowledge that reasoning about ownership
and sharing at compile time is not going to be feasible, write Rc<RefCell<…>>
(with a documentation comment to that effect) and move on. All it takes is
knowing where to add a tiny bit of boilerplate.

~~~
amelius
Yes, but you still can't write garbage collected code, which is tremendously
useful in many circumstances. E.g. when using closures you really don't want
to be thinking about memory allocation, and closures have proven a very useful
concept. There are countless of reasons why the availability of a GC is a
productivity booster.

So I wouldn't describe Rust as a language that fits all domains and/or
programmers well.

~~~
pasabagi
Isn't Rc<T> essentially garbage collection though?

~~~
amelius
Reference counting _is_ a form of garbage collection, but with closures you
often end up with circular dependencies, which is what RC can't handle.

------
chrismorgan
On the set_expires thing, the docs are at
[https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#...](https://docs.rs/rocket/0.4.5/rocket/http/struct.Cookie.html#method.set_expires),
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_surpri...](https://old.reddit.com/r/rust/comments/hpzmeu/rust_is_surprisingly_good_as_a_server_language/)

------
fooyc
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-...](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/)

~~~
steveklabnik
> 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!

------
lmm
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?

~~~
Lio
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
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.

~~~
Lio
Sorry, I may not have explained my point clearly enough.

I'm not suggesting that you would use WASM for server work at all.

I'm suggesting that Rust would be interesting for WASM on the frontend because
it doesn't depend on a runtime.

Given that you might want to use Rust for WASM you may also want to use it on
the backend (that's without using WASM on the backend).

The assessment of Rust via small projects says nothing about the suitability
or not of C or any other language.

It's just about the suitability of Rust right now and how it's changed from
the last time you assessed it.

~~~
jfkebwjsbx
Fair enough. I wanted to mention that Rust is not the only language that
targets WASM since you talked about maturity.

------
finder83
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.

------
akoncius
[https://stu2b50.dev/posts/tag/culture](https://stu2b50.dev/posts/tag/culture)

on tag page it’s possible to see drafts :)

------
ragnese
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
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
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
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-...](https://stackoverflow.com/questions/55553048/is-it-possible-to-
cause-a-memory-leak-in-rust)

~~~
ragnese
Depends what we're talking about. A "true" memory leak (as in allocated memory
that is not referenced) is not very likely.

A reference cycle with `Arc`s can happen though.

But if you're talking about Java and mediocre devs (I'm in the club- don't
worry), I feel like there are no shortage of ways to make bugs with null,
concurrency issues, etc, that Rust completely eliminates. You _can_ make
reference cycles in Rust, though.

Also, in Rust code you often don't have references to references to references
the way you do in Java, so it's just not an issue that I'm aware of having had
yet.

~~~
koheripbal
[https://stackoverflow.com/questions/55553048/is-it-
possible-...](https://stackoverflow.com/questions/55553048/is-it-possible-to-
cause-a-memory-leak-in-rust)

~~~
estebank
That SO answer restates what the parent said: you can leak data either
explicitly (Box::leak/std::mem::forget) or by creating reference cycles when
using Arc/Rc.

------
eximius
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.

------
csomar
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.

------
tanilama
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.

------
echelon
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.

------
IAmEveryone
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
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.

------
rwmj
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.

~~~
sanxiyn
The point of the article is that surprisingly, lack of GC does not hurt
developer time.

~~~
joppy
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”.

------
golergka
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
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
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.

------
grok22
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 :-).

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

------
colesantiago
Is there anything like Rails for Rust?

~~~
vghaisas
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/)

------
privacyonsec
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.

~~~
chrismorgan
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.

------
0xDEEPFAC
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
Does it provide the same/better safety guarantees as Rust? The website has
extremely limited information about the language.

~~~
DoingIsLearning
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-
lang...](https://www.quora.com/How-secure-is-Ada-the-programming-language)?

[https://ada2012.org/comparison.html](https://ada2012.org/comparison.html)

[https://www.adacore.com/about-spark](https://www.adacore.com/about-spark)

~~~
imtringued
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
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)

------
marvinblum
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...](https://marvinblum.de/blog/how-i-built-my-website-using-emvi-as-a-
headless-cms-RGaqOqK18w)

~~~
nkozyra
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
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.

