TUSF

You need to link against the oldest glibc version that has all the symbols you need

Or at least the oldest one made before glibc's latest backwards incompatible ABI break.

You shouldn't, cause it's wrong.

libwayland is 40k lines of code. wlroots is 60k loc.

And just to check, sway is about 49k loc.

I wouldn't call it "tragedy of the commons" because the very idea was coined as a strawman. As far as I'm concerned, the entire concept is a fallacy, and people should stop perpetuating it.

cake[0] might interest you. Basically transpiles C into C89.

[0] https://github.com/thradams/cake

As I understand it, WASM GC provides a number of low level primitives that are managed by the WASM host runtime, which would theoretically allow languages like Go or Python to slim down how much of their own language runtime needs to be packaged into the WASM module.

But how those languages still need to carry around some runtime of their own, and I don't think it's obvious how much a given language will benefit.

I'm not who you were asking, but my only experiences with vlang was years ago when its marketing was making false claims about what its capabilities were, while pretending to be an already production-ready language. This in turn harbored tons of distrust about any of its promises of future capabilities too.

At this point, I don't think it matters if the V programming language has actually fixed all of those issues and its marketing is completely truthful now. The language's perception is tainted, and it'll take a herculean effort to fix that.

There's no special tooling to catch this, because nobody catches an error with if-else—it's simply not idiomatic. Everyone uses switch statements in the catch block, and I've never seen anybody using anything other than switch, when catching an error.

anti-Rust sentiment

I have not seen much of any anti-Rust sentiment in the community. There's a lot of people in the community who do Rust, like rust, and work on rust projects. If the Zig community has an anti-anything sentiment, it's against C++.

Qt has no official C bindings. This makes it difficult for a new language to write Qt bindings, unlike for GTK.

The negative aspects of Electron have little to nothing to do with CSS, and you're only invoking it here to poison the well by association.

Linux is stupid and sucks.

None of this is Linux's fault. I'd argue this is both C's and GNU's fault. The need for a copy of the library, seems to be just a tooling convention. GCC's linker requires it, so others do the same thing. The executable itself doesn't need to know where a given symbol is in a shared library's memory at runtime (or even what shared library a symbol comes from, just that it's inside one of the libraries declared as needed in its dynamic section), because that's the (runtime) linker's job to figure out. Regardless, you don't actually need a full copy of the library—a stub will suffice.

I don't know a ton about compilers, but as far as I know, there's no reason clang's linker (LLD) couldn't just not require an existing copy of the shared library you're linking to. Can't do anything about requiring a version of the libc headers you need for every platform though.

Zig has a couple of IR layers. Generally, Zig's compiler goes: AST → ZIR → AIR, and from there it'll either emit LLVM bitcode or one of its own, platform-specific "Machine IR"

Zig already has an Allocator interface that gets passed around, and the convention is that libraries don't select an Allocator. Only provide APIs that accept allocators. If there's a certain process that works best with an Arena, then the API may wrap a provided function in an Arena, but not decide on their own underlying allocator for the user.

For Zig users, adopting this same mindset for Io is not really anything new. It's just another parameter that occasionally needs to be passed into an API.

Breaking changes is just another Tuesday for Zig.

I don't think SO's "canonical answer" concept really jives with a pre-1.0 language like Zig that is still in constant flux, regularly making breaking changes. One of the questions the blog brings up as an example, "What allocator to use in WASM?" would have a different answer last year than it would this year, and may well have a different answer next year.

One idea is to include a bunch of nonsense text into webpages, and use CSS to hide it from browsers. Depending on how aggressively you want to do it, this may affect some accessibility tooling.

Zig on Linux already directly interfaces with syscalls,[0] unless your library or application directly links libc.

[0] https://ziglang.org/documentation/master/std/#std.os.linux

In Zig, the main function can return either a u8 or void (which always returns 0) or it can return an error union !void, where if you allow an error to bubble up to main, it'll print an error trace and return 1.

What prevents anyone from dedicating a Zig memory allocator to the job (and all of its subtasks), and simply freeing the entire allocator at the end of the job? No baby-sitting needed.

Given the whole ecosystem is built around the Allocator interface, it's entirely feasible for the consumer of a library to pass in a Garbage Collecting allocator, and let it do the job of deciding what gets dropped or not.

Downside is that this is all at runtime, and you don't get the compile-time memory management that Rust has.

Yes. In fact, Aro is already in the main Zig compiler's repo, although currently I don't think it actually does any compilation of C (unless you explicitly disable LLVM) and is mostly used for Zig's "translate-c" functionality, last I checked.

Is it still so after ditching LLVM?

Zig hasn't ditched LLVM, nor does it really plan to. What's planned is for the main Zig executable to not directly depend on LLVM, that way contributors to the compiler can still develop on the code base without needing to set up and compile LLVM on their systems. Zig does plan to eventually supersede LLVM's functions with their own custom backends, but in the short term, this only means using the new backend as a debug compiler (for faster compilations, to allow for a better developer feedback loop) and it won't be until the distant future that LLVM could feasibly be dropped as a dependency entirely, if the devs ever decide to actually go through with that.

Yeah, LLVM is here to stay for Zig. The plan is to have a custom backend for fast Debug builds for use during development, while emitting LLVM bitcode for release builds that can then be fed to LLVM.

Not linking to LLVM would also make the barrier to entry on contributing to Zig itself lower, because now you can just compile Zig with Zig, and not worry about other dependencies.

Does an ecosystem designed with custom allocators (including gc) in mind not count for anything?

It's called lobbying, and the courts consider it "free speech". Speech that says "I just spent a million dollars to inconvenience my competitors."

By convention, all Zig libraries have functions that take an allocator as input from the user. Your application can use libgc[1] and pass the allocator to any library function you use, and not worry about deallocating afterwards.

[0] https://github.com/linusg/zig-libgc

You can always use a garbage collecting allocator with Zig, if you're that paranoid anout it.

And most of those were rejected without all that much pushback, as opposed to this one where there's about 100 comments already.

This is only still at the proposal stage. The Github issue is mostly for posting usecases for and against, etc… It's not "Accepted".

Zig's C/C++ compiler is just clang, but with header files for most major platforms included, and sane defaults, so there's no hassle getting it it to cross-compile. Some companies have been using Zig solely for an easier to use clang.

With Zig, you just write something like:

  const c = @cImport({
      @cDefine("SOME_MACRO", "1");
      @cInclude("raylib.h");
  });