generichuman

You can use GLM in OpenCode with a z.ai subscription by default as well. Also it'd be good if you mentioned you were involved with nemesis8.

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?

Check Detour out: https://github.com/graphitemaster/detour?tab=readme-ov-file#...

I suspect with combination of Detour & Zapps it could be possible.

Can you build GUI programs with this? I'm thinking anything that would depend on GPU drivers. Anything built with SDL, OpenGL, Vulkan, whatever.

If your use case is generating html, MathML is supported in all modern browsers: https://developer.mozilla.org/en-US/docs/Web/MathML#browser_...

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".

All fair, but:

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.

https://archive.md/cvzgy

(was down for me, this fixed it)

[...] where we make more $$$ than 95% of the population [...]

That doesn't make a difference. Suppressed wages are suppressed wages.

But, since you care about the comparison, people doing the suppressing are making even more.

My favorite SFXR alternative is this one which has a very nice UI: https://sfbgames.itch.io/chiptone

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.

Depends on what GUI library you're using, same as every other programming environment. There's GTK Sharp for C#.

its very hard to pick one to learn

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.

The submission title should be "The DOM Explained, Quick and Simple" instead of "How to Write a Parser". Looks like a copy-paste mistake?

Projects Panama & Valhalla seems to solve all your complaints:

Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so.

Part of Panama: check out the "Foreign Function & Memory API" [0]. The official docs [1] say it is a preview in 21 but it got stabilized in Java 22 (isn't out yet).

Another thing missing in Java is intrinsics support, both scalar like popcnt, bitscan, BMI, etc., and SIMD like SSE and AVX.

Also part of Panama: see the "Vector API" JEP [2].

Native stack and value types in C# reduce load on GC, and the number of complicated tricks required from JIT compiler. This in turn helps with startup performance. This is critical for command-line apps, and very desirable for desktop apps.

This is part of Project Valhalla [3], they're adding value types and actual generics, among other things.

That said, most of these are not done / not in a stable LTS Java release yet. We'll see how much better it'll be compared to C# (if at all) once they land.

[0] https://openjdk.org/jeps/454

[1] https://docs.oracle.com/en/java/javase/21/core/foreign-funct...

[2] https://openjdk.org/jeps/460

[3] https://openjdk.org/projects/valhalla/

Technical details here: https://github.com/dotnet/runtimelab/blob/feature/green-thre...

This is only true if you're talking about non-GUI apps

It is also true for GUIs if you're using Avalonia [0]. I use it to develop GUI apps on Linux, it works very well (Nothing I can show publicly, sadly).

Obviously it doesn't use native controls, but it is a solid GUI framework.

[0] https://www.avaloniaui.net/

if that's my go to solution, why am I using Godot instead of Unreal?

No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).

Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

even a more mature C++ renderer framework like bgfx, or even Ogre3D?

IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

Response to the article from godot dev: https://reddit.com/r/godot/comments/16lti15/godot_is_not_the...

TL;DR is that they know this & working on it

facegoomicrappama. See this: https://www.youtube.com/watch?v=2tQzCqkIQ60

It could force changes to Bun _internals_, which doesn't really affect users if the Bun team does not want to break API.

Link to the audio programming language / server they're using in the article: https://github.com/supercollider/supercollider

Author's talk at dconf (from today, actually) may be of interest: https://www.youtube.com/live/wXTlafzlJVY?feature=shared&t=24...

(Timestamp is 6:45:08)