Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mlugg
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
mlugg
1y ago
I mean... you use `await` if you've used `async`. It's your choice whether or not you do; and if you don't want to, your callers and callees can still freely `async` and `await` if they want to. I don't understand the po
32.
▲
by
mlugg
1y ago
Right, the proposal doesn't discuss the implementation details -- I do apologise if that made it seem a little hand-wavey. I opted not to discuss them there, because they're similar-ish to the way we lowered stackless async in its
33.
▲
by
mlugg
1y ago
> it depends on reintroducing a special function calling convention This is an internal implementation detail rather than a fact which is usually exposed to the user. This is essentially just explaining that the Zig compiler needs to f
34.
▲
by
mlugg
1y ago
We don't know whether or not we'll have stackless coroutines; it's possible that we hit design problems we didn't foresee. However, at this moment, the general consensus is that we are interested in pursuing stackles
35.
▲
by
mlugg
1y ago
I'm not sure how you got the perception that we're going "all in" on green threads, given that the article in OP explicitly mentions that we're hoping to have an implementation based on stackless coroutines, based o
36.
▲
by
mlugg
1y ago
The key difference to typical async function coloring is that `Io` isn't something you need specifically for asynchronicity; it's something which (unless you make a point to reach into very low-level primitives) you will need in o
37.
▲
by
mlugg
1y ago
This is simply not true. See https://zigbin.io/f57b94/run . (That link seems to show the "unused local variable" error line twice for me; that's some kind of bug with this zigbin service and does not repr
38.
▲
by
mlugg
1y ago
When targeting x86_64, the self-hosted backend is already enabled by default on the latest builds of Zig (when compiling in Debug mode). The self-hosted aarch64 backend currently isn't generally usable (so we still default to LLVM when
39.
▲
by
mlugg
1y ago
[edited to correct formatting] Your points here don't really make sense. There are many ways you can apply DoD to a codebase, but by far the main one (both easiest and most important) is to optimize the in-memory layout of long-lived o
40.
▲
by
mlugg
1y ago
The whole "stage1/2/3" jazz is about our bootstrap process; that is, the way you get a Zig compiler starting from nothing but a C compiler. This is a tricky problem because of the fact that the Zig compiler is written in
41.
▲
by
mlugg
1y ago
I believe (although I won't claim to know details) that Rosetta is unable to handle the code our self-hosted backend emit. I don't know whether it's related to the machine code or the Mach-O object, nor do I know in what way
42.
▲
by
mlugg
1y ago
The other comments get the general idea, but here's a slightly more detailed explanation. Code generation backends in the Zig compiler work by lowering an SSA-like structured IR called AIR to machine code (or actually first to another
43.
▲
by
mlugg
1y ago
I don't understand how you reached this conclusion. Nothing is decided for sure, but the plan is most likely to re-introduce stackless coroutines as a set of lower-level primitives [0], and support implementing the planned `std.Io` abs
44.
▲
by
mlugg
1y ago
[edited to fix a formatting problem, sorry!] Well, one interesting number is what happens when you limit the compiler to this feature set: * Compilation front-end (tokenizing/parsing, IR lowering, semantic analysis) * Our own ("se
45.
▲
by
mlugg
2y ago
The long-term plan is for Zig to expose some form of language server (not LSP) from the compiler itself, so it can use all the information it gets from doing the compilation. Incremental compilation is a key part of this plan, because it me
46.
▲
by
mlugg
2y ago
The compiler is set up so that this should be impossible! At the start of an "update", we mark parts of the dependency graph as "outdated" and "potentially outdated", based on which source code changed. From
47.
▲
by
mlugg
2y ago
I'm afraid I'm not sure what you're referring to. For instance, I can build a simple Hello World in Zig using `zig build-exe`, and get a static executable, on which I can use `nm` to confirm that there aren't symbols fro
48.
▲
by
mlugg
2y ago
I'm unsure what you're referring to here -- Zig doesn't have any runtime, it doesn't even depend on libc. The only thing I can think of that you might be referring to is compiler-rt: if so, this is a thing in C too! It&#
49.
▲
by
mlugg
2y ago
Also note that on Zig master, initializing `GeneralPurposeAllocator` like this is deprecated -- it'll be removed after the next release. Instead, you should do this: var gpa: std.mem.GeneralPurposeAllocator(.{}) = .init;
50.
▲
by
mlugg
2y ago
It's not actually about `*` -- for instance, declaring `const T = *T;` emits an error. The thing that makes this okay is that field types (for structs and unions) are evaluated in the "lazy" way you describe.
51.
▲
by
mlugg
2y ago
> Neat that you casually get an entire subnet for a rented computer. Here's a little more info on this, because it's fun: it looks like Hetzner give you a /64, which by convention is indeed the size of one IPv6 subnet. Tha
52.
▲
by
mlugg
3y ago
We have written proof-of-concepts for how incremental rebuilds will work in the Zig compiler, which can achieve incredible speed. Let's say you change a single constant value in a function (e.g. you change a string). The rebuild proces
53.
▲
by
mlugg
3y ago
> If anything this will further worsen LLVM-powered build-times, surely? What's the motivation here? The key motivation is that this will allow Zig to drop its dependencies on the LLVM libraries, instead using a separate LLVM compil
54.
▲
by
mlugg
3y ago
Hi, core team member here (I'm quoted in a parent comment!). The problem with LLVM is not that optimization is slow - it's perfectly acceptable for release builds to take arbitrarily long for optimal binaries. The problem is how l
55.
▲
by
mlugg
3y ago
I wrote a good chunk of these notes and can tell you that these are probably the least detailed/useful we've ever done, because they were only about 40% completed when release day came, so we spent a few hours doing quick & sl