Mostly unrelated, but I recently built a small utility in Zig, Hare, Go, Odin, and V.
I never completed the Odin / V implementations since their standard libraries didn't have argon2 (a requirement for me).
Of the group, I liked Odin's syntax and feel best. Hare was also very nice. But Zig's optimized binary sizes were unbeatable. 96KB vs 500KB for Hare and 2.5MB for Go.
Zig's standard library and tooling are impressive. Personally, I wish more projects were written in Zig instead of Rust since Zig doesn't seem to have the package explosion problem that Rust has.
There isn't anything fundamental about Zig that makes it immune from package explosion. It simply isn't popular and stable enough for that to have happened yet.
Zig's standard library is structured so that you only compile what you need, so Zig has no problems adding richer functionality to its standard library. This is influenced by Zig's decision to only have a single compilation unit per compile.
HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that. This helps control package explosion.
Why do you think Zig won't have the same issue? In my experience lack of packages seem to come from no standard place to put them (C++, then you end up with effective package stores like Boost), or just not popular enough.
Most languages I work on (Rust, Python, JavaScript, Haskell), have a huge number of packages.
I think that the "package explosion problem" actually does exist in C/C++ and Go but it's just hidden. Very often a project takes the form of various components, and you only depend on a subset of them. In these older-style languages these are all shipped as a single unit, but in newer languages these are shipped more explicitly so you can see what the shape of your dependency tree really looks like.
Boost is a great example of this, since it does a ton of different things, but the boundaries between components are not quite as obvious as having a "dependencies.lock" to look at. Tokio has a ton of different packages but often you only need a few of them.
Its was so nice to just quickly write up a static file server.
Just to play with wasm without needing to use the usual python http server thingy.
I was told the std.http.* isn't meant to be used for production servers but its nice that i now have a drop in zig file that contains a very very... bare bones static file server i can add to zig projects that might need it.
Just use Instruments. Yes, I know it’s slow, but it’s miles ahead of anything on Linux. If you’re looking for an identical profiling experience on macOS as you get on Linux you’re greatly missing out.
Other than just the niceness of the interface, a key one is that the M4 generation added profiling of CPU branching and afaik instruments is the only thing that supports it right now
For low-overhead Zig profiling on Apple Silicon, you can also use DTrace with the pid provider to sample stacks without modifying your code or relying on Instruments' UI.
Mostly unrelated, but I recently built a small utility in Zig, Hare, Go, Odin, and V.
I never completed the Odin / V implementations since their standard libraries didn't have argon2 (a requirement for me).
Of the group, I liked Odin's syntax and feel best. Hare was also very nice. But Zig's optimized binary sizes were unbeatable. 96KB vs 500KB for Hare and 2.5MB for Go.
Zig's standard library and tooling are impressive. Personally, I wish more projects were written in Zig instead of Rust since Zig doesn't seem to have the package explosion problem that Rust has.
There isn't anything fundamental about Zig that makes it immune from package explosion. It simply isn't popular and stable enough for that to have happened yet.
Zig's standard library is structured so that you only compile what you need, so Zig has no problems adding richer functionality to its standard library. This is influenced by Zig's decision to only have a single compilation unit per compile.
HTTP, for example, can go into Zig's standard library, whereas C or Rust cannot do that. This helps control package explosion.
9 replies →
Why do you think Zig won't have the same issue? In my experience lack of packages seem to come from no standard place to put them (C++, then you end up with effective package stores like Boost), or just not popular enough.
Most languages I work on (Rust, Python, JavaScript, Haskell), have a huge number of packages.
I think that the "package explosion problem" actually does exist in C/C++ and Go but it's just hidden. Very often a project takes the form of various components, and you only depend on a subset of them. In these older-style languages these are all shipped as a single unit, but in newer languages these are shipped more explicitly so you can see what the shape of your dependency tree really looks like.
Boost is a great example of this, since it does a ton of different things, but the boundaries between components are not quite as obvious as having a "dependencies.lock" to look at. Tokio has a ton of different packages but often you only need a few of them.
2 replies →
Its was so nice to just quickly write up a static file server. Just to play with wasm without needing to use the usual python http server thingy.
I was told the std.http.* isn't meant to be used for production servers but its nice that i now have a drop in zig file that contains a very very... bare bones static file server i can add to zig projects that might need it.
Just use Instruments. Yes, I know it’s slow, but it’s miles ahead of anything on Linux. If you’re looking for an identical profiling experience on macOS as you get on Linux you’re greatly missing out.
What kind of extra functionality are you getting from Instruments that isn't covered by other tools?
Other than just the niceness of the interface, a key one is that the M4 generation added profiling of CPU branching and afaik instruments is the only thing that supports it right now
1 reply →
An interface designed around finding real bottlenecks instead of "here is some data do you think it is good".
XCode is painful but I always miss Instruments whenever I'm profiling something on my Linux systems
perf top
1 reply →
This is cool! I'm anxious to dig into Zig on an M1, and this helps.
Side note, the CSS is broken for me in Safari—I get this error:
For low-overhead Zig profiling on Apple Silicon, you can also use DTrace with the pid provider to sample stacks without modifying your code or relying on Instruments' UI.