> So, if you want to build games using raylib, why not learn learning or use Swift for that?

Because Apple won't fix Swift's abysmal compile times, and there are languages with similar or better ergonomics without that flaw.

What are the languages with similar or better ergonomics?

Everyone will have their different take on what Swift is, and what a proper alternative looks like. Swift started life as a C-family successor, so I'll be looking at languages with similar aims (fine-grain control, scaling to large projects.)

The first two I'd mention are D and Nim. I only wrote ~10k LoC with these languages (so they weren't really for me) but they strike me as similar to Swift. They both optionally support an automatic memory management strategy like GC, (whereas Swift as ARC) and there is great effort put into metaprogramming facilities. Both D and Nim compile much faster than Swift, and offer better error messages than the Swift compiler in the presence of complex generic expressions. In the context of the parent post (games) Nim is especially well equipped with a package ecosystem. D seems a touch less lively, but has a following.

For myself, I prefer the Odin programming language. Full disclosure, I've been donating to Odin for about a year now after happily using it for more than 5. After writing "Orthodox C++" for a while, I stumbled on Odin and feel as if it was made specifically for me. The compiler is fast, and the language has been something like a tutor or mentor for me, as it applies friction in places where I usually waste time. It would take some hand-holding as a first-language though, as some error messages relating to overloading/generics would seem obtuse to a beginner.

EDIT: I've recently been exposed to the Raku language, and it strikes me as sort of a ... dynamic version of Swift? It's jammed full of functionality, with an emphasis on being able to design syntax a-la DSL.

Also I'd add that Swift is sort of part of this new litter of "no-paradigm languages" like Kotlin and C#. I don't think Kotlin can actually dip as low-level as C# and Swift can, though. At least I think only C# and Swift have some kind of safety-wrapped user-level pointer "thing."

Why wouldn't it?

... and so another benchmark is born.

Thank you!

“Changing the equation” by boldly breaking the law.

> “Changing the equation” by boldly breaking the law.

Is it? I think the law is truly undeveloped when it comes to language models and their output.

As a purely human example, suppose I once long ago read through the source code of GCC. Does this mean that every compiler I write henceforth must be GPL-licensed, even if the code looks nothing like GCC code?

There's obviously some sliding scale. If I happen to commit lines that exactly replicate GCC then the presumption will be that I copied the work, even if the copying was unconscious. On the other hand, if I've learned from GCC and code with that knowledge, then there's no copyright-attaching copy going on.

We could analogize this to LLMs: instructions to copy a work would certainly be a copy, but an ostensibly independent replication would be a copy only if the work product had significant similarities to the original beyond the minimum necessary for function.

However, this is intuitively uncomfortable. Mechanical translation of a training corpus to model weights doesn't really feel like "learning," and an LLM can't even pinky-promise to not copy. It might still be the most reasonable legal outcome nonetheless.

Laws don't have to treat humans and machines equally. They can be "unfairly" biased for humans.

People have needs like "freedom of artistic expression" that we don't need to grant to machines.

Machines can operate at speeds and scales way beyond human abilities, so they can potentially create much more damage.

We can ban air pollution from machines without making it illegal to fart.

Non-sequitur. It can be both.

Its only breaking the law if you don't have enough money to pay the politicians.

Whoa a CEO writing about why their product is especially important in this very moment!

Interesting. The Odin Programming Language has some primitives that are pretty similar to Absail's macros.

For control-flow we've got the postfix operators: `or_return`, `or_break`, `or_continue` For alternative values we've got postfix `or_else`.

Considering how much I enjoy Odin I should probably entertain using Absail for my next C++ project.

Lots of confused comments here about immediate vs retained GUIs. Immediate-mode is an API-design, not an implementation detail. All Immediate-mode GUIs retain data, and for that reason they each have their own APIs for retaining data in various capacities. Usually something really simple like hashing for component-local state.

> What about when you're embedding your GUI into an existing application? or for use on an already taxed system?

You should check out the gamedev scene. It's soft real-time, and yet dearIMGUI is the choice for tooling. Immediate-mode is an API-design, not the implementation details. All Immediate-mode GUIs retain data some data, and for that reason they each have their own APIs for retaining data in various capacities. Usually something really simple like hashing and component-local state.

> This works for simple apps, utilities, and demos/mvps. Not great for actual applications.

Respectfully, I don't think you're informed on this. Probably the most responsive debugger out there is RAD Debugger and it's built with an IMGUI.

This doesn’t solve a problem.