Monday 10 April 2023

Which one do I prefer ?

 Hi folks,


Following-up my previous post and having spent more time with Zig since, I have tried to assess which, among the languages I am dealing with, I tend to prefer. Before going further, I wanted to clarify the following statements represent only personal opinions, not a general consensus of any sort nor the "truth" that everyone agrees upon. Indeed, if you prefer language E over A, I encourage you to continue 🙂 and will have my respect as you are dedicating your time into it.

1/ Rust

After 3 years plus after diving into it, I still like the language and what it stands for. Now, I see more of its caveats and idealise it less than I used to ;  it is still an excellent programming language tough. I tend, now, to see it more as a possible C++ replacement than a C one in term of expressiveness possibilities.

Pros:

- Extended expressiveness, the inherent difficulty of Rust does not bother me as much as long it is justified. To me, in the case of Rust, it is. Just the trait concept alone does it in my opinion, same as with the macros.

- Mature ecosystem. It even had been accepted by the Linux kernel as a secondary language of choice for kernel modules (while having refused C++ decades ago, which tells a lot).

- Miri is very helpful to detect possible undefined behavior, but hopefully will be mature enough one day to be part of rust rather than being a separated tool.

- How you can switch memory allocators (jemallocator, mimalloc, etc), while benefits from their features (e.g. jemalloc profiling).

- An excellent alternative for web programming too.

Cons:

- It is far to be straightforward to interact with C++ code however and even with specialised crates (e.g. cxx), it is not ideal. I think if you mostly want to build bridges with legacy C++ code, there are other languages out there more appropriate (Google Carbon, ..., D (yes it is not dead 🙂)).

- But even if you want to deal with C, you have to use libc and/or bindgen capabilities. The latter works mostly fine in my experience. Overall, not a deal breaker in my view tough.

- No builtin defer mechanism but not a huge drawback again on this one, you can fairly do one of your own easily like you would do in C++ with using drop trait and a macro.

- No strong cons overall tough.

2/ Zig

After one month into it, I can't say if this language will "make it"  (ie to the industry at large) with 100% certainty. Does it have the potential tough ? Absolutely ! it has good community and good press already ; but we will know better once 1.0 is out. Indeed, a good chunk of great languages did not or are stuck in a particular niche (Haskell, Ada, ...). The lack of maturity does not discourage me enough to be interested by it tough.

Pros:

- Overall less obscure than Rust, in term of semantic and features usability.

- An excellent bridge builder towards C, better than Rust is for sure.

- The comptime feature by itself but also how accessible it is to use it.

- The various allocators ; arenas, heap, fixed buffers ... are an interesting concept by themselves.

- The clever build system (via build.zig), not only for Zig code but C/C++/ObjC/Assembly as well.

Cons:

- Again ; unless you re willing to do some C wrapping beforehand, there are better solutions out there to deal with C++ code.

- You need to disable ubsan, one of the signs of its inherent immaturity which needs dear fixing.


Others

1/ Nim

I think it s a decent programming language ; however it has a garbage collector. While it can be disabled, with a low level programming language I want the other way around, no garbage collection at all or at least disabled by default  (I am glad c++ 23 removed its support); I prefer to have full reins ; good for them tough you can choose the garbage collection algorithm. Not necessarily a huge fan of the python's like style but that is not necessarily a real deal breaker in my view ; I think their target are indeed around this : python/ruby/golang developers especially for embedded development.

2/ D

It is a bit unfortunate this language did not get much traction decades ago. But it starts to get some renewed interest recently I find, especially that the language mentioned above borrow some of its concepts 😉, can interact with C and especially C++ a lot easier than Rust/Zig. It also has a garbage collector but you do not have to use it and manage memory manually.

3/ Jai

Is still in development, the compile time function execution is one of its selling point. The fact that Jai is not yet accessible to the public is a bit of an issue in my view, but looks definitively promising. However I barely see it as a general programming language but has a better chance to have its own niche.

4/ Odin

I personally appreciate it better than Nim and is a more appropriate contender against Zig in my opinion ; is open source, can decently interact with C. I m willing to give it more time to assert and prove themselves in the mid/long term.

So ? ...


Well, for me Rust and Zig are toe to toe, depends of the actual task at hand. For interacting with C and rapid development Zig tends to win but otherwise the higher maturity of Rust has my preference in other situations. As for their performance, both are usually very close in my personal usage and can be potentially be faster than C in some contexts. But overall I appreciate the greatly improved memory safety they both bring.

Labels: , , , ,

View David Carlier's profile on LinkedIn