That's cool. I imagine I could also maintain a MinGW package that can be downloaded through the Zig package manager and statically linked without involving the zig libc? (Such that the user doesn't need to install anything but zig)
That's a good way to sell moving over to the zig build system, and eventually zig the language itself in some real-world scenarios imo.
This is very exciting for zig projects linking C libraries. Though I'm curious about the following case:
Let's say I'm building a C program targeting Windows with MinGW & only using Zig as a cross compiler. Is there a way to still statically link MinGW's libc implementation or does this mean that's going away and I can only statically link ziglibc even if it looks like MinGW from the outside?
I will be even more impressed with linux syscall stability if your implication is that (some) people need to recompile their software for each major update on all other UNIXes.
I'm only thinking in terms of Linux distributions since I never needed to deploy software on other UNIXes (excluding macOS, but Apple constantly forces changes anyway).
Do other UNIXes have any problems similar to glibc ABI problems that Linux users experience, or do they stabilise the libc ABI similar to how Linux keeps syscalls stable?
That doesn't give you independence from the libc, does it? By extension you lose distro-independence too (not sure if Detour supports musl-based ones, need to run tests).
Agree that IPC will be more secure and stable though.
I imagine Detour is mostly targeting closed source projects trying to run on as many distros as possible.
That's only true if you're making CRUD software and easily replaceable by any random programmer. For anything more serious LLMs are only useful as a better search engine.
Keep in mind there _may_ be a negative feedback loop there.
If you're building your software in a way that won't be able to perform better with superior disk/db/network performance, then it isn't worthwhile to ever upgrade to a more performant disk/db/network.
If it is possible, make sure your software will actually be faster on a faster disk rather than just testing on a slow disk and thinking "well we're I/O bound anyway, so no need to improve perf".
> As for the "...latest version of the SDKs..", that is moving the goal posts, there is no mention of it on [...]
I thought it was implied since tooling & library breakages over the years happen and sometimes you can't just get the old SDK to run on the latest Windows / macOS. If the languages and Ant/Maven are backwards compatible to that extent, that's actually pretty good!
I had to deal with moving a .NET Framework 4.7 project to .NET Standard 2.0 and it wasn't effortless (although upgrading to each new .NET release after that has been pretty simple so far). We took a couple of weeks even though we had minimal dependencies since we're careful about that stuff.
Okay, C++ is believable, but can you really build a Java / .NET project that was not touched for 20+ years with no changes to the code or the build process (while also using the latest version of the SDKs)?
I imagine you can _make_ a project compile with some amount of effort (thinking maybe a week at most) but they wouldn't be exactly "unzip the old archive and execute ./build.bat".
I landed on "immutable distros by default for average users" as well. It is a more Windows/macOS like experience where it is much harder to mess up the system.
Flatpak guarantees everything will work in most cases, and for other cases there's AppImage. Just need to get most devs to distribute AppImages. BoxBuddy with distrobox will solve _all_ edge cases where someone says "X works with Y in Z on my machine" so you replicate their machine in distrobox.
I know this is trading program size with convenience, but that's what Windows and macOS does too. It is better to be on some immutable linux distro rather than Windows in my opinion. We don't have to force the average person who just wants their computer to work to install (extreme example) Gentoo or whatever.
> If you're interested in writing C# and .Net code on a Linux machine. Then wait no further. VS Code (with .Net dev kit extension) works great.
Unless you're writing Roslyn source generators. You can only debug them with (non-code) Visual Studio on Windows in my experience. Rider does not work well either.
If you don't know it already, you learn C, as well as you can. It is not a hard language to learn, but it has a lot of footguns. That's why you learn it along with tools like Valgrind & sanitizers.
Then you look at Rust. That's somewhat harder to learn, but nails some important details you need to think about while writing C. It will make some things obvious that you'd need to learn by shooting yourself in the foot repeatedly in C. You don't need to use Rust once you got what you need out of it education-wise, but a lot of people like and use it.
At this point it is kind of unimportant what other "systems" language you decide to learn, but here's my opinion of some of them:
- Personally I like Odin's ergonomics. It is incredibly convenient. You can just jump in and start writing OpenGL code without dealing with wrappers and all that. Included vendor libraries take care of a lot.
- I also like the explicitness of Zig. It seems like it'll be the most popular one in the future, most likely not because of the language itself but because of the tooling. By the way the reason I say "not because of the language" is that the maintainers seem uninterested in having some way to constrain generics. The language sorely needs some sort of comptime interface / traits / concepts, anytype-everything is not nice. In 10 years someone will come up with a Boost-like library that implements just that in userspace and it'll be horrible.
- Ocaml is garbage collected Rust, or rather, Rust is non-garbage-collected Ocaml. It is underrated. Jane Street people are adding borrow checker to it. Could be more popular in the future. Also, all languages are "systems" languages depending on how you wield them. No need to bikeshed about Ocaml's "system"ness status.
- D is pretty cool. Very fragmented library ecosystem if you want to do betterC or no-gc though. Be prepared to just use C or C++ libraries, which it can talk to pretty easily.
- Nim is a nice language. Does reference counting so it has a low memory footprint compared to other GC'd languages. It compiles to C so technically it is the most portable language in this list. You can easily run it on microprocessors that others won't run on. Try it, you'll very quickly land on "like it" / "don't like it" territory depending on your programming style.
- Jai is non-existent right now. Doesn't warrant a discussion until Jon Blow feels it is ready for prime time. But since that's his strategy, expect something practical and polished. If it sucks, two possibilities: 1) he didn't deliver and it won't get drastically better or 2) your use case was not in consideration.
- C3, it exists, it is usable, it is like a halfway between C and D. I didn't spend much time on it yet.
- Free Pascal: I didn't use it but just putting it here because this list is getting long & it kind of deserves a shout. Lazarus looks nice.
- Go: Use Java or C# instead, they can compile to native now.
- C++: It exists, it is used everywhere, it sucks. As opposed to most other languages on this list, it wasn't designed. It kind of picked up random features along the way because they looked good. You kind of design it by picking up a subset and putting up with its weirdnesses. Don't use it if you can help it. If you have to use it you most likely didn't have a choice in the first place.