May I ask how your new systems programming language differs from Zig? - I see that your language (I'll call it "Better Than Rust" for now) may be released before Zig. - BTR will have a standard spec before Zig. - BTR will have more uses of the work "fuck" in source code than Zig. (I'm just joshing your here). - BTR is currently more mysterious than Zig. - BTR is smaller and simpler than Rust. Obviously. Will BTR be faster than C? Zig? Thanks, Joshua P.S. Your reply could very well be your next blog post. So I will patiently await your reply.
On Fri Mar 19, 2021 at 2:18 PM EDT, Joshua Branson wrote: > May I ask how your new systems programming language differs from Zig? It's much simpler, and does not provide any metaprogramming facilities (such as comptime). Unlike Zig, BTR does not use LLVM. Zig takes about 30 minutes to compile and run its test suite, not including the time required to build LLVM, whereas BTR takes about 5 seconds to build qbe, its compiler, and its stdlib, and run the compiler and stdlib test suites.  https://c9x.me/compile > - BTR will have a standard spec before Zig. Probably. > - BTR is smaller and simpler than Rust. Obviously. Smaller and simpler than Zig, too. > Will BTR be faster than C? Zig? It will be similarly fast to other languages in its class.
Hi, Just wanted to note that there's a difference between zig the language and Zig the LLVM-based compiler, and give my two cents. I'm currently working on a compiler that supports both Zig and BTR as input languages (though the BTR frontend has not yet been written, as I'm finishing up ARM64 codegen first), is written in pure C99 (and is primarily tested on plan9!), and with a focus on compiler simplicity and correctness. Zig the language is more complex than BTR, but is arguably simpler than C in many respects. Zig the compiler (both the LLVM-based stage1 and the self-hosted compiler) are absolutely more complex than BTR, and small C compilers like cproc or kencc, but that is an implementation concern; the language allows for simpler implementations. To answer the original question: As I see it, though this is fully subjective and either Andrew, Drew, or bothmight object to this, the fundamental difference between Zig and BTR is that Zig is intended to make writing complex software simpler while BTR is intended to make writing simple software simpler (with the understanding that simple software is intrinsically better). Drew doesn't intend to use BTR for metaprogramming,so why would it be needed? Similarly, since Zig is intended for the use case of writing complex software, Andrew tries to address those use cases in a simple manner - hence, comptime instead of a dozen other features in its place (generics, constexpr, and so on). I wouldn't say that either is "better" or "worse"; both fit into their own niche very well, and I'd much rather run a system with only Zig and BTR than one with only C and C++, for instance. You could argue reasonably that BTR is a simple low-level language while Zig is a simple high-level language.\ - Noam Preil  http://sr.ht/~pixelherodev/ProjectTricarbon
Hey Drew, First time commenter on your posts, so not really sure if you like individual comments in their own thread or a thread per post... Although I am not sure how much I can contribute to the things you talked about in your post, I would be interested in trying to bring Meson support to your language. I have contributed to Meson in the past and am active in their freenode channel (#mesonbuild). Would be a chance for me to get more into Meson internals specifically around implementing language and compiler support. Not exactly sure where you stand on Meson or if you already have a build system in mind. Knowing you, your language probably operates with Make nicely already. The Meson work could live in a private branch/fork somewhere until you are ready to release the language. Would hate to spoil the surprise prematurely. My systems programming experience: * Contributed to a Windows device driver to support time synchronization between devices at NI (National Instruments) * Currently working on a high-performance storage engine called the Heterogeneous-Memory Storage Engine (HSE, https://github.com/hse-project/hse) at Micron Thanks, Tristan P.S.: If you are aware of any software engineers who have experience in the systems engineering space and are looking for a new opportunity, my team is hiring for the project mentioned above. Won't post the links here, but feel free to pass along my email to other people who could have an interest. Could maybe be interesting to have a jobs mailing list on sourcehut. Maybe the jobs posted could be restricted to open source only, but wouldn't necessarily have to be.
Hey Tristan, we don't use Meson to build our programs, so we'll pass on this for now. Would be nice to see Meson add support after the public release.
Disappointing, but understandable. Excited for the 1.0 release and the traction the language can gain. I am sure adding Meson support post-1.0 will be pretty cookie-cutter. Thanks, Tristan