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

How Our Rust-to-Zig Rewrite Is Going

rtfeldman.com

Post reply on HN
Print view View original

121–130 of 336 posts

Re: How Our Rust-to-Zig Rewrite Is Going

#121

Post by steveklabnik »

dminik wrote: post #118
andriy_koval wrote: post #100

Earlier quoted context omitted.

> In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..

I work both on a pretty much bog-standard web (GraphQL) backend and the frontend that uses it. We switched over from Apollo on node to async-graphql on Rust. The runtime performance is much better, but the compiler time performance is terrible. To be fair, this is mostly the fault of async-graphql, but that doesn't really matter all that much. For example, it's not uncommon for a single character SQL query change to…

For whatever it's worth, I share some of your async-graphql woes, though I haven't investigated things deeply enough to have strong opinions about what to do instead.

Re: How Our Rust-to-Zig Rewrite Is Going

#122

Post by steveklabnik »

inigyou wrote: post #120
AlotOfReading wrote: post #101

Earlier quoted context omitted.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?

Memory safety is:

1. Foundational for other forms of safety

2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective.

That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.

Re: How Our Rust-to-Zig Rewrite Is Going

#123

Post by nvme0n1p1 »

inigyou wrote: post #88
AlotOfReading wrote: post #65

Earlier quoted context omitted.

I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.

I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.

That would mean no language can ever be considered safe, because any language can emit bytes to a file that will later be executed.

Re: How Our Rust-to-Zig Rewrite Is Going

#124

Post by skissane »

inigyou wrote: post #120
AlotOfReading wrote: post #101

Earlier quoted context omitted.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?

> Why do we want a very specific form of safety instead of wanting safety in general?

Because a “very specific form of safety” is a useful tool in achieving “safety in general”

Because a “very specific form of safety” is tractable for a compiler and language runtime to achieve, “safety in general” isn’t

Re: How Our Rust-to-Zig Rewrite Is Going

#125

Post by giancarlostoro »

epage wrote: post #80
giancarlostoro wrote: post #31

One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be…

We are trading away disk space for faster builds. We could make them faster in some cases by using even more... On the other hand, it would be good to garbage collect those caches. We are wrapping up work on a new layout for intermediate build artifacts that will make it easier to GC them.

Sounds like what I was thinking, that or for third party deps to go into the same temp folder, and anything not accessed in over a week, or so just gets auto wiped by rustc / cargo build process?

Re: How Our Rust-to-Zig Rewrite Is Going

#126

Post by munificent »

norir wrote: post #106

This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler https://www.roc-lang.org/faq#self-hosted-compiler and from that concluded that their only choice besides rust was zig. I know from experience that this in…

Your comment is very assertive, but also doesn't offer much in the way of science.

Being able to compile ML quickly in the 90s tells you little about being able to compile Roc or some other language today because the language design enforces hard constraints on the algorithms necessary to compile it and the hardware today is much more complex. It's not hard to write a fast Pascal compiler that targets a 1980s chip with shallow pipelines. But that's not the problem being solved here.

I don't know much about Roc but it looks like it's got some amount of overloading and the linked article alludes to sophisticated algorithms to avoid heap allocating closures. Those can enforce algorithmic complexity in the compiler that is essential and can't be eliminated.

Once you're at the limits of algorithmic optimization, all that's left is reducing constant factors. I've written code in many languages in different performance regimes over the years and it's certainly the case that higher level languages, especially managed memory ones, put a hard floor in terms of how low you can go when optimizing to improve those constant factors.

I have seen in real-world code where explicit control over memory layout improved performance by more than an order of magnitude. I have friends in the game industry where much of their career is this kind of work. Those people would love to live in the luxurious world you describe where all they need to do is find a sufficiently clever algorithm and all of their performance problems will disappear.

Re: How Our Rust-to-Zig Rewrite Is Going

#127

Post by giancarlostoro »

inigyou wrote: post #84
tredre3 wrote: post #73

Earlier quoted context omitted.

Rust isn't great, and it shouldn't be a surprised since it's designed after npm. However one metric where nodes_modules is still worse for me is the sheer number of small files in it. Having nearly one million files in nodes_modules isn't that unusual. The problem is that on most common file systems the minimum allocation is usually at least 4KB. So even if the actual data is less than 500MB, you end up with 4GB disk…

I wish ext4 had a feature to mark a file as "atomic" where it would allocate all atomic files in a long run, without room for expansion, and I suppose with very inefficient compaction upon deletion, but without any padding bytes.

A file “pointer” for byte exact files, pointer gets ditched for files that get updated or the pointer gets adjusted to another common file.

Re: How Our Rust-to-Zig Rewrite Is Going

#128

Post by [deleted] »

inigyou wrote: post #120
AlotOfReading wrote: post #101

Earlier quoted context omitted.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?

[deleted]

Re: How Our Rust-to-Zig Rewrite Is Going

#129

Post by nvme0n1p1 »

inigyou wrote: post #120
AlotOfReading wrote: post #101

Earlier quoted context omitted.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?

> safety in general

This is impossible. General words like "safe" and "good" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.

Re: How Our Rust-to-Zig Rewrite Is Going

#130

Post by lioeters »

pjmlp wrote: post #95
veber-alex wrote: post #37

Earlier quoted context omitted.

It's impossible to add a borrow checker to any existing language. The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking. It's is not something you can just tack on to an existing language without fundamentally changing it.

Swift, Linear Haskell, Chapel, Ada/SPARK are all counter examples from such claim.

Also OxCaml, from what I hear.
Post reply on HN