Besides, if a language guarantees that all pointers are not null, initialized, not dangling, etc you have a solid foundation in which to build large systems.
Also - why are people even mentioning C#? Rust is a language for writing SQL servers, drivers, browsers, and other foundational components where a garbage collector wouldn't make sense. Just about all of my stuff deals with HTTP, which is farther up the stack from Rust's sweet spot.
Yes, you can ducttape rust style memory safety features into C# or C++, but I'd imagine using it is kind of like introducing asynchrony into a C# codebase - it wants to affect everything and if you don't you'll always be contending with the sync/async border. Better to make it a requirement and reap the rewards from knock-on effects.
They then took some of those learnings into Windows 8.x, UWP .NET Native and C# 7.x and 8.0 low level memory primitives.
A tracing GC, coupled with value types and manual memory management in unsafe code makes plenty of sense and has been done multiple times since Xerox PARC days.
The only thing missing is a company having the guts to push it no matter what. A bit like Google is doing with ChromeOS and Android.
This. I see a lot of the so call new idea and hype aren't actually new at all. It didn't succeed simply because it never got the investment or drive until it has sustainable critical mass. And every few years or decades we start to reinvent the wheel by new generation of developers.
Especially in tech industry where you are considered old if you are over 40, but in reality it is the age you finally see all the ideas keeps getting recycled again by newer generation and you could finally say meh, no.
It’s not a language “for” anything per se, it’s ergonomic anywhere up the stack.
Actually, there is, not having a GC means you can better reason about stack/heap memory usage. That matters for performance critical and things like embedded systems where you might not even use malloc() in c.
Been learning rust for a few months now and really enjoying it so far... waiting on the new async stuff to firm up a little before continuing.
It's a lot easier for someone to scoff at memory bugs on an internet forum than it is to write memory-safe code.
People need to "humble down" and see that if people keep falling into the same traps even with training, it's not as simple as "people sucks"
The parent isn't saying "people suck" or even that "people who write memory bugs suck".
They're saying that 'programmer machismo' sucks.
Saying, "we don't need better tools, we just need better people, and I'm one of those better people," sucks.
Closely related is saying, "manual memory management is hard, so I guess most programmers should use better tools. But I'm a really advanced 10x 'leet programmer, (in spite of how much of my code has wound up in CVE's), and I'm clearly capable of writing code using manual memory management because of my 'leet skills."
It's one of the peculiarities of the field that we're completely ok with practitioners using dangerous tools and building techniques when better tools and techniques are available.
Hence why we need languages that are better at memory management than C. It's ergonomics.
In the same way you can't put a racing gearbox/clutch in a street car and expect everybody to deal with it. They won't.
But let's say they were very smart and did not get all those bugs. Even then, why would someone claim the compiler double-checking is not useful?
I have a pretty good grasp of Javascript and can pretty much always predict what type something is going to be. Of course I make mistakes, but even if I didn't: using TypeScript is still great, because I don't have to manually keep track of all those types. Sure, I could do it, but it's more useful to spend my cognitive effort and energy on other things.
I built a domain agnostic virtualization and streaming platform that generalized the “Click2Run” features of Office and could apply retroactively to any traditional app that didn’t include kernel code (e.g. worked on Adobe Creative Suite)
I also worked on the early phases of the sandbox that runs WinRT for JS, which also required paying my dues and fixing bugs or implementing new features (e.g. the fetch API) for the Trident engine in IE.
I wouldn’t consider these trivial projects.
Also, being memory safe doesn't get you much (or rather very very little IMHO), because complex code still contains logic bugs, UI bugs, performance bugs, etc, etc. Personally, I want the program to crash rather than keep running only to find out it was silently messing up data or otherwise leaving things in an inconsistent state.
Fuchsia contains a considerable and ever-growing amount of Rust. And if you consider VM infra in the "OS" category, you have Firecracker from Amazon and crosvm from Google as well.
> maybe an entire AAA game written in Rust will be an interesting challenge.
We'll see how it goes; there is one studio that has made AAA-level games in the past using Rust now, and a new studio that is full of ex-EA folks.
> Personally, I want the program to crash rather than keep running
The alternative here isn't keeping running, it's "does not compile in the first place". That's even sooner than your crash, and guaranteed, as opposed to "happens to hit the right code path."
Different people mean different things when they talk about correctness. I think it means accurately capturing the intent of the programmer, i.e. the logic/algorithm/code flow or whatever, and eliminating the ambiguity. How does rust help here?
I'm saying that its this the same kind of programmer error (not being able to specify things without ambiguity or a way to capture intent accurately) that was the cause of the memory bug in C too. Its just that with C you will hard crash whereas in Rust you wont. You didn't crash but you modified a data structure you shouldn't have, and your program will still end up in an inconsistent state.
In much the same way, the kernel doesn't care what happens in userspace - which thread is doing what with memory or what userspace resources are being corrupted, etc. The kernel can trivially kill userspace threads at will, and continue to remain rock solid as ever. So yes while the separation of kernelmode and usermode helped the user escape from poorly coded apps, it didn't really help reduce the actual bugs as much.
Hopefully that made as much sense as it did in my head! :)
Just in this thread stats about memory bugs being 70% of CVEs is presented, so why do you believe "being memory safe doesn't get you much" ? I am not a Rust fanboy and would rather use a GCed language for most work. But I don't get this stubbornness towards progress and better tools. If some tool can make "your" life easier in many ways, use it for your own profit !!
As an aside, I've recently been working with PLCs and I've come to respect a lot of the design elements of things like the Siemens GRAPH language which makes it easy to capture my intent for sequential control stuff.
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...
Not to mention Firefox's poor state in macOS.
https://4e6.github.io/firefox-lang-stats/
They are working on a new Rust-based rendering engine, Servo, but it hasn't received nearly the level of work that a browser like Chrome has yet.
On my machine at current gig it crashes every other day making me lose my containers. It doesn't overheat the machine like some others reported though.
That said, you're better off comparing CVE counts for Firefox vs Chrome. That said someone could craft a malformed legacy font file that has to be parsed by some dusty win32 code and BOOM!
1. In a constraint context (embedded/kernel) you want to preallocate most things anyway, since even normal malloc/free isn't deterministic. Once you preallocate objects, it doesn't matter if those are coming from a long-lived GCed heap or from somewhere else.
2. Kernels like Linux rely on the fact that some small allocations never fail. Plugging in a GC and asserting that it won't fail would have the same effect (with some impact on latencies).
What might be most important is that the language supports explicit stack allocations, which avoids the need for any kind of heap when necessary. That is given for languages like C# and Go.
This says a lot. I'm sure Microsoft has very smart and competent engineers, yet they still get all these bugs. It's because manual memory management is really, really hard.
I'm baffled to keep hearing some people saying that manual memory management is okay when the evidence is this huge.
Perhaps for very simple programs is okay to do manual memory management, but for complex ones like most of them nowadays, it seems close impossible for humans to write safe programs.