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[0], its compiler, and its stdlib, and run the
compiler and stdlib test suites.
[0] 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[1] 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
[1] 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.
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