Hacker News Reader

Comment by ceronman | Hacker News Reader

"70% of all Microsoft patches are for memory-related bugs".

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.

View on HN

You don't want to have to rely on people being competent all the time. You want people to 'fall into the pit of success' instead of opting into several safety mechanisms that'll get you something that's 'pretty good'

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.

Because Microsoft has written several OSes in C# variants, with AOT compilation to native code.

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.

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

There’s nothing intrinsic to rust that makes it better suited for “foundational components” over anywhere else in the stack. Just because it’s capable of being used lower down doesn’t mean it’s a better or worse language higher up the stack. It’s probably got all the APIs or great crates you need for your work.

It’s not a language “for” anything per se, it’s ergonomic anywhere up the stack.

> There’s nothing intrinsic to rust that makes it better suited for “foundational components” over anywhere else in 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.

I think I may not have phrased it well, I agree with you, it’s better than many other languages for low level software development. What I’m saying is there’s nothing that makes it worse for high-level software development.

Depends on how your mind works really... I know a lot of devs that cannot break out of C# class and enterprise app thinking. I happen to like JS for a lot of workflows. It really depends on mindset.

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.

Because explicit memory management has a higher cognitive overhead than implicit memory management, a GC-based language is more suitable higher up the stack.

Rust memory management is in fact implicit. Sometimes you have to be explicit about lifetimes, but the two are not the same.

For that matter, wouldn't be too surprised to see MS publish crates that give nicer interfaces to Windows internals or even linux, sql, azure or other platforms access.

Because there is plenty of higher level systems interfaces that could be just as well written in C++, C# or Rust. Just because rust works on low-level problem spaces, doesn't mean it doesn't work higher up. Also, MS could very well create some of the applications in question with C# as well.

"Good programmers don't need help managing memory" is the "global warming isn't real" of the programming world

This is also a “10x and I’m sorry” issue. The unicorns write a prototype which is then handed to lesser mortals for maintenance. Will the mortals do as well as the initial author that had complete control? No. I was just thinking it’s basically denialism at this point yet I still run into engineers that think memory management is no biggie. Everyone has a blind spot, and this is one often found in the most talented.

> I'm baffled to keep hearing some people saying that manual memory management is okay when the evidence is this huge.

It's a lot easier for someone to scoff at memory bugs on an internet forum than it is to write memory-safe code.

That comment isn't scoffing at people who write code with memory bugs. That comment is scoffing at people who think writing memory-safe code (in languages which allow programmers to easily write memory-unsafe code) is easy.

Correct answer

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"

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.

Yes, that's what I'm referring to -> 'programmer machismo' sucks

This seems self contradictory. If people keep falling into the same traps even with training, how is "this is a human limitation" not a reasonable conclusion?

I don't see what are you reading there, but "this is a human limitation" is the correct conclusion

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.

What makes you think they don’t include themselves in the term “humans”?

> This says a lot. I'm sure Microsoft has very smart and competent engineers, yet they still get all these bugs.

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 don’t understand how SAL and RAII couldn’t help with this. In three years I never had memory issues reported against my C++ code. The closest thing that happened to me was corruption while prototyping a Zip utility that had new features I was inventing. There I had to build a variable sized input bitstream writer and had corruption on some ISAs due to differences in the interpretation of <<.

Because modern C++ won't save us: https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

if you don't have memory issues in your code then either it's so small that everyone participating in its development can actually keep it in a perfect state or no one searched hard enough yet. After a certain complexity bugs just appear, you don't have to do anything, they are just there.

I’m not saying I never wrote bugs, but tools like SAL or RAII types that manage sharing help. By the time I checked in, they were either squashed or not found until after I left Microsoft.

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.

Its hard, but you're trading memory safety for performance. Rust cheerleaders will tell you that its possible to avoid that trade-off, but the proof is in the pudding. Its become almost impossible to see a new OS project succeed in the current landscape, so maybe an entire AAA game written in Rust will be an interesting challenge.

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.

> Its become almost impossible to see a new OS project succeed in the current landscape,

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

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

Sure, if you’re talking about that, then Rust has more maintstream tools: a very strong and static type system, built in test framework, that kind of thing. You can help guard against logic bugs by using these tools more effectively, but they do require proficiency to use.

Right, but such tools are available across multiple programming languages, and the onus is on Test/QA to ensure that. Lets say that Rust eliminates memory crashing bugs by restricting certain freedoms afforded by C or C++. The problem of coordinating between multiple threads of who gets to do what when, and with which data and accurately capturing the intent of the programmer still exists. Now if you view the world through Rust-colored glasses, then any invalid state is the result of a programmer error because they used Rust incorrectly.

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! :)

Sure, I don’t disagree with any of this, which is why I said “more mainstream.”

OKay.. fair enough!

logic bugs + UI bugs + performance bugs < logic bugs + UI bugs + performance bugs + memory bugs

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

Well, I'm not opposed to it, as much as I have yet to "see the light". I think that the the original non-trivial problem of deciding which thread or which subroutine gets to change what piece of memory at what time is still there. The original problem was a logic bug, but it manifests as a memory bug in C.

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.

The showcase project for Rust is a web browser (after all, Rust started out at Mozilla), which is certainly one of the larger undertakings one can start nowadays.

Well, I personally wouldn't put any web-browser in the performance applications category. They are important applications, no doubt, and increasing their memory safety is always a plus. But there is something "soft realtime"/definitive about fitting the rendering of millions of textured-polygons, and running AI, Physics, data streaming, audio, gameplay code in a total budget of 16ms per-frame for hours and hours.

How is Firefox a showcase of Rusts performance when Chrome beats it in benchmarks?

https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...

Not to mention Firefox's poor state in macOS.

Rust is 6.5% of Firefox's code:

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.

What do you mean by it’s poor state in macOs? I use it as my main browser on macOs both at work and at home, and much prefer it over Chrome.

I envy you. There are complains of Firefox on macs on most Firefox-related threads. Ignore the titles and search comments in recent threads with significant number of comments: https://www.google.com/search?q=site:news.ycombinator.com+fi...

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.

According to the same benchmarks that test is a few versions older. Compare it to these and they are neck and neck (in theory). Consider that most benchmarking is subjective...depends on so many factors like is this Clear or Ubuntu Linux? Are the chipsets the same? The numbers are different here for "Speedometer" but between both tests there isn't enough information here even to say the tests are comparable just different. https://www.phoronix.com/scan.php?page=article&item=firefox-...

It's not. You may as well be comparing C++ to Swift. Chrome has had a lot more time and resources put into it anyway while Quantum has only seen release for two years.

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!

Keep in mind that, in kernel mode, things like garbage collection just won't work!

Feel like that's a common misconception: https://en.wikipedia.org/wiki/Midori_(operating_system)

http://programatica.cs.pdx.edu/House

Good thing rust doesn't have one.

I would argue that it actually might not matter too much:

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.

Could you please expand on this. When garbage collection works in applications and webservers that handle large number of requests, why wouldn't it work in OS kernel?

GC can create noticeable pauses in the whole windows UX because windows scales vertically in a machine not horizontally in a DC. And per another comment I made, if your OOM handler needs to JIT it can be catastrophic.

It introduces indeterminism into a system that strives to have as little as possible. You could of course, but you probably shouldn’t.

maybe it would? maybe somebody could create a co-processor just for that. sadly cpu's won't actually have specific extensions to have a good way of doing garbadge collection. but I guess it would be pretty helpful.

So, LISP machines?

maybe, without the brackets, of course.

Xerox PARC, ETHZ, DEC and MSR had other opinion regarding that.

Reply on news.ycombinator.com