Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finding and fixing Ghostty's largest memory leak

mitchellh.com

Post reply on HN
Print view View original

141–150 of 152 posts

Re: Finding and fixing Ghostty's largest memory leak

#141

Post by AndyKelley »

hardwaresofton wrote: post #117
AndyKelley wrote: post #86

Earlier quoted context omitted.

If you wanted to match Ghostty's performance in Rust, you'd need to use unsafe in order to use these memory mapping APIs, then you'd be in the exact same boat. Actually you'd be in a worse boat because Zig is safer than unsafe Rust.

> If you wanted to match Ghostty's performance in Rust, you'd need to use unsafe in order to use these memory mapping APIs, then you'd be in the exact same boat. Yea, but not for all the parts — being able to isolate the unsafe and build abstractions that ensure certain usage parts of the unsafe stuff is a key part of high quality rust code that uses unsafe. In this case though I think the emphasis is on the fact tha…

Thank you for the kind words.

> every line of C/Zig is unsafe

This is trivially false... for instance here's a line:

    const pi = 3.14;
It's actually a pretty small subset of the language that can cause unchecked illegal behavior.

Also IMO the word "safety" should include integer overflow. I don't agree that those kind of bugs are so unimportant as to not be checked in safe builds.

Re: Finding and fixing Ghostty's largest memory leak

#142

Post by AndyKelley »

vlovich123 wrote: post #124
uecker wrote: post #108

Earlier quoted context omitted.

Also in C or Zig you do not need to create your own memory management using mmap. Whether this is necessary in this case or not is a different question. In the end, if the Rust advantage is that "Rust's technical design reinforces a culture" where one tries to avoid this, then this is a rather weak argument. We will see how this turns out in the long run though.

The long run has already spoken. Go look at the reports out of Microsoft and Android. It’s screamingly clear that the philosophy of Rust that most code can be written in safe with small bits in unsafe is inherently safer. The defect rate plummets by one or two orders of magnitude if I recall correctly. C is an absolute failure (since it’s the baseline) and Zig has no similar adoption studies. You could argue it will…

Microsoft and Google are on the Rust Foundation board:

https://rustfoundation.org/about/

They benefit by having more of the industry using technologies they control.

Studies from independent third parties would be less biased.

Re: Finding and fixing Ghostty's largest memory leak

#143

Post by hardwaresofton »

AndyKelley wrote: post #141
hardwaresofton wrote: post #117

Earlier quoted context omitted.

> If you wanted to match Ghostty's performance in Rust, you'd need to use unsafe in order to use these memory mapping APIs, then you'd be in the exact same boat. Yea, but not for all the parts — being able to isolate the unsafe and build abstractions that ensure certain usage parts of the unsafe stuff is a key part of high quality rust code that uses unsafe. In this case though I think the emphasis is on the fact tha…

Thank you for the kind words. > every line of C/Zig is unsafe This is trivially false... for instance here's a line: const pi = 3.14; It's actually a pretty small subset of the language that can cause unchecked illegal behavior. Also IMO the word "safety" should include integer overflow. I don't agree that those kind of bugs are so unimportant as to not be checked in safe builds.

> Thank you for the kind words.

Absolutely, I meant them.

> This is trivially false... for instance here's a line:

Yep, that was really wrongly stated on my part -- what I meant is that the kind of protections that "safe" Rust provides are not available anywhere in average lines of Zig code (though they can be detected with tooling, etc).

What I should have written is that I could easily write unsafe code anywhere in Zig (as in C). In practice of course most people don't because they're not trying to destroy their own computers, and most code is benign. Rust will at least save me from myself some of the time.

> Also IMO the word "safety" should include integer overflow. I don't agree that those kind of bugs are so unimportant as to not be checked in safe builds.

Rust does do some work to catch trivial overflows, but you're right that it does not catch any slightly more complex overflows, and that is certainly unsafe in a sense. I don't think any reasonable person would disagree with that.

Rust's answer to this of course is checked_{op}/wrapping_{op}/etc options, and that's what I often see in high quality codebases where it matters. Of course, this is a footgun that could have had a safety applied and it's too late now (AFAIK) to change the default to be always wrapping or something (also, I think people may oppose always checked for perf reasons).

[EDIT] Just to compare/make this more concrete, playgrounds:

https://zig.fly.dev/p/LGnrBGXPlVJ

https://play.rust-lang.org/?version=stable&mode=release&edit...

Rust in this case of doing something obviously wrong is at least a little more helpful -- the obvious overflow does not compile.

And of course you can get rust to do it like it allows (and what would be present in any codebase with real complexity):

https://play.rust-lang.org/?version=stable&mode=release&edit...

It's just that little bit of safety that makes it easy for me (personally) to default to Rust. Very possible that someday that won't be true.

[EDIT2] Also, somewhat under-discussed, but if Zig supported a bolt-on a "safety check compile mode" that ran with some stricter (maybe not quite borrow checking level) semantics, that would be pretty dope. Of course not something anyone should devote any real time to for a long time (or ever?) BUT it would trivialize a lot of these discussions maybe.

But in the mean time people just using what they're comfortable with/the feel they want is obviously fine.

Re: Finding and fixing Ghostty's largest memory leak

#144

Post by vlovich123 »

AndyKelley wrote: post #142
vlovich123 wrote: post #124

Earlier quoted context omitted.

The long run has already spoken. Go look at the reports out of Microsoft and Android. It’s screamingly clear that the philosophy of Rust that most code can be written in safe with small bits in unsafe is inherently safer. The defect rate plummets by one or two orders of magnitude if I recall correctly. C is an absolute failure (since it’s the baseline) and Zig has no similar adoption studies. You could argue it will…

Microsoft and Google are on the Rust Foundation board: https://rustfoundation.org/about/ They benefit by having more of the industry using technologies they control. Studies from independent third parties would be less biased.

More FUD and guilt by association. Microsoft and Google are also major contributors to the C and C++ standards bodies. Microsoft also has C# and Google has Kotlin. I think claiming they control Rust is weak given the community organization structure within the project and claiming the studies are inherently biased because they provide some funding is exceedingly weak.

IMHO the onus is on you to present any contrary studies showing Rust's safety profile isn't as good as the studies indicate when compared with C++ or to demonstrate where Zig's safety profile in real world complex environments stacks up.

We can disagree on opinions, but you can't discard all experimental evidence in favor of no evidence, especially when the safety profile of Rust is backed by solid theoretical models as to why it would be safer.

To that point, AWS and Cloudflare have also adopted the Rust language for all new projects. I think that says something about the recognition that it really is much harder to write trivial memory vulnerabilities.

Re: Finding and fixing Ghostty's largest memory leak

#145

Post by tialaramex »

hardwaresofton wrote: post #143
AndyKelley wrote: post #141

Earlier quoted context omitted.

Thank you for the kind words. > every line of C/Zig is unsafe This is trivially false... for instance here's a line: const pi = 3.14; It's actually a pretty small subset of the language that can cause unchecked illegal behavior. Also IMO the word "safety" should include integer overflow. I don't agree that those kind of bugs are so unimportant as to not be checked in safe builds.

> Thank you for the kind words. Absolutely, I meant them. > This is trivially false... for instance here's a line: Yep, that was really wrongly stated on my part -- what I meant is that the kind of protections that "safe" Rust provides are not available anywhere in average lines of Zig code (though they can be detected with tooling, etc). What I should have written is that I could easily write unsafe code anywhere in…

If you want "overflow-checks" in release builds for the primitive integer types you can tell Cargo that you want this, some people do so. https://doc.rust-lang.org/cargo/reference/profiles.html

Although Rust provides Wrapping if you want that, in practice you don't want that, wrapping unsigned integers are occasionally useful and I've written code with Wrapping and Wrapping types, but wrapping signed integers basically never come up. However it is significantly faster and it remains well defined so that's why it was chosen for release builds.

Re: Finding and fixing Ghostty's largest memory leak

#146

Post by uecker »

vlovich123 wrote: post #139
uecker wrote: post #137

Earlier quoted context omitted.

I don't put too much wait on the self-reporting by Microsoft or Google. I agree though that the strategy to write safe bits and abstractions is good. What I know not to be true is the idea that similar strategies would not work also in C.

> What I know not to be true is the idea that similar strategies would not work also in C. Is your argument that developers at MS and Google haven’t been trying to employ these strategies for existing C codebases? It’s a bold position to take and one I’d say devoid of evidence; all the evidence suggests it’s really hard to reason about ownership in complex systems and abstractions only help you do so error free up to…

I know for sure that Microsoft does not, because they are not interested in C (and there compiler does not even fully support recent standards) and I assume the same thing about Google. I general, I do not think they write much C in the first place. I also think their use cases and priorities are different from others.

Re: Finding and fixing Ghostty's largest memory leak

#147

Post by uecker »

vlovich123 wrote: post #140
uecker wrote: post #136

Earlier quoted context omitted.

I am not saying that safety culture is irrelevant, not at all. I am saying that if the advantage of Rust is the culture that emphasizes safety (or rather memory safety, if the Rust community cared about safety in general cargo would not exist in this form) then that is a weak argument. I don't think 10 years ago there was a lot of Rust used, so I am not sure how relevant it is that 1.0 was released at this time.

The culture of Rust is pretty uniform both in terms of convention (lots of good examples to learn from) and automated tooling (eg cargo clippy can fix many constructs into cleaner versions). But sure, ultimately any code you see is limited by the talent of the author. However the safety of that code is not - it’s limited by how many unsafe blocks they wrote which you can actually grep for.

This is a naive and dangerous view of "unsafe". The safety of surrounding code depends on the unsafe blocks not violating invariants of safe Rust, and the safety of "unsafe" blocks may rely on assumptions about the safe part. Also it relates only to memory safety, so if your code review is to grep for "unsafe" blocks you are doing it wrong anyway.

Re: Finding and fixing Ghostty's largest memory leak

#148

Post by hardwaresofton »

tialaramex wrote: post #145
hardwaresofton wrote: post #143

Earlier quoted context omitted.

> Thank you for the kind words. Absolutely, I meant them. > This is trivially false... for instance here's a line: Yep, that was really wrongly stated on my part -- what I meant is that the kind of protections that "safe" Rust provides are not available anywhere in average lines of Zig code (though they can be detected with tooling, etc). What I should have written is that I could easily write unsafe code anywhere in…

If you want "overflow-checks" in release builds for the primitive integer types you can tell Cargo that you want this, some people do so. https://doc.rust-lang.org/cargo/reference/profiles.html Although Rust provides Wrapping if you want that, in practice you don't want that, wrapping unsigned integers are occasionally useful and I've written code with Wrapping and Wrapping types, but wrapping signed integers basical…

Those are great points, thanks for mentioning this, re-enabling overflow checks for release builds would indeed make the code safer with only a config change.

It's great that there are lots of options other than wrapping as well, checked, saturating, etc -- that at the cost of a little inefficiency make code that is robust to such failures really obvious.

Re: Finding and fixing Ghostty's largest memory leak

#149

Post by smoyer »

neobrain wrote: post #116
smoyer wrote: post #113

Earlier quoted context omitted.

Why would I move to GhosTTY versus the terminal emulator that comes with my OS as it's not clear to me from the documentation?

I don't think I can do a better overview than https://ghostty.org/docs/about . It's not world-changing but simply a very polished, well-executed terminal. GPU rendering virtually eliminates typing latency. Most terminals that have it don't support native content like tabs, but Ghostty gets minimal latency without having to compromise on essentials since it uses native toolkits under the hood. The modern TTY has lots…

I wish a couple of those paragraphs were on the home page!

Re: Finding and fixing Ghostty's largest memory leak

#150

Post by uecker »

vlovich123 wrote: post #144
AndyKelley wrote: post #142

Earlier quoted context omitted.

Microsoft and Google are on the Rust Foundation board: https://rustfoundation.org/about/ They benefit by having more of the industry using technologies they control. Studies from independent third parties would be less biased.

More FUD and guilt by association. Microsoft and Google are also major contributors to the C and C++ standards bodies. Microsoft also has C# and Google has Kotlin. I think claiming they control Rust is weak given the community organization structure within the project and claiming the studies are inherently biased because they provide some funding is exceedingly weak. IMHO the onus is on you to present any contrary s…

Neither Microsoft nor Google contribute to C standardization.
Post reply on HN