Or anything that isn’t a scripting language

indeed, C#/Go/Java etc would all be a big boon without the mental overhead of Rust. Data races being caught at compile time is also nice though when doing a multithreaded server.

> but this is a perfect use case for Rust

Idk it seems like for someone prototyping things alone, Python is the perfect langauge

I don't think the parent is disagreeing with that, but the article mentions graduating from Python to something else, which is where the recommendation fits. Parent isn't saying the article's original version should be in Rust.

got it thx

Just wrote a websocket server in Rust. Turned out really easy.

Or java

I used to be on the java hate train, but honestly the JVM is magic for infra. I worked at AWS, and I groaned so hard when I started. Then, I came to appreciate it because of the tooling and the types of issues that actually cropped up.

This may also be stockholm syndrome.

the nice thing about Java is you get pretty good performance even while pretending the hardware concerns don't exist. This takes a lot of things to think about off your brain. The downside is you can't choose to think about them even if you want to.

Or F#/C#. Rust will have memory fragmentation over time.

Memory fragmentation is generally a problem for pets, not cattle. In 90% of use cases it’s nothing that frequently reaping processes won’t fix. This works regardless of language, as it pushes the job of garbage collection onto the os. Another nice feature of treating your processes like dirt is that you tend to get high fault tolerance and scalability as emergent properties.

Right. Just like the story of a memory leak in a missile.[1]

[1]: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

I really think it's a good solution for many cases but I haven't seen any server-side web framework that implements a kill-the-process-often strategy.

Do you know of any? If so, when do they decide to kill the process and how do they handle client disconnect?

Some pre-forking web servers will shut down a child process after it has processed a configured number of requests.

E.g. Apache in mpm_prefork mode, MaxRequestsPerChild configuration.

C# suffers from that too. I've personally seen a prod instance experience OOM with something like 40% free virtual memory. There's a reason why ArrayPool is part of mscorlib.

All of that said, x64 greatly reduces the effects of memory fragmentation: there's always more virtual memory.

Previous discussion on this https://news.ycombinator.com/item?id=18190573

I prefer C or Go

Ah yes, C, well known for its memory safety!

As with any tool, if you don't use it properly it can hurt you.

That's quite a ridiculous statement in this context. Even highly-trained, extremely smart developers are proven to not be able to use C without introducing gaping security holes. That's not "it can hurt you". That's "it hurts you and everyone that is exposed to your RCE machine".

Have you looked at code by AntiRez, the author of Redis? Redis is written in plain C.

What about QMail and DJBDNS, from Dan Bernstein? Again, all C.

And the mother of all: the Linux kernel. Again, in C.

Redis has RCE exploits which would not exist in a memory safe language [1]. QMail had an RCE as well[2] and DJBDNS has had a security bug which would not have occurred in a memory safe languages [3]. The linux kernel has had an incredible amount of memory bugs over the years. The software you mentioned does much, much better then the average C written code. But it still has had issues with memory. So in fact all your examples prove my point.

[1] https://github.com/jas502n/Redis-RCE

[2] https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...

[3] https://web.archive.org/web/20190126114638/http://article.gm...

C is not C++. There is a reason core services for DHCP, DNS, etc are built in C and not Rust. If you're a careless developer you can have security vulnerabilities in any language.

The reason they're built in C is legacy and the fact that Rust hasn't been around all that long.

Well, what's stopping you from rewriting it in Rust?

That's only true on Linux and other systems where the kernel has been written in C. On some platforms the kernel provides no backwards compatibility guarantees and that means backwards compatibility is handled by libc. This means C is enshrined into the platform and often the path of least resistance.

There was also a pure Rust Wayland binding that failed because Wayland assumes that you are using C semantics which made it hard to provide a safe interface for Rust that was also convenient.

Yes, and that good reason was that Rust did not exist.

I'd rather be hurt by my safety razor than by my chainsaw though.