6 ms·
Author contemplating an eventual C++ rewrite, but this is a perfect use case for Rust. When you want performance and where memory mistakes can be a serious secu
by gameswithgo 6y ago
Author contemplating an eventual C++ rewrite, but this is a perfect use case for Rust. When you want performance and where memory mistakes can be a serious security problem.
- gitweb 6y agoI prefer C or Go
- lwansbrough 6y agoAh yes, C, well known for its memory safety!
- 1024core 6y agoAs with any tool, if you don't use it properly it can hurt you.
- rowanG077 6y agoThat'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".
- gitweb 6y agoC 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.
- weakfish 6y agoThe reason they're built in C is legacy and the fact that Rust hasn't been around all that long.
- 1024core 6y agoWell, what's stopping you from rewriting it in Rust?
- rowanG077 6y agoYes, and that good reason was that Rust did not exist.
- imtringued 6y agoThat'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.
- 1024core 6y agoHave 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.
- rowanG077 6y agoRedis 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 https://github.com/jas502n/Redis-RCE [2] https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-... [3] https://web.archive.org/web/20190126114638/http://article.gmane.org/gmane.network.djbdns/13864 https://web.archive.org/web/20190126114638/http://article.gm...
- malka 6y agoI'd rather be hurt by my safety razor than by my chainsaw though.
- skeeks 6y agoOr java
- mathgladiator 6y agoI 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.
- gameswithgo 6y agothe 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.
- gnusty_gnurc 6y ago> but this is a perfect use case for Rust Idk it seems like for someone prototyping things alone, Python is the perfect langauge
- kroltan 6y agoI 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.
- gnusty_gnurc 6y agogot it thx
- nick_ 6y agoOr F#/C#. Rust will have memory fragmentation over time.
- cube00 6y agoPrevious discussion on this https://news.ycombinator.com/item?id=18190573 https://news.ycombinator.com/item?id=18190573
- catlifeonmars 6y agoMemory 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.
- zamalek 6y agoRight. Just like the story of a memory leak in a missile.[1] [1]: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
- Yoric 6y agoI 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?
- jlokier 6y agoSome 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.
- zamalek 6y agoC# 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.
- pensatoio 6y agoOr anything that isn’t a scripting language
- gameswithgo 6y agoindeed, 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.
- Yoric 6y agoJust wrote a websocket server in Rust. Turned out really easy.
- deleted 6y ago[deleted]