C3 is a language designed as an evolution of C, without retaining strict backwards compatibility, but excellent interop with C.
This version brings - among other things: struct splatting (some_call(...a_struct, 1, 2)) and vector swizzle initialization (int[<3>] x = { .xy = 3, .z = 5 }). Together with other improvements and fixes.
Ultima 4 was good story wise, but the combat was extremely tedious with each in your party only being able to take a single step per turn. This was particularly annoying when facing easy to beat foes. The SSI AD&D games which only came out a little after U4 had a superior system, where each character in the party could move multiple steps (depending on stats) and so could the mosters. That system, while also repetitive, was much faster for combat, not to mention much more strategic and fun.
Later Ultimas, like U7 instead went for a streamlined realtime battle which was much better. That went overboard with the at the time infamous U8
Over 25 years ago I was doing ny final thesis on string theory for my Masters degree. The more I read, the more I went ”this could not possibly be right”. I ended up taking a break to work to get perspective on things and decide whether I wanted to continue pursuing a career in theoretical physics. I never went back. And given that in this field, things have been stagnant for those 25 years, it seems my impressions were quite on the mark.
Having so many things required to make it work, that we could not verify always rubbed me the wrong way, as was the ability to always be able to add just one more patch to make it outlive each experimental or theoretical setback.
Jai isn't open source so it is completely and totally irrelevant.
Zig builds C faster than most C compilers. You're going to have to do better than just mention it.
However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.
”Zig builds C faster than most C compilers” is a nonsense statement, which I don’t know how to answer.
The fact is simply that despite Zig uses LLVM as a backend in the same way Odin and C3 does, it compiles much slower. Exactly why that is, is something I can only guess at, but the fact is that Zig cached is still much slower to compile than Odin or C3.
(There are a few possible candidates as to why this is so that I identified and can share if it is interesting)
In any case, Zig is only ”fast to compile” if you compare to the triad of infamously slow languages: Swift, C++ and Rust.
This is just a convenient excuse. If Zig is to be fast to compile, it doesn’t help to make excuses for it.
Saying something it ”fast enough” because one is comparing with even slower languages is likely what made both Rust and Swift so slow to compile - they all just compared with C++, and it wasn’t until much later - when larger projects appeared - that the problem was taken more seriously. But at that time core architectural and language design concerns were already locked in.
This is why it’s not good for Zig to rest on its laurels and compare with worst of the class. And actually, faster Zig compile times benefits Jai, Odin and C3 as well, because then THOSE compilers can’t afford to slow down either. It’s a win-win.
If we compare with the worst though, then that’s a lose-lose proposition.
I have never heard anyone calling Zig "famously simple" before. In fact, people tend to say it has quite the learning curve.
Of course, caveats apply: it is certainly simple compared to some languages, but certainly not compared to others. "Famously simple" seems to indicate it is one of the simplest languages to learn, which seems wrong unless there are some serious qualifications to that statement?
C, C++, Rust, Zig. Rust and C++ have an infamous learning curve. If you know anything about using any systems language other than Zig, Zig is incredibly simple to pick up, like C. Unlike C, it pushes you toward making less mistakes.
If you don't know anything about using a systems language, Zig makes it easier for the people who do to review your code and make sure you didn't mess it up. It does this with very intentional design that makes it easier to understand the full impact of code quickly, reducing the cost of review, making review practical to catch the issues. It also has many other fail safes to catch these problems before they ever reach a production release.
So, yeah, it's totally depending on where you are coming from -- but Zig is not a tool built for a web developer who doesn't know anything about memory to go and ship an application within their first week. It does make it easier for that person to learn the ropes at a steady pace.
Meanwhile, everyone complaining that Zig is not memory safe doesn't seem to care that applications written in Zig do not have the vulnerabilities that memory safety solves on the scale that C does[0].
If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.
If you have, you probably understand there is a niche that Zig fits in and that it isn't surprising it exists to fill it. Like all things in our industry, there is a cost/benefit analysis required for choosing the tools you build with.
No one reasonable has claimed that memory safe languages should not exist, but there is a maddening number of people being disrespectful toward those who think there are other ways of addressing the same problems.
If you are comparing Zig to Rust and C++, which are very well known to be difficult to learn, then that is not really saying anything about the ease of learning it. Compare it to Swift, D or Odin. Is it "incredibly simple" compared to those languages as well?
Similarly, one can claim that pretty much anything compiles "incredibly fast" if one compares with Rust, C++ and Swift.
But comparing to worst in class doesn't actually say anything.
One note about this:
> If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.
I don't know what this has to do with my comments at all, but I want to point out that you are using "cargo culting" wrong. This describes imitating practices of something successful, thinking that by this imitation, success will follow as well.
> No one reasonable has claimed that memory safe languages should not exist,
Again, I have not talked anything about whether memory safe languages should or should not exist. You are confusing me with someone else.
Marketing speak, that looks to be trying to put Zig over languages like Golang, Vlang, etc... which are well known for their simplicity and readability. The false hype arguably creates confusion, that Zig can be "all things to all people", when it's not.
I feel qualified to offer a guess as to why: in Zig (and Odin) reuse is mainly done through what basically is templates. This reduces the need for vtables only when true ”plugin” type of objects are the only solution. For Zig and Odin, the only stdlib usages are for allocators and streams. These few usecases are way too few to motivate a full fledged interface feature, and consequently it’s not added.
So it’s both a lack of usecases, as well as a desire to prefer templates over interfaces for reuse, typically due to performance concerns.
While LLVM certainly is a problem, consuming over 90% of compile times both for C3 and Odin, it should be noted that both languages compile MUCH faster than Zig, achieving in general sub second compile times while using LLVM and without incremental compilation. So the question could be asked: ”what is making Zig so slow to compile” as both languages have similar feature sets compared to that of Zig.
1. Zig uses three(!) frontend IRs, Odin and C3 only one.
2. Zig relies heavily on comptime to provide most of its language features. C3, which has a similar set of features, doesn’t encourage excessive use of compile time and offers more features built into the language (for example format checking is a builtin, whereas in Zig it’s userland, even if C3 has the capability to do it like Zig). Although note that Zig only checks code directly traced, whereas C3 will check all code, and so will - esp for simple code - check much more code than Zig does.
3. Zig generates A LOT of code for even just a ”safe” Hello World.
On top of that, maybe there are just some other inefficiencies that hasn’t been addressed yet by the Zig team?
Even though I have stakes in the game I hope Zig gets faster. We need to move away from the illusion that Swift, C++ and Rust compilation speeds are anywhere near acceptable.
This release adds shebang support, and simple generic parameter inference (which doesn't have that much use in C3 compared to languages that have per function/type generics, rather than generic modules). There are some conveniences, like in-place compile time concat with `+++=`. And of course that slices and arrays of types with an implemented `==` overload can now be compared as well.
There are plenty of fixes, but still half of what was in the 0.7.5 release.
