pron

3 ms·

1.
by pron 5d ago
> As far as I understand it comptime is basically runtime compilation and integration into the running program (just-in-time compilation). That gives it great flexibility of course but it also requires each Zig application to carry a ful
2.
by pron 6d ago
Well, the problems don't start after 20 years but after 5 or so (depending on the size of the codebase and the rate of the application's evolution), and the reason there aren't many large and oldish Rust codebases isn't
3.
by pron 6d ago
It's not theoretical, it's one of the main reasons many large applications abandoned C++, and there's absolutely no reason for it to not exist in Rust. All low-level languages suffer from expensive evolution for fundamental r
4.
by pron 6d ago
sorry, the "and" was a typo
5.
by pron 6d ago
> But this should be up and front in their self-promotion! It is! "A fresh approach to metaprogramming based on compile-time code execution and lazy evaluation" is the second selling point after simplicity: https://z
6.
by pron 6d ago
For me it's because Zig presents a novel and even revolutionary new coherent design for low-level programming, whereas D is mostly a collection of many ideas, many of them are good, but they don't coalesce into a simple design phi
7.
by pron 6d ago
Benign write/write races (when multiple threads do unordered writes of the same value to the same address) are quite common and useful, both in parallel algorithms and in lazy initialisation. Useful benign read/write races are far
8.
by pron 6d ago
> i find it fascinating how big of a rust hater you are. willing to outright lie to make your point.. because you can do this with_allocator You say I outright lie for not mentioning the existence of something that doesn't exist??
9.
by pron 6d ago
It is entirely novel. As I wrote, what makes the design revolutionary isn't the partial evaluation mechanism itself, but how the language is organised around it. It's like what made the iPhone's design revolutionary wasn&#x27
10.
by pron 7d ago
This is true. In Java, we have a notion we call "integrity", which is a generalisation of memory safety and includes a host of properties guaranteed by the platform. It includes memory safety, but also things like "a non-publ
11.
by pron 7d ago
Many more C programs have been verified than Rust programs. Also, Zig's spatial and memory safety is as good as Rust's, so it's not really similar to C at all. The reason it's not "the norm" is that (especially
12.
by pron 7d ago
When that is the case (and it isn't yet; and remember that it's not only the containers, and strings, that need to be parameterised, but any routine that allocates them, transitively), then that's what Zig does. But the quest
13.
by pron 7d ago
I don't know exactly how specific you want to be, but sure, because we've come across this countless times in C++, which suffers from the exact same problem. Suppose you're writing a program that's mostly high-level, say
14.
by pron 7d ago
> but rust has crates like bumpalo for that purpose. Except that's not composable - not only do you need specialised data structures, but all (transitively) allocating calls need to be specialised. That's the exact same issue w
15.
by pron 7d ago
They're not separate forms but they are separate modes, and it is precisely because the language tries to fit both these modes into the same language that both suffer. I fully understand the goal of trying to unify these modes into the
16.
by pron 7d ago
That's always been true in all the safe languages with unsafe escape hatches, except here these "primitives" are the main reason to reach for a low-level language in the first place - because they presumably require the contr
17.
by pron 7d ago
> I don't understand the hype about Zig? As a long-time low-level programmer, and as someone working on a popular mainstream language, I find Zig fascinating, and I also think it addresses a long-standing problem in low-level progra
18.
by pron 8d ago
> But if it needs one language for programming, machine code, why is that the optimal and only one for every application? Why would any other specific language be? Machine code is the most general and, as I said, if the AI wants to use a
19.
by pron 8d ago
It needs a special language for both. Machine code is a special language for programming, and since this is an exercise in imagining what an AI that could do anything would do, I don't see why it would need anything else. Machine code,
20.
by pron 8d ago
We used to write programs without a compiler. We'd write them in Assembly. The AI won't even need the assembler. If verification is done through formal proofs, a logic language is, indeed, needed, but the program itself could rema
21.
by pron 9d ago
Yes, but also, who do you gather requirements from? Other people. But if we're talking AGI, then these other people, i.e. users - or at least those who define the requirements - could be replaced, too.
22.
by pron 9d ago
> In the post-AGI economy, humans will eventually stop writing and reading code, but we still need an ambiguity-free way to tell the AIs building the world around us what we want done. Why? Won't an AI that can correctly write any p
23.
by pron 9d ago
> For example, when developing two modules (possibly even by different teams), all they know about each other is a lean interface, without any implementation details. However, the compiler might know everything. You're talking about
24.
by pron 10d ago
Yes, this is why we're doing automatic heap sizing :)
25.
by pron 10d ago
By time and time again I meant concurrent services that are written by people who are not experts at low-level programming. The irony is that they don't see "CPU spent on memory management" as they do in Java not because ther
26.
by pron 10d ago
It's quite common in concurrent services that non-experts write. But the more interesting cases are things like Moka. In a simple evaluation (and, of course, not much can be extrapolated from any benchmark) Java's old Caffeine lib
27.
by pron 10d ago
> A 500KLOC codebase in Java would usually be half that size in Rust Ok, so you barely know either Java or Rust. > If your argument is that large codebases makes life harder for agents, you should go with a less verbose language. You
28.
by pron 10d ago
> There are many things that can be inferred from the code without needing to execute it. The question is how difficult it is to make such an inference: in one scenario, the compiler might attempt to track whether specific data changes-a
29.
by pron 10d ago
When CPU utilisation is low, the heap can be set much smaller. Many don't know that, so in the next year we'll have the VM do it automatically: https://openjdk.org/jeps/8377305 The amount of memory a Java pro
30.
by pron 10d ago
> And moving GC is terrible for memory bandwidth compared to both Go-style concurrent GC (which doesn't have to do bulk moves) and manual memory management. This is not true. The whole point of the algorithm - the reason it was desi

More ›