zig
rust
Our great sponsors
zig | rust | |
---|---|---|
812 | 7 | |
30,295 | 707 | |
3.7% | 1.1% | |
10.0 | 0.0 | |
about 3 hours ago | about 1 month ago | |
Zig | Rust | |
MIT License | GNU General Public License v3.0 or later |
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.
zig
-
Bun - The One Tool for All Your JavaScript/Typescript Project's Needs?
NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.
-
Bun 1.1
I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Some tech companies have internal implementations of this sort of system. Then I see the shim DLL:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.
Then I look into the source for it:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:
https://github.com/ziglang/zig/issues/1840
I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :
#include
ntdll.dll!RtlUserThreadStart()
There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.
-
Zig, Rust, and Other Languages
https://github.com/ziglang/zig/blob/5cd7fef17faa2a40c8da23f0...
Generally speaking, it’s as mentioned just a convention. A zig library might not allow its users to pass allocators for example.
In C++, stl containers can take an allocator as a template parameter. Recent C++ versions also provide several polymorphic allocators in the stdlib. You can also override the global allocator or a specific class’ allocator (override placement new).
-
Nanos – A Unikernel
We need to remove that. We did have a channel on freenode a while back but got rid of it.
Outside of gh discussions there is also https://forums.nanovms.com/. We made a decision a while ago to follow Zig's lead here and have no 'official' community space (https://github.com/ziglang/zig?tab=readme-ov-file#community) instead letting people form their own spaces.
Zig also has an IRC channel on libera (#zig) that is moderated by Andrew Kelley.[1]
- Ask HN: What Underrated Open Source Project Deserves More Recognition?
-
Top Paying Programming Technologies 2024
1. ZIG - $103,611
-
MicroZig: Unified abstraction layer and HAL for Zig on several microcontrollers
ESP32 and STM32 support is very welcome!
I have been following https://github.com/ziglang/zig/issues/5467 for a while and progress seemed to have slowed significantly
rust
-
ESP32 example project
The esp-template issue might be this one: https://github.com/esp-rs/rust/issues/158. Try with --release or updating to 1.68.0 with espup update. I'll take a look at the log as soon as I can, atm Im on the phone and is not that easy to scroll through :(
-
Are there situations where it's better to use C++?
Xtensa. They've got a fork of LLVM that supports it that they're working toward getting upstreamed. The community has a fork of rustc that uses it (and a quickstart crate) while we wait for it to get upstreamed.
-
Multi-use kernel written in Rust
It only works if you have an Xtensa compiler which takes hours to compile, here: Rust Xtensa (if you don't have it). The network driver is just a function that sets the name of the driver so the Esp32 does something other that blinking.
- Could IOTA transaction be started solely from the IoT capable device (like esp32)?
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).
Odin - Odin Programming Language
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
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.
Elixir - Elixir is a dynamic, functional language for building scalable and maintainable applications
llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
Beef - Beef Programming Language