Ditto... I love Zig as a language but I worry the high-level community builders (including Andrew) are a little too antagonistic to foster a positive, tolerant, patient community in the long term. In saying that, my infrequent interactions in the reddit and discord are always pleasant.
I don’t think Andrew is a bad guy, but his tone seems to attract a certain kind of person. All the technical people I’ve interacted with in the Zig community have been awesome, but for whatever reason it also attracts a lot of people who are just there to shit on anything mainstream.
He has a pattern of taking any bit of criticism of his language on bad faith, and immediately goes all defensive accusing the criticizer of being a psyop working with a rival language.
Actual Zig community spaces like Ziggit is very pleasant as far as programming language forums go. I think Zig just occupies a unique space in the language ecosystem (a very performance oriented, production oriented language that is not afraid to rapidly try things and throw them out if it doesn't meet expectations in practice - not many languages sit in the middle of this venn diagram) and people see it as an opportunity to gain a social foothold in something potentially great.
It seems like it might be in the nature of a language with these goals and this development process to attract people like this, no matter how warm and welcoming the community leaders are.
For many languages I agree, especially languages with steep learning curves (e.g. Rust, Haskell). But zig is dead fast to learn so I'd recommend just nipping through Ziglings and seeing if its a language you want to add to the toolbox. It took me only about 10 hours to pick up and get used to and it has immediately replaced C and C++ in my personal projects. It's really just a safer, more ergonomic C. If you already love C, I maybe wouldn't bother.
The big thing I would say I actually learned and would intentionally apply to other languages is SIMD programming. Otherwise, I'd say it gave me a much clearer mental model of memory management that helps me understand other languages much more fundamentally. Along with getting my hands directly on custom allocators for the first time, a question that took me time to figure out but gave me a lot of clarity in answering was "why can't you do closures in Zig?" Programming in Zig feels very Go-like, and not having closures was actually one of the biggest hiccups for me. I don't think this really changed how I write in other languages, but definitely how I think about other languages.
Snap! I also played around with closures a tonne in Zig. Definitely possible but not... ergonomic. Haven't ended up using them much.
And agree with allocators; in C I always considered using custom allocators but never really needed to. Having them just available in the zig std means I actually use them. The testing allocator is particularly useful IMO.
Never used Go but if it's Zig-like I might give it a shot! Thanks!
I'll make a list of the things that both languages have in common that make them feel similar to me:
- structs and functions are the main means of composition
- the pattern of: allocate resource, immediately defer deallocating the resource
- errors are values, handled very similarly (multiple return values vs error unions)
- built in json <-> struct support
- especially with the 0.16.0 Io changes in Zig, the concurrency story (std.Io.async[0] is equivalent to the go keyword[1], std.Io.Queue[2] is equivalent to channels[3], std.Io.select[4] is equivalent to the select keyword[5])
- batteries included but not sprawling stdlib
- git based dependencies
- built in testing
I agree, I love zig but the things that make me program differently are features like excellent enum/union support, defer and comptime, which aren't readily available in the other languages I tend to use (C++, Fortran and Python).
One recent HN post I loved recently was on Arthur Whitney's insanely terse C code[0]. I personally find it beautiful, and many others did, but many did not. So it goes.
The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare).
While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refining them, and removing unnecessary ones seems in sharp contrast to the development of any other langauge I'm aware of. I'm no language historian though, happy to be challenged.
I am not sure if a slow pace is as beneficial as you say. I scrolled through the error handling issue brought up in this comment section ( https://github.com/ziglang/zig/issues/2647#issuecomment-2670... ) and its clear that only thing that happened there was communication on the issue was hindered. I come from C++ side and our "ISO C++ committee" language development process leaves a lot to be desired. Now look at error handling that they did passed in C++23 ( std::expected ). It raises some questions on how slow you can be while still appearing to be moving forward.
Disclaimer: I would like to see Zig and other new languages to become a viable alternatives to C++ in Gamedev. But I understand that it might happen way after me retiring =)
I second that. Clojure is really a great joy to use. It may take a while to shift into the mindset, especially for someone new to Lisp, but after a while it's an absolute delight.
A great degree of occasional criticism of Clojure typically comes from brief exposure - either from not using structural editing idioms, misunderstanding REPL-driven workflows, or confusion around "the type system". Of course, Clojure being dynamically/strongly typed, doesn't really have a type system in the traditional sense, yet it has mechanisms that provide type-like guarantees, and from pragmatic point-of-view those instruments are incredibly robust.
I don’t think Java and Rust were so ok with completely removing features. For example, in Zig 0.15 they completely overhauled the io, meaning all libraries now have to rewrite up usage. Just to make sure they did it right
> I don’t think Java and Rust were so ok with completely removing features.
This just shows that you weren't around for pre-1.0 Rust. Back then Rust was infamous for the language making breaking changes every week. Check out this issue from 2013 tracking support for features which were deprecated but had yet to be removed from the compiler: https://github.com/rust-lang/rust/issues/4707 , and that's just a single snapshot from one moment in Rust's prehistory.
Semantic major/minor version 0.15 means it's still in development. It's not supposed to be stable.
Going from 0.14 to 0.15 allows breaking changes.
Try making a similar change between version 5.0 and 6.0, with hundreds of thousands of existing users, programs, packages and frameworks that all have to be updated. (Yes, also the users who have to learn the new thing.)
I love it. My largest project is about 20k lines … so nothing too big. But if you need to be expedient (just quickly make a data extract/load/transform or a command line thingy) it is great fun. The LLMs seem to be pretty good too, just the usual hallucination here and there.
I thought it was useful information for people who did not know this. Of course Wikipedia would have sufficed, too: "Raku, formerly known as Perl 6 [...]".
I hear you were coming from the angle of being useful. In a sense that's what matters most, and I love that you have that spirit.
If Wikipedia has deadnamed Raku with grace then that might be a model to follow, but in general it's far from helpful unless it's done carefully. There's a reason why the community embarked on the somewhat painful multi decade process of renaming it. To try clarify my understanding I'll summarize it here.
Because of the original name for Raku, people assumed for a long time (long after it became problematically misleading) that it shared semantics, or syntax, or compiler tech, or libraries, or something technical like that, with some other programming language(s).
This was partly because Raku did indeed take some inspiration philosophically and/or technically from some existing languages (traces of a half dozen or so are evident), and partly because Raku and its compiler tech features the ability to use Python code and compilers, and C code and compilers, and Perl code and compilers, and so on, as if they were native Raku code/compilers.
But Raku was never C, or Python, or Perl, and the old name is unfortunately a form of deadnaming -- which is to say, something that is seldom helpful, especially if some commentary like this comment is not included.
At least, that's how I experience it.
That said, regardless of my view, I love your impulse of being helpful, which is why I've written this -- and I hope it does help any readers.
I don't know if taste is the correct word here but I agree with the spirit of the article, especially the parts on tinkering being a form of practice. Play (in the form of enjoyable tinkering) is such a powerful motivator in learning. In saying that I've found two big limitations with this style of play-based learning:
1. It can easily devolve into meaningless tweaking (see author's point about touching dotfiles) which can still be satisfying but not very impactful.
2. It's hard to maintain motivation when something stops being fun. This is where external motivators like bosses, clients and scoreboards (e.g. Advent of Code) are actually valuable...
