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

Interview with Mitchell Hashimoto about Ghostty and Zig

alexalejandre.com

Post reply on HN
Print view View original

261–270 of 281 posts

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#261

Post by pjmlp »

tjoff wrote: post #227
wild_egg wrote: post #197

Earlier quoted context omitted.

Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well. The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.

I didn't say that. But if you think about memory then GC does more harm than good because you have no help from the language. A GC is not the only fix for UAF and buffer overruns...

Depends very much which programming languages we're talking about.

There are enough managed languages with knobs allowing to do C like coding when required to do so.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#262

Post by pjmlp »

asa400 wrote: post #201
torginus wrote: post #182

Earlier quoted context omitted.

Its academia. Rust is admirable for having been able interesting programming language research into a mainstream language, but this had the implication of bringing the people who did said research with it into the communities. It used to be that programming languages were mostly boring and predictable, with maybe questionable semantics (const etc.), but generally that messiness meant they were good enough at getting…

I've been using Rust in anger since ~2018 and I guess I've had completely different experience, especially compared to what I was mostly doing before, which was Scala. Scala (the v2 series, I haven't used v3 at all) was, to a first approximation, a language of, by, and for graduate students in language research that accidentally escaped the lab and briefly took over the data engineering space. Multiple competing cate…

Rust is becoming the chosen language for those that would have previously used Haskell, OCaml, Scala, but now get to use something with more mainstream mindshare.

It isn't very hard to find folks misusing unsafe to mean something else other than memory safety, or their own ZIO like frameworks.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#263

Post by pjmlp »

swiftcoder wrote: post #190
torginus wrote: post #184

Earlier quoted context omitted.

I use the terminal that happens to be at hand, which is usually the one that ships with the OS, or the one in VSCode. I don't have high demands on the terminal, and I don't understand what problems are there to solve, as long as it handles unicode and control sequences correctly.

> I don't understand what problems are there to solve, as long as it handles unicode and control sequences correctly. It turns out its not 1986 anymore, and sometimes we want to output gasp images to our terminals

We could already do that in 1986, outside UNIX.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#264

Post by Zambyte »

bmitc wrote: post #256
Zambyte wrote: post #252

Earlier quoted context omitted.

Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.

Do you have any examples as to how Zig is more simple than Rust? For the most part, I find Rust to be somewhat boring once you get past the initial learning curve of the borrow checker. It's almost uneventful code and reminds me a lot of writing code in F#. The only area that Rust feels very friction-y can be with async programming, but basically no language except Erland and Elixir make that frictionless.

> Do you have any examples as to how Zig is more simple than Rust?

On the surface: just the scale of the things you're expected to know in order to program in Zig vs the scale of things you're expected to know to program in Rust. I read the entire Zig language reference[0] in an afternoon, and then started comfortably writing Zig. I have been wanting to find time to read the Rust language reference[1] for years, but I have never carved out the time to do it, in large part because it simply demands so much more time. I end up just limping along looking up everything when I touch Rust.

I know you're hoping for more concrete examples though, so I'll try to give a few.

- One of the more obvious ones coming from a Zig perspective is the comptime story. Comptime in Zig is super easy, Rust macros less-so.

- In Zig, C libraries can be directly imported and C functions can be called directly. Rust requires (? maybe wants is more accurate?) bindings written in Rust.

- You mention Erlang and Elixir have frictionless async, and while they are essentially async utopias, I would put Golang not terribly far behind. The latest release of Zig introduced an async API that is very close to Golangs async API; I described the parallels in this comment[2]. Zig is certainly no Erlang, but the standard async API is quite nice, even when comparing to languages beyond the scope of ones with minimal runtimes like Rust and Zig.

It's hard for me to go into much more detail than that because I don't really have enough experience with Rust to say much more with confidence.

[0] https://ziglang.org/documentation/0.16.0 (though it was 0.14.0 at the time I read it end to end)

[1] https://doc.rust-lang.org/1.49.0/reference/

[2] https://news.ycombinator.com/item?id=48636824

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#265

Post by Zambyte »

pjmlp wrote: post #260
Zambyte wrote: post #252

Earlier quoted context omitted.

Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.

D and Swift integrate just as easily. Also languages do not exist in isolation, thus the question remains what product will drive Zig adoption, beyond its core community.

> D and Swift integrate just as easily.

Sure, but those languages are not Rust, which was what was asked about.

> Also languages do not exist in isolation, thus the question remains what product will drive Zig adoption, beyond its core community.

The Zig team seems to be banking on providing an excellent build system that is useful beyond applications written in Zig to fill this role.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#266

Post by tjoff »

pjmlp wrote: post #261
tjoff wrote: post #227

Earlier quoted context omitted.

I didn't say that. But if you think about memory then GC does more harm than good because you have no help from the language. A GC is not the only fix for UAF and buffer overruns...

Depends very much which programming languages we're talking about. There are enough managed languages with knobs allowing to do C like coding when required to do so.

Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#267

Post by steveklabnik »

Zambyte wrote: post #264
bmitc wrote: post #256

Earlier quoted context omitted.

Do you have any examples as to how Zig is more simple than Rust? For the most part, I find Rust to be somewhat boring once you get past the initial learning curve of the borrow checker. It's almost uneventful code and reminds me a lot of writing code in F#. The only area that Rust feels very friction-y can be with async programming, but basically no language except Erland and Elixir make that frictionless.

> Do you have any examples as to how Zig is more simple than Rust? On the surface: just the scale of the things you're expected to know in order to program in Zig vs the scale of things you're expected to know to program in Rust. I read the entire Zig language reference[0] in an afternoon, and then started comfortably writing Zig. I have been wanting to find time to read the Rust language reference[1] for years, but…

I’m curious: how did you get that link to the Rust reference? It’s to a five and a half year old version.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#268

Post by wild_egg »

tjoff wrote: post #266
pjmlp wrote: post #261

Earlier quoted context omitted.

Depends very much which programming languages we're talking about. There are enough managed languages with knobs allowing to do C like coding when required to do so.

Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.

That really, really depends on the language.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#269

Post by pjmlp »

tjoff wrote: post #266
pjmlp wrote: post #261

Earlier quoted context omitted.

Depends very much which programming languages we're talking about. There are enough managed languages with knobs allowing to do C like coding when required to do so.

Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.

It is perfectly convenient across D, Modula-2+, Modula-3, C#, Nim, Swift, Oberon, C++/CLI, and plenty others.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#270

Post by Zambyte »

steveklabnik wrote: post #267
Zambyte wrote: post #264

Earlier quoted context omitted.

> Do you have any examples as to how Zig is more simple than Rust? On the surface: just the scale of the things you're expected to know in order to program in Zig vs the scale of things you're expected to know to program in Rust. I read the entire Zig language reference[0] in an afternoon, and then started comfortably writing Zig. I have been wanting to find time to read the Rust language reference[1] for years, but…

I’m curious: how did you get that link to the Rust reference? It’s to a five and a half year old version.

Oops, I found it here: https://doc.rust-lang.org/stable/reference/#rust-releases

I just assumed it was a stable link to the version being read (in this case, the latest stable version).

Post reply on HN