It makes me think that it's worth sitting down and considering what all the valid outcomes for a piece of functionality are. A user typing in a string in the wrong format is not necessarily "exceptional", whereas running out of memory while getting the input would be. I feel like programmers too often treat perfectly valid outcomes to be errors. For example, in Rust I'll see Option<Vec<Foo>> and I ask myself if we could just use the empty vector as a valid return value.
Rust shines in user-space systems-level applications (databases, cloud infrastructure, etc.) but definitely feels a bit out of place in more business-logic heavy applications.
I was really interested in lisps for a couple of years, but eventually I came to the conclusions: it's just hard to read. I know they say "the parens disappear" but even if that is the case, it simply requires you to jump around the expression holding lots of context in your head. I'm a fan of code that mostly reads top-to-bottom, left-to-right.
Not speaking for all Go programmers, but I think there is a lot of merit in the idea of "making zero a meaningful value". Zero Is Initialization (ZII) is a whole philosophy that uses this idea. Also, "nil-punning" in Clojure is worth looking at. Basically, if you make "zero" a valid state for all types (the number 0, an empty array, a null pointer) then you can avoid wrapping values in Option types and design your code for the case where a block of memory is initialized to zero or zeroed out.
I like the goals of this language a lot and I've wished something with these goals already existed. But, I'm not sure if this syntax/approach is quite what I want. Really cool project, though!
I have always felt like Swift is the king of application development. The syntax and ergonomics really lend itself to UIs and the like. It's a shame that the Swift compiler is on the slow side.
It seems to me like parser combinators are always more trouble than they're worth. People often have the impression that parsing is difficult and should be outsourced to another library, but often it's pretty simple to hand-roll and usually it makes faster code.
I agree with the sentiment of this article but the question that fascinates me is "when do you need a language feature instead of a library in order to accomplish X, Y, or Z?"
I see people waxing poetic over Ruby a lot saying that it's a language "built for the human". The thing is, every language is built for humans (or at least should be) but we tend to have different definitions for what "built for humans" means. Ruby certainly has some clean and expressive syntax, but I personally find it difficult to use because of its dynamic typing (which makes it hard to know what the types are while I'm writing it) and the heavy use of macros and other magic (which does unknown operations without my knowledge and introduces symbols into the scope mysteriously). That said, it clearly works great for some humans, just not for this human (me).
I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probably leads to better software because nothing is "hidden". But, I also think that there's a level of abstraction/indirection that makes code clearer and less error-prone. It's a tricky balance to achieve, and past languages have succeeded and failed at it to different degrees. Either way, I echo the OP's sentiment: if Zig is your jam, great, go make some awesome stuff with it. It's just not my go-to today.
Thanks for those links. Have you tried using arenas that give out handles (sometimes indexes) instead of mutable references? It's less convenient and you're not leveraging borrow checking but I would imagine it supports Send well.
For those who are interested, I think that arena allocation is an underrated approach to managing lifetimes of interconnected objects that works well with borrow checking.
Piping syntax is nice for reading, but it's hard to debug. There's no clear way to "step through" each stage of the pipe to see the intermediate results.
I love seeing these kinds of explorations in the realm of language design. I've wondered about expanding the notion of boolean operators like this. For all its flaws, one thing I've always liked about JS is the overloaded (||) and (&&) operators. It's really slick to write something like `foo.get_that_can_fail(x) || "default value"`.
I'm less concerned about people not adopting other frameworks. I'm concerned about people not knowing/learning the fundamentals of how websites work. It's apparent in job interviews that developers from bootcamps are only learning how to make sites/apps with React and don't know the fundamentals that support it.
"So-called "natural language" is wonderful for the purposes it was created for, such as to be rude in, to tell jokes in, to cheat or to make love in (and Theorists of Literary Criticism can even be content-free in it), but it is hopelessly inadequate when we have to deal unambiguously with situations of great intricacy, situations which unavoidably arise in such activities as legislation, arbitration, mathematics or programming." -Dijkstra