141–150 of 286 posts
I hear about zig all the time, and I'm surprised I don't more about vlang. Yet they still to target a similar audience. Is this a matter of popularity or features ?
> added a Rust dependency which in turn changed the list of supported platforms My understanding is that `zig cc`/`zig c++` are thin wrappers around LLVM, so doesn't that just reintroduce the same problem?
The point about the Python package example is not to say that Zig can get on platforms where Rust can't, but rather that the C infrastructure that we all use is not that easy to replace and every time you touch something, regardless of how decrepit and broken it might have been, you will irritate and break someone else's use case, which can be a necessary evil sometimes but not always.
This is a point I made in the section of the blog post dedicated to explaining the limits or rewriting code.
I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…
Earlier quoted context omitted.
Zig itself doesn't cross compile C/C++ code, LLVM does the work for Zig. > If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target. Rust is built on LLVM, and so its toolchain can also cross-compile C/C++ code. There are crates for that[0], and projects inspired by that idea[1]. > Give it some time, it will. Given enough time mountains beco…
You're splitting hairs in a weird way. rustc cannot compile C code. zig can. That they delegate to LLVM is immaterial. "This crate calls out to the most relevant compiler for a platform, for example using cl on MSVC."
But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages.
Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs
rustup and cargo also provide easy cross-compilation support, too.
I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous im…
I would say that Zig has the same advantages for a lot of these points. Its interoperability with C at the source and object level is first-class, the syntax was very easy for me to pick up as someone familiar with C/C++, the features it adds on top of C (e.g. slices, compile time execution) are few but huge QoL improvements, its translate-c utility works amazingly well at transpiling C code to Zig, and its test bloc…
I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30.
So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs.
> Its interoperability with C at the source and object level is first-class
- https://dlang.org/spec/interfaceToC.html
- https://dlang.org/spec/cpp_interface.html
It can even directly interop with C++ classes:
- https://dlang.org/spec/cpp_interface.html#using_cpp_classes_...
> the syntax was very easy for me to pick up as someone familiar with C/C++
"10. Where D code looks the same as C code, have it either behave the same or issue an error."
"The general look and feel of C/C++ is adopted. It uses the same algebraic syntax, most of the same expression and statement forms, and the general layout."
I found Zig to be much less syntactically similar to C/C++ than D. Zig felt more like a mix of Rust/Go.
> the features it adds on top of C (e.g. slices, compile time execution)
- https://dlang.org/articles/d-array-article.html#introducing-...
- https://tour.dlang.org/tour/en/gems/compile-time-function-ev...
> its translate-c utility works amazingly well at transpiling C code to Zig
You use these if you're linking with an external out-of-tree library, or a C++ library.
- C, Limited C++ = https://dlang.org/blog/2019/04/08/project-highlight-dpp
- C, Extensive C++ = https://github.com/Superbelko/ohmygentool
- C, Objective-C = https://github.com/jacob-carlborg/dstep
> its test blocks make unit testing trivial to integrate.
- https://tour.dlang.org/tour/en/gems/unittesting
=============
Not trying to start a pissing match, because I actually think that Zig has a lot to offer as well -- but for these particular list of things, there's no clear winner here.
Earlier quoted context omitted.
disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…
"simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple. Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a co…
I think we'd all agree there's a spectrum, with, say, Assembly on one end and Idris on the other, where neither Zig nor Rust are near either extreme, and are actually rather close to each other. It's not a matter of accepting or rejecting a principle, but on picking slightly different sweet spots (hopefully) on a tradeoff spectrum.
Rust doesn't check at compile-time most things that could be checked at compile-time. In fact both language check almost the same things at compile-time, and almost the same things at runtime. The design differences come down to one or two things that are clearly tricky and that neither language "does for you" -- i.e. you still need to think about them -- but are, indeed, checked in different ways.
Zig is clearly leaning in hard to the E3 strategy! (embrace, extend, extinguish) for those not familiar
Second, "extend" has traditionally meant "extend with proprietary code". Think early 2000s Microsoft with browser APIs and J++, or Amazon with their in-house forks of MongoDB, PostgresQL, etc.
There's plenty of innocuous activity that could be called E3 if you stretch the definition that far. Most of the GNU ecosystem for example.
Earlier quoted context omitted.
You're splitting hairs in a weird way. rustc cannot compile C code. zig can. That they delegate to LLVM is immaterial. "This crate calls out to the most relevant compiler for a platform, for example using cl on MSVC."
> You're splitting hairs in a weird way. rustc cannot compile C code. zig can. But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages. Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs rustup and cargo also…
I quoted from cc’s readme above.
Earlier quoted context omitted.
"simple" is, unfortunately, not a simple concept, nor does everyone agree on its effects on programs written in a language that is or is not simple. Some people do believe that, let's say "conceptually parsimonious" languages (using complicated words to describe simplicity is amusing to me, sorry) do exactly what you say. Others believe that complexity inherently exists, and you can put it in the language, where a co…
> Others believe that complexity inherently exists, and you can put it in the language, where a compiler can tirelessly check certain properties for you or a runtime can do magical complicated work on your behalf, or you can put it in the programs, where users have to check such things themselves. I think we'd all agree there's a spectrum, with, say, Assembly on one end and Idris on the other, where neither Zig nor R…