|2 days ago
|3 days ago
|BSD 3-clause "New" or "Revised" License
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Show HN: Tokamak – A Dependency Injection-Centric Server-Side Framework for Zig
6 projects | news.ycombinator.com | 5 Feb 2024
Atop your readme, you point out that nginx or another reverse proxy should be used. Kudos for that.
As for performance, I'd be curious what gains you get using `std.http.Server` with keepalive and a threadpool. Possibly you can re-use your ThreadContext - having 1 per thread in the threadpool that you can re-using. `std.Thread.Pool` is also very poorly tuned for a large number of small batch jobs, but that's a place to start.6 projects | news.ycombinator.com | 5 Feb 2024
Yes, fundamentally. In Rust if you take a parameter of generic type T without any bounds, you cannot call anything on it except for things which are defined for all types. If you specify bounds, only things required by the bounds can be called (+ the ones for all types). Another difference is where you get an error when you try pass something which doesn't adhere to a certain trait. In Rust you will get an error at the call site, not at the place of use (except if you don't specify any bounds).
Zig is doing just fine without any trait mechanism and it simplifies the language a lot but it does come up from time to time. The usual solution is to just get type information via @typeInfo and error out if the type is something you're not expecting . Not everybody is happy about it though  because, among other things, it makes it more difficult to discover what the required type actually is.
New Linux glibc flaw lets attackers get root on major distros
7 projects | news.ycombinator.com | 4 Feb 2024
It's not so unusual to write the C runtime library in a different language.
E.g. Zig is getting a libc written in Zig:
Rust would work too of course.
Zig Roadmap 2024 [video]
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 long it takes to emit debug builds.
Take building the Zig compiler itself in Debug mode. This process takes about 30 seconds running through the Zig pipeline (semantic analysis and generating LLVM IR), and then 90 seconds just spent waiting for LLVM to emit the binary. OTOH, when using our self-hosted x86_64 backend (which is now capable of building the compiler, although is incomplete enough that it's not necessarily integrated into our development cycle quite yet), that 30 seconds is essentially the full build (there are a couple of extra seconds on the end flushing the ELF file).
I can tell you from first-hand experience that when fixing bugs, a huge amount of time is wasted just waiting for the compiler to build - lots of bugs can be solved with relative ease, but we need to test our fixes! Rebuilds are also made more common by the fact that LLVM has an unfortunate habit of butchering the debug information for some values even in debug builds, so we often have to rebuild with debug prints added to understand a problem. Making rebuilds 75% faster by just ditching LLVM would make a huge difference. Introducing incremental compilation (which we're actively working on) would make these rebuilds under a second, which would improve workflows a crazy amount. This would hugely increase our development velocity wrt both bugfixes and proposal implementation.
It's also important to note that we have quite a few compiler bugs which are [caused by upstream LLVM bugs](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen...). LLVM often ships with regressions which we report before releases come out and they simply don't fix. In the long term, eliminating the use of LLVM as our main code generation backend will mean that all bugs encountered are our own, and thus can be solved more easily.
> 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 compilation to compile the bitcode file. This is nice because it simplifies the build process and drops the Zig compiler binary size by a full order of magnitude - see https://github.com/ziglang/zig/issues/16270 for more deatils on that. It also allows us to implement incremental compilation on the bitcode file itself to drop compile times a little, which isn't really possible to do through the LLVM API since it doesn't implement certain operations.
In terms of speed, there's no reason to expect this will worsen our build times; in fact, we expect it will be faster. As with any common C++ API, LLVM's IRBuilder comes with a lot of overhead from how LLVM is written. What we're going to do here is essentially the same work that IRBuilder is doing, but in our own code, for which we will be focusing on performance.
You can find more details on this at https://github.com/ziglang/zig/issues/13265.
> ...but that doesn't mean LLVM was easy to develop.
To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability.
Thanks for the detailed reply.
> You can find more details on this at https://github.com/ziglang/zig/issues/13265.
Thanks for the link, my thoughts mirror those of certik in the thread, which Andrew answered well.
> at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability
Perhaps a useful point of comparison: the lightweight qbe C compiler achieved compile times of around a quarter that of GCC and Clang, with the generated code taking very roughly 170% as long to execute as the code from GCC or Clang. qbe has roughly 0.1% the lines of code as those 'big' compilers.  This should presumably be possible for Zig too, and could be a big win for Zig developers.
Closing the performance gap with LLVM though would presumably be extremely challenging and, respectfully, I can't see the Zig project achieving this. Compiler optimisation seems to be a game of diminishing returns. Even if this were achieved, optimised compilation would surely be much slower than unoptimised.
 https://archive.fosdem.org/2022/schedule/event/lg_qbe/attach... (Relevant discussion: https://news.ycombinator.com/item?id=11555527 )
Passing nothing is surprisingly difficult
2 projects | news.ycombinator.com | 16 Jan 2024
Speed up your code: don't pass structs bigger than 16 bytes on AMD64
3 projects | news.ycombinator.com | 4 Jan 2024
> I think this is the same in the still experimental Carbon
Apparently, it's not (anymore?):3 projects | news.ycombinator.com | 4 Jan 2024
Pass by value / pass by ref is quite a bit of mental overhead as it effectively affects your ABI/API. Zig tries to not force this so as long as you "pass by value", the compiler can actually decide to pass it by reference. It does expose this kind of footgun though https://github.com/ziglang/zig/issues/5973#issuecomment-1330...
Zig cookbook: collection of simple Zig programs that demonstrate good practices
6 projects | news.ycombinator.com | 1 Jan 2024
Hmm, there's a distinct change of opinion by andrewrk from the linked issue (2022) to now
https://github.com/ziglang/zig/issues/12064 (July 2022):
> Hope you don't mind I'm going to reopen this issue because it concisely demonstrates a design flaw with result location semantics and I'm not ready to accept status quo as permanent due to aliasing issues like this.
Compare to a very closely related issue regarding destructing, which exhibits the same problem
https://github.com/ziglang/zig/issues/17283 September 2023):
> This is working as designed. Everybody was aware this behavior would be a consequence of destructuring and there is no plan to change it.
Odin Programming Language
I don't know about a list online but here's what I know off, in the C/C++ realm
Odin - https://odin-lang.org/
I highly recommend looking at:
* The Overview: <https://odin-lang.org/docs/overview/>
* examples/demo: <https://github.com/odin-lang/Odin/blob/master/examples/demo/...>
As for the first example: a basic lexing example is probably boring, but it does show some basic ideas of what the language is about. If people want to write better examples or just reorder the current ones, please feel free to make an issue or PR on the website's GitHub page: <https://github.com/odin-lang/odin-lang.org>.
Botlib: Telegram Bots in C by Antirez
5 projects | news.ycombinator.com | 24 Nov 2023
Austral Programming Language
4 projects | news.ycombinator.com | 27 Jul 2023
Small Joys with Odin
4 projects | news.ycombinator.com | 21 Jul 2023
Why your F# evangelism isn't working
5 projects | news.ycombinator.com | 30 May 2023
There's also MojoLang that brands itself as a alternative to Python, and Google will look to release Carbon soon as well. It'll be interesting to see how these two grow.
There's also Odin that looks promising.
I don't think C# is going anywhere, F# on the other hand :shrug: is at the mercy of MS - they always seem to be on the fence about it.
 - http://odin-lang.org/
Good languages for writing compilers in?
8 projects | /r/ProgrammingLanguages | 11 May 2023
You can try using Odin language: https://github.com/odin-lang/Odin
New language suggestion to old time Gopher
5 projects | /r/golang | 1 Apr 2023
Odin shares some common ancestors with Go and has some similarities:
When Zig is safer and faster than (unsafe) Rust
3 projects | /r/programming | 8 Mar 2023
The language Odin does this, but it comes at a cost, the calling convention is different from C (a register is commandeered to point at a context object which contains the allocators).
What are some alternatives?
Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
rust - Empowering everyone to build reliable and efficient software.
go - The Go programming language
rust - Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266
ssr-proxy-js - A Server-Side Rendering Proxy focused on customization and flexibility!
TinyGo - Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
crystal - The Crystal Programming Language
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.