Fortran still plays a big role in scientific computing. I am working on climate models, which need to be run on several different supercomputers with different compiler stacks and architectures. Biggest upside of switching to C++ is to use libraries like Kokkos (which aggressively incorporates new C++ standards) to take advantage of the heterogeneous architectures in a portable fashion. And the code will be used / developed by a lot of people, so I guess C++ will win out over just C.
We’ve talked about using transpilers and some of our custom tools and we will probably use them for certain modules. But, one of the exciting parts of the re-write is to have an opportunity to reconsider the basic code structure.
Std lib not stable enough / good enough - I think those two should be separated. While they are related (meaning that if it’s stable, that’s a good thing), stable and good are too entirely different things. I voted, because it is not stable, not because it’s not good.
Interesting! I wonder if using cc -E to get the preprocessor output, saving it to disk, and trying to compile that would let Zig succeed without having to do any pre-processor anything.
Zig programming language is currently little-known in the software market in Türkiye (Turkey) , where I live. Despite its limited market penetration and job opportunities, I see it as a language that could dethrone Rust in the future. However, I still see some shortcomings:
Limited Library: A trend like “Rewrite with Rust” requires porting libraries like ML/DL, Data Science, and Scraping from languages like Python, GO, and Rust to Zig.
A More Stable Version: (No need to explanation)
More Real-World Examples: I believe that as the number of references, especially from large companies, increases, it will begin to appeal to a larger community. Languages like Rust, GO, and Python are backed by large companies, a large developer community, and plenty of advertising. It’s beneficial to make strides in this regard.
Integrated Web Framework: Zig should also include integrated web frameworks like those found in languages like Elixir.
A detailed official documentation system similar to MDBook: One of the most widely used systems for the wider dissemination of the Rust language was the MDBook documentation system. A similar zig documentation system would also be very useful. DIY-style systems always attract users.
Static Website Generator: A static website development environment similar to Hugo could increase the population.
Zig Conferences: The Zig language could be promoted through online and offline university conferences. Conferences that showcase examples of industry-specific usage can particularly attract the attention of the masses.
I don’t think this is necessary, or even useful. Why rewrite it, when you can just use an existing C/C++ library? The only reason why “Rewrite it in Rust” mentality is a necessity for other languages, is because it’s a pain to use a C libraries, since you need to make bindings first.
Whereas in Zig you’re just a single @cImport away (+ some setup in the build system, which if you are lucky has already been done for you: All Your Codebase · GitHub).
I was particularly impressed when I saw the Rust versions of ML/DL libraries like Tensorflow and Pytorch. I liked the idea of being able to run them in Rust. However, I don’t know if something like this exists for C++. I’ve written in Python, GO, and Rust. But I’ll try to check out the resources you mentioned.
I’ve been using the Hare programming language for a few years now – the biggest sore spot with Zig compared with Hare is the error prorogation experience. Both languages have decent error handling functionality, but creating my own error states in Zig just doesn’t map to how I like to think about error states.
One global error set requires awkward C-like namespacing (i.e. the Test errors in the stdlib), whereas in Hare an error type can be declared as a tagged union type at the module level, like any other type.
The lack of payloads requires awkward C-like out-parameters to convey error context, whereas in Hare any type can be tagged as an error, allowing any information to be associated with an error state.
Can you give me an example where that’s beneficial, as opposed to bubbling up errors and handling them in a central place?
Other parts of the language don’t seem to mesh with this though – like being able to return !void from main, which encourages not handling errors at all.
Because then you don’t need to bubble up errors and handle them all in a central place.
There seems to be an assumption here that the program is going to be crashed upon any error. If this is the case, why bubble it up the call stack at all, just crash the program where it happened. Otherwise, it stands to reason that the calling function which just got an error returned to it is going to have more context on how to proceed/recover than my main function will X layers higher in the stack.
Zig has error return traces, so I don’t think it makes a difference regarding being able to see from where the error originated. I think it depends on the code where it makes sense to handle the error or crash.
I use zig all the time for hobby projects/experiments. One thing that prevents me to use in work environment is quite simple. I’m behind proxy, unfortunately proxy support to fetch packages doesn’t work. I know there are workaround for this but it is still not ideal.
I meant if the program is just crashing, then there isn’t a big difference between bubbling the error up to main or calling panic where the error happens. If however you decide to actually handle the error, then you can get more precise information at the point where it happens. I mostly wanted to point out that letting it bubble up is fine in some situations. For example if it will be another programmer handling the error / fixing the program.