I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though.

[1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

▲

vanderZwan 3 days ago | parent [-]

Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.

▲

dadrian 3 days ago | parent [-]

Not clear to me there's a correlation between hours worked and number of memory safety vulnerabilities

▲

blacksmith_tb 3 days ago | parent [-]

I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".

▲

tptacek 3 days ago | parent [-]

The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.

▲

vanderZwan 2 days ago | parent [-]

I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.

	▲	timschmidt 2 days ago \| parent \| next [-]
		I'm no expert, but I've been hacking in Rust for several years now, and the only unsafe I've written was required as part of building a safe interface over some hardware peripherals. Exactly as intended. The borrow checker is something new Rust devs struggle with for a couple months, as they learn, then the rules are internalized and the code gets written just like any other language. I think new devs only struggle with the borrow checker because everyone has internalized the C memory model for the last 50 years. In another 50, everyone will be unlearning Rust for whatever replaces it.
	▲	dadrian 2 days ago \| parent \| prev [-]
		Web browsers and operating systems are full of memory safety bugs, and are not written by engineers in crunch these days.