Live data from Hacker News

Interview with Mitchell Hashimoto about Ghostty and Zig

alexalejandre.com

191–200 of 281 posts

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#191

Earlier quoted context omitted.

I've had rust developers quite often..tell me that it's immoral to use a language that doesn't have memory safety

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users? Me: You're right. Java has come a long way. Let's download... Rust: No! No no on. Not like that! --- Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn…

GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance.

For scripting etc. it is perfect though.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#192
post #155

Earlier quoted context omitted.

I think you're mistaking text-with-structured data for structured data itself. Because unix shell is irrevocably text-oriented, kludging in something like JSON is basically the best that can be done when you start to want to do structured operations on structured data. (I'm sympathetic to your point about the AWS CLI tools doing JSON by default though--that just sounds like bad design.) Being text-oriented imposes dr…

the point is well-taken, but i do want to show the bash version just for fun: podman image ls --all | sed 's/\s\s\+/\t/g' | tee >(head -n 1) >(tail -n +2 | sort -hrk 5) >/dev/null this is _still_ all text, and we're relying heavily on sort to do a bunch of internal parsing and be in agreement with podman about how sizes should be formatted. also, for "real world" work, i dunno if the tee trick here has any kind of or…

Ooh, I was so hoping someone would take up the challenge! This is a far shorter answer than I had honestly thought was possible. More readable too, somehow? Great use of tee that I would never have come up with (though I hear what you say about there maybe not being ordering guarantees).

Unfortunately, it's not 100% correct, due to misaligned headers:

  REPOSITORY TAG IMAGE ID CREATED SIZE
  registry.fedoraproject.org/fedora-toolbox 44 5a36f433c691 2 months ago 2.14 GB
  quay.io/keycloak/keycloak latest 1361d6e49205 9 days ago 478 MB
  ...
I think that speaks to your final point, which is spot-on:

> I'd probably just end up dropping the header and living with worse output in reality

This pretty much sums up plain text and unix shell imo. It's very much the pragmatic solution here, and it's what ~100% of shell scripters would choose to do. And it should make anyone question the orthodoxy around the "power" of plain text in shells.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#193
post #111

> I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it. I wonder if it's not that different people have entirely different experiences: If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (sm…

I just think it'a visually unappealing language.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#194

Earlier quoted context omitted.

I've had rust developers quite often..tell me that it's immoral to use a language that doesn't have memory safety

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users? Me: You're right. Java has come a long way. Let's download... Rust: No! No no on. Not like that! --- Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn…

If you're manually calling malloc in Rust, your code is almost certainly wrong. It might be called as an implementation detail when you create new objects, but std can generally be used as if it were managed automatically.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#195
post #191

Earlier quoted context omitted.

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users? Me: You're right. Java has come a long way. Let's download... Rust: No! No no on. Not like that! --- Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn…

GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance. For scripting etc. it is perfect though.

For a lot of programming tasks, HAVING to think about memory is a disservice.

That's part of the reason why Python, go, Ruby, etc. are so popular.

There is no one right answer, it's very dependent on what's being built and where the ROI for the programming effort comes from.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#196
post #155

This is the only statement I disagree with: > PowerShell gets a lot right with structured data. CLI programs should operate on text. If you want to parse and format it, do so, but the default output mode should be plain text, so that I can pipe it into grep or awk without a second thought. I am continuously irritated that the AWS CLI defaults to outputting in JSON. No one (I hope…) is using that tool in programs; tha…

I think you're mistaking text-with-structured data for structured data itself. Because unix shell is irrevocably text-oriented, kludging in something like JSON is basically the best that can be done when you start to want to do structured operations on structured data. (I'm sympathetic to your point about the AWS CLI tools doing JSON by default though--that just sounds like bad design.) Being text-oriented imposes dr…

    $ podman image ls --all --sort=size
…or was the point more about doing it in a pipeline?

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#197
post #191

Earlier quoted context omitted.

Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users? Me: You're right. Java has come a long way. Let's download... Rust: No! No no on. Not like that! --- Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn…

GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance. For scripting etc. it is perfect though.

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.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#198
post #111

> I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it. I wonder if it's not that different people have entirely different experiences: If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (sm…

I also do not like the Rust culture. I think the core problem is that it is so centered around identity, and this leaks into how the arguments are presented and how "outsiders" are judged. Which your example illustrates.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#199
post #136
post #111

> I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it. I wonder if it's not that different people have entirely different experiences: If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (sm…

Zealots are a problem in every community, sadly. Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead. The zealots just don’t understand (or acknowledge) how “all else being equal” does all the heavy lifting. As somebody who’s fascinated by programming languages in general…

> all else being equal, most C software would indeed benefit from being written in Rust instead

I don't even think this is true.

You can certainly say "the security of computer systems would be a little bit better if most software was written in memory safe languages" (even more so if you went a bit further and said "with automatic memory management").

However, a lot of software exists and is useful, and the only reason it exists is because the author(s) found a way they liked to express that software.

So, for example, there are millions of companies out there, especially small ones, running all their finances on Excel. Not even accounting software. Excel. I am totally OK with this. I do not need all these companies to rewrite their Excel workflows into frontend applications backed by a relational database, even though that would be "better" in a lot of ways (more robust, easier to backup, easier to bring someone else onto...). Those little business owners understand Excel and build models and count numbers and they're happy with that. If some kind of edict compelled them to use something "proper" instead, they might not even go into business, and the world would lose whatever it is their business does.

The same thing goes for software and languages. Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it. Some languages are a better "fit", sometimes for the problem domain, sometimes for the programmer's mind, sometimes for community building. It's difficult to compare any two languages because of this, and if you were to say "language X should not exist, all software written in X should've been written in language Y", you have to accept in your thought experiment that were that the case, their is likely a huge amount of software which would not exist just out of the people who made it not being happy about language Y and, if it were the only choice, would choose not to create the software they created in language X at all.

Re: Interview with Mitchell Hashimoto about Ghostty and Zig

#200
post #111

> I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it. I wonder if it's not that different people have entirely different experiences: If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (sm…

It’s like that joke: I admire Jesus Christ, it’s his fan club I really can’t stand.

You can substitute that with Rust and it sums up my feelings. The language is great, the obsession with static typing and memory safety from its fans, as if it’s the panacea to all problems in computing, is obnoxious and smells of inexperience. It’s not a coincidence that Rust these days is baby’s first low level language, so you get a lot of strong, uninformed opinions on software design.

Post reply on HN