This is a excellent write-up. I'm really impressed how quick it was to whip up a UI for manual solving.
I would argue however that Rust counts as a functional programming language, however. Algebraic data types, higher-order programming and immutability are all idiomatic features of the language.
I was impressed by that too. It is a very valuable skill, to be able to build a UI prototype that quickly. The author attributes it to Clojure and there is certainly truth in that, but given he also basically learned a new programming language in a day and got a decent rating on his solution makes me think it is not just the tool. For one, this is a smart and skillful programmer. But it also takes a playful mindset and training to be able to do this.
The fact that the author was able to find success with Zig so quickly speaks not only to the author's abilities but to the simplicity of Zig. Learning enough C++ or Rust to be productive in the same amount of time would be a much greater challenge.
Rust is missing the function part though. For good reason - closures and GC are like PB&J. But programming exclusively with closures like you can in Haskell or Scheme isn't as feasible in Rust. This isn't to say Rust doesn't have excellent closures, lambdas, etc given its design constraints.
So we can decoralate winning the first prize and brute forcing. OP is saying language matters if you want to brute force and not say, win the first prize.
I want to like Zig, but I also want operator overloading because multiplying matrices together in chains of functions is among the ugliest code I've ever had to look at. There have been more than a couple decent suggestions for making it clean and obvious, but there are a few things that Andrew isn't willing to budge on.
> defer is pure genious
Being able to defer for resource cleanup is nice. I like that Zig makes it a priority to make things adaptable (not sure that's the right word). For example, everything in the std lib that allocates, takes an allocator object, so if you want to implement a custom allocator, it's very simple to use. If you want to use a custom event loop for async, it's easy to substitute. All in all, I think its shaping up to be a nice language, just not for me.
Every day I see people avoiding entire interesting languages for bad reasons. Little things they are used to and don’t yet know how to work around the change, but you would learn and it would be fine.
the lack or presence of these things are never deal breakers, it can be worth trying to adjust because maybe you will find 900 things you love about the new way that make up for the one or two things you think you can’t stand.
I’ve yet to find the perfect language but that doesn’t mean I’m satisfied with the imperfections that exist in the ones I use. It’s perfectly reasonable to not use a language for lack of operator overloading. I personally avoid languages developed with contempt for functional programming and type systems. We all have our reasons.
I've used zig for projects before. It's a nice language with some improvements on C, just not ones I care about. I did adjust, finished the projects I was doing, and I decided to move on to something else. I had a problems with the C interop as well. It's likely that I was doing something wrong, but the documentation is poor and I want something that just works.
Again, the language is great. It's a young project. I'm glad you like it. Andrew seems to have a very firm idea of where Zig is headed. It's just not for me, in part because operator overloading is not a "little thing" for me.
> the lack or presence of these things are never deal breakers
Sure, but it can definitely break a tie. Frankly, operator overloading can create some really nice apis. And code that's pleasing to read takes less mental overhead to pick up.
I was actually thinking about writing a “macro” (i.e. function) which takes in a math expressions as a string and an anonymous struct for these use cases:
I'm a bit sad there seems to be no interest in adding interpolation syntax to Zig. While anonymous tuples work well for shorter expressions, they can get confusing for larger textual templates or DSLs, imo.
I've been experimenting with Zig for WASM, for example, and the readability of HTML templates suffers. I'd love to be able to pass arguments inline, and while we can do that with anonymous tuples, the added noise makes it annoying to use in practice. I believe Javascript's template literals, out of all things, would be a fitting inspiration for a little syntactic sugar on top of anonymous tuples:
var tuple_params = html.create("{} ... {} ... {}", .{a, b+c, observable});
var tuple_inline = html.create(.{"", a, " ... ", b+c, " ... ", observable, ""});
// equivalent to tuple_inline
var tuple_sugar = html.create(`{a} ... {b+c} ... {observable}`);
> because multiplying matrices together in chains of functions is among the ugliest code I've ever had to look at.
OK, but how much code is it? I doubt even a game engine has matrix operations in more than 0.1% of its lines of code (obviously, in Matlab/Julia it can by 99%). The beauty of so little code is a worthy sacrifice for the explicitness of a low-level language.
It also comes up with vector addition, subtraction, and multiplication, all of which are used all over in gameplay code.
I like Zig overall, but lack of operator-overloading just seems like a pain to me.
Zig in many ways puts faith in the coder to not screw things up, but in this case it diverges from that philosophy. Would it be too much to trust the user not to overload operators in an unacceptable way? Social convention over technical constraint.
That said I'd be more persuaded by the argument that it's not worth the extra code and complexity for a language as concise as Zig.
> lack of operator-overloading just seems like a pain to me.
It is a pain, but all things considered, having it would have been a greater pain. Note that the main issue with operator overloading in Zig isn't so much the operator part but the overloading part, because overloading introduces ambiguity that cannot be resolved at the code-unit level. Zig doesn't allow name overloading even for ordinary identifiers (actually, Zig is more strict in its opposition to overloading than Clojure or Erlang, which do allow it when there can be no ambiguity). I think it's more likely that Zig will allow user-defined infix operators (say +' or something) before it allows overloading of any kind.
> Zig in many ways puts faith in the coder to not screw things up
I understand Zig very differently. Zig puts a lot of effort to make it hard for the coder to screw up. Even where it doesn't enforce correctness at compile time or at runtime (and it does both much more than C++, to the point that the goal is to eliminate all or nearly all undefined behaviour in safe mode), its strong emphasis on correctness, including functional correctness, is expressed precisely through a simple and lean language that's easy to understand, so that it's harder for the programmer to screw up (plus fast compilation and easily isolated code units). So to the extent that Zig puts faith in the coder (less than C++, more than Rust), it can do so because the language is so lean and simple.
> because overloading introduces ambiguity that cannot be resolved at the code-unit level
Can you explain this a bit? Operator overloading just seems like such a strange bugbear of Zig folks to me. Maybe I've just never been bitten by it, but at least in Elixir, my main language, I've never really understood the danger.
Are operators truly so different from functions? You'd expect that any function you import could do, well, anything. Aren't operators essentially just the same thing, just with a "prelude" in the language that basically imports them by default?
In Elixir, you might have (discouraged):
defmodule MyMod do
import MyOperators
and then you know to check what's defined by MyOperators, for that module. But more common, if you really wanted to overload, would be to be more specific:
defmodule MyMod do
import MyOps, only: [+: 2]
and then you know plus (with two arguments) has a different meaning in that module.
I’m not super familiar with Zig specifically, aside from watching some of Andrew’s talks and coding streams. But this thought process is not a Zig only concept. As far as I know, the explicit ‘operators’ that are provided with Zig are guaranteed to be a low-level construct (ideally implemented at the ISA level) which are made visible to users of the language in standard ways, i.e. infix arithmetic operators. When overloading of these operators is allowable that guarantee goes out the window. There is a fundamental difference at the generated code level between a function call resulting from a use of ‘’ to multiple two random matrices and a use of ‘’ to multiple two 32 but integers. Further, as I understand it, Zig guarantees that anything that allocates memory does so explicitly and anything that calls a function does so explicitly. The very concept of operator overloading is incompatible with such a guarantee. So, I think given the implied goal of explicit is better, it makes sense that a flat rejection of operator overloading is the broad view.
> Operator overloading just seems like such a strange bugbear of Zig folks to me.
Not operator overloading; just overloading. You can't overload ordinary-named subroutines in Zig either.
> and then you know plus (with two arguments) has a different meaning in that module.
That's not overloading, that's shadowing. Overloading is when the same name refers to multiple things depending on the type of its arguments. Erlang allows overloading based on arity, but that's something that can be understood from the call-site code.
> overloading introduces ambiguity that cannot be resolved at the code-unit level
This seems clearly false to me. Operator overloading is non-virtual type-based dispatch, just like the dot operator for method calls in C++/Java/etc., and is resolved statically at compile time. You can think of overloadable "+" as just syntactic sugar for an ".add()" method (in fact, this is more or less exactly how it's implemented in Rust). Even if your language doesn't have methods, you can implement overloading with typeclasses, like Haskell does (as does Rust, formally speaking).
Operators are a red herring here; what Zig disallows is overloading of names, period. Yes, overloading is resolved statically at compile time, but that's not the point (Zig does allow dynamic dispatch). The point is that a simple understanding of what the code does requires information available outside the unit (subroutine or even file). A subroutine can contain two references to `foo` resolving to two different targets, but you can't know that from the code in the subroutine. The meaning of a name must be defined in one place in Zig, and a name can only refer to one thing.
We could certainly argue on whether disallowing overloading is helpful, but it's first important to understand what the principle is, and it's not about the operators.
> The point is that a simple understanding of what the code does requires information available outside the unit (subroutine or even file).
No, it doesn't. Knowing what function "+" resolves to requires only the type of the left-hand side (or, I think, the RHS as well in Haskell). Absent overlapping instances (which Rust doesn't support, and Haskell only supports with an extension), there can only be one such function implementation per type. And, since top-level items are fully type-annotated in Rust (and idiomatically annotated in Haskell), this is a completely local determination. Therefore, for every occurrence of "+" in the source, it's completely unambiguous which implementation "+" calls, and this can be determined solely by looking at the calling function.
The end result: Rust, like Zig, disallows overloading of names, but Rust also effectively supports overloaded operators via traits (typeclasses).
> there can only be one such function implementation per type
Right, and that's more than one definition per name. In Zig, a name refers to only one definition. (Plus, recall that in Zig the type of a target isn't always known when reading the code, probably more frequently than in C++ or Rust, where this only happens in macros.)
> disallows overloading of names
That the definition referred to by an identifier depends on the type is what overloading means. Overloading is the very essence of traits.
> in C++ or Rust, where this only happens in macros
Sorry, this is wrong. In both of these languages it happens much more frequently. All the time, in fact, whenever you either infer return types or just chain calls on return values, or when the type is a generic/template type parameter. So when you see `foo(e)` or `e.foo()`, where `e` is some expression, you can only tell which definition of `foo` is referenced -- or even whether two instances of `foo` refer to the same definition or not -- by figuring out the type of `e`, which is often implicit in the code.
> Overloading is the very essence of traits.
Which is why in Zig, the mechanisms that perform a similar task to that of traits -- i.e. abstracting over types -- work differently, without overloading.
As a general rule, Zig does not want the semantics of a piece of code to depend on things the compiler might know but the reader of the unit might not. Whether or not such a degree of explicitness is a worthy principle for a low-level language is a matter of taste, I suppose.
IMHO better than operator overloading (which opens the gates to hell) would be builtin vector and matrix types like in shading languages. Currently Zig has a vector type builtin (search for @Vector and/or std.meta.Vector), which supports the "simple" operations (addition, subtraction etc...), so it's halfway there, but no swizzle, and no matrix types.
I would love to see Clang's ext_vector_type extension features in Zig, it lets you write code like GLSL, including easy swizzling. Add the same thing for matrix types, and the the feature would be complete, no need for operator overloading:
Would it be possible to do a slight Zig fork that works a bit like Rust, where + calls the add(), - the sub(), and * the mul() designed specifically for cases that needs it? Or maybe do it by declaring something at the top of your file? That could be a good compromise.
Having used defer in golang, I'm firmly in the camp that scope-based cleanup like defer is bad and value-based cleanup like destructors is better.
Say you have this (pseudocode):
function foo() {
let bar = make_bar();
defer cleanup_bar(bar);
let baz = make_baz();
defer cleanup_baz(baz);
let quux = make_quux();
defer cleanup_quux(quux);
do_something_with(bar, baz, quux);
}
Now imagine you have multiple functions like this that all create bar, baz and quux's. Say these are unit tests and the bar-baz-quux are mocks or whatever.
So you decide to DRY by moving the creation to a common function.
function create_mocks() -> (Bar, Baz, Quux) {
let bar = make_bar();
defer cleanup_bar(bar);
let baz = make_baz();
defer cleanup_baz(baz);
let quux = make_quux();
defer cleanup_quux(quux);
(bar, baz, quux)
}
... except this doesn't work any more, because the cleanup happens within create_mocks and create_mocks ends up returning cleaned-up values.
You could fix this by switching to a callback approach:
function run_with_mocks(f: function(Bar, Baz, Quux)) {
let bar = make_bar();
defer cleanup_bar(bar);
let baz = make_baz();
defer cleanup_baz(baz);
let quux = make_quux();
defer cleanup_quux(quux);
f(bar, baz, quux)
}
... but now you have to make the caller use a callback that necessarily returns void and not any other type. (This is mostly a golang problem, since languages with generics can be generic on the return type of the callback.) It also means you can't easily do things like set variables in an outer scope easily, depending on how the language deals with closure captures.
Worse, if not all tests use the same mocks, you actually end up with multiple of these functions:
function with_bar(f: function(Bar)) {
let bar = make_bar();
defer cleanup_bar(bar);
f(bar)
}
...
function foo() {
with_bar(bar => {
with_baz(baz => {
with_quux(quux => {
do_something_with(bar, baz, quux);
});
});
});
}
All these problems are avoided by having destructors.
I'm not arguing against destructors, but this example is ultra contrived. Why would you defer cleaning up objects you are returning? That's no longer your responsibility.
Instead you'd return an object, and make it the callers responsibility to close it. Destruct all three in the close call.
It may not fit your mental model, and that's fine. But let's not pretend it's a serious hurdle.
No, it's not a psychological problem. This is real complexity, and it's one of the most serious and widespread issues in software development.
The key issue is that we often have rules that say: Whenever A happens then B must happen as well. It is absolutely critical that rules like this are expressed in exactly one place and that enforcement is opt-out not opt-in.
Everything else is error prone and creates significant mental burden.
This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that. For your case with mocks (note mock as a noun, not a verb, which is a bit of an antipattern anyways, see: http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-...). That aside:
Go doesn't have generics so you can't really do this, but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront, make_ functions that return the pre-initialized stuff, followed by running the function, followed by no-op deinits, followed by whatever forensics you'd like to run later.
>This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that.
This is missing the point. The point of a destructor is that it runs automatically. .deinit() is the same as the three cleanup_*()s in my example and thus has the same problems.
>but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront
The third example in my post shows why this is inadequate.
Then im not really sure what your point is, because I've written zig code that reuses code in a similar way to what you are talking about, with three different forms of parallelism calling into some common runner code each of which has different needs for resource cleanup times (single threaded, cooperative, and independent parallelism). It wasn't a problem.
Have you tried doing what you propose in zig? Ultimately, the only difference between a .deinit() and a destructor is that one is explicit and the other is not. There are cases where you can easily make a mistake for both an explicit destructor and an implicit destructor.
Again, your Foo always contains a bar, baz and a quux. And again, the third example in my original post talks about how not every test needs all three.
Ah, I understand now. My understanding is that with zig and go, one does not DRY deferring, it's just a part of the idiom trade-offs between verbosity and explicitness.
So if bar, baz, quux aren't intrinsically related as a unit and might be mixed and matched arbitrarily, you just forego the whole ceremony and call each thing or the respective mock individually (the argument being that if you're making multiple different permutations, you're not repeating yourself per se; e.g. mocks don't need to be cleaned up in the first place)
There's also something to be said about tests needing several arbitrary mocks. Normally, I'd consider that a smell. I've actually seen the pattern of making a kitchen sink foo for scenarios like that, but with nils/noops for unused things (can't say I like that approach though).
It's a huge code smell. It's funny because just today I was listening to a podcast about testing and they talk about exactly these sorts of contrivances as being a good sign you should not be mocking something in a test.
With the three mocks I gave, there are 2^3 - 1 = 7 possibilities of which mocks a particular test needs. Of these, three are degenerate cases of a single mock each which would be served by the individual make_* already, so that leaves four cases of make_foo* that you'd need to implement.
With more than three mocks, this number grows rapidly.
func newMocks(
) (
foo Foo, bar Bar, baz Baz,
cleanup func(),
)
and making the caller responsible for calling the cleanup function, possibly in a defer. To me, this seems like a good trade off between making a little more work for the caller and keeping things explicit and under the caller's control.
This doesn't work with the third example, ie where the set of mocks is not the same for every test. This suggestion devolves to the original code that we were trying to refactor.
Then the original code is perfectly fine and does not need refactoring. You create the mocks you need with cleanup defers and you're done.
You could just make a function that creates all the mocks needed for all tests, but you don't like that. So the only option left is to specify which mocks you need for each test... which is exactly what the original code is doing.
You're running into a wall because you're trying to abstract code that's already maximally abstracted.
I wonder if "conditionally send a local variable over a channel" is another good example of something that's hard to clean up with defer.
One upside of destructors is that adding destructor cleanup to a type isn't necessarily a breaking change. (In Rust terms, as long as the type isn't "Copy".) But in languages with defer or with/using statements, it is.
Another upside of destructors is that the cleaned-up state can be mostly hidden from other code. But when cleanup is a regular function, it's easier to access an object after cleanup, and you have to reason more about what happens in that case. (A Rust example here might be "What happens if you use a Box after it's freed?" The answer is that you just can't do that, even though Box doesn't have a freed/null state.)
Wait, the moment a creator function returns its created values, it is also returning their ownership. So at least with that concrete DRY refactor you are showing, you're effectively not only moving code but also responsibilities around.
But I get your point: with destructors you are free to change the ownership responsibilities, because the link between a variable and its releasing is implicit and carried over by the runtime, instead of explicitly being cared for by the code.
100%. And another problem with defer is that it only works in function scope, not block scope. This bit me in a piece of Go I had to refactor into multiple functions recently when all I wanted to do was a few lines change around a 'for' loop. The code review ended up being more substantial and it made the code less readable than just being able to sprinkle in some additional defers.
With the C++ destructor RAII pattern I can use it at any lexical scope I need it at, which is super handy.
Zig's defers, at least, are block scoped. So they are executed at the end of whatever block they're created in, in contrast to Go's version of defer which is function scoped only.
RAII is very obviously a bad idea, and I'm shocked that more people can't see this. it's "fine" until it isn't, and when it bites you, it crushes your arm. you are unlikely to ever forget this after it happens. it's like driving a car fast while blindfolded; you will crash, and it will hurt, it's just a matter of when.
Use-after-free is definitely the major footgun portion of RAII in C++ (in my experience) but seems to me like the same issue would be present in any non-GC'd language that offers a 'deferral' mechanism, asynchronous or not (unless it has ownership/borrow management like Rust as you point out).
>When people show how to accomplish that, you state 'well what about my test that doesn't need all three?'
You've phrased this as if I said this after I'd been given a solution for the initial problem. In reality, I mentioned this in the original post itself, but it seems many people didn't read it.
It's almost like I have prior real-world experience of this problem, where I already went down the path of making common functions for all the creation and cleanup respectively, only to find that it doesn't help when all the functions don't create the same subset of things.
Hey, I didn't mean to come across as rude but when I reread it, it was. I wasn't expressing myself well, I apologize.
I've been a Go mentor for years, and see how people take concepts they are used to and try to shoehorn them in, and complain they are ugly.
In this case, when I first saw your examples, my thought was 'youre doing it wrong'. But not wrong as in incorrect, but now how the language was designed.
If you truly care we can go through scenarios and I can tell you how I'd approach it. But in my past experience, when people find a paradigm they like, they tend to not listen.
These are great examples. I knew that I preferred destructors over defer, but I could not explain why. You put it into words.
I think people have a bias against destructors because of C++, but they really are pretty nice. Speaking as a guy that uses C instead of C++, destructors are the one thing I would add to C.
They certainly have their problems. They're functions that get invoked without any code to explicitly invoke them. You have to consider whether a destructor can be invoked on a partially constructed object. You have to consider whether a destructor can be invoked more than once. You have to consider providing the ability to not call the destructor for performance. etc etc
It's understandable why a language trying to be close to C in spirit does not have them.
Yes, those are all problems with destructors, but they are well understood. However, in a language I am currently creating, calling a destructor on a partial object is impossible because the object is created in "one" step. In other words, constructors themselves don't have access to the object in a partially created state.
I agree. For example, most of Rust libraries uses the drop handler (something like desctructors) to close a file descriptor.
However it has problems since in async model closing is also async and it may return an error.
So in tokio-uring explicit async close will be provided.
https://github.com/tokio-rs/tokio-uring/pull/1/files#diff-3d...
Note that there are ideas to fix this issue in the async foundations WG. It's arguably more of a problem with async as implemented in Rust than with the concept of RAII.
The motivation for explicit allocation is explicitness, not adaptability. The adaptability is great, but it's a consequence of the language designer's design principle that all function calls will be explicit via (), and all allocation will be explicit via allocator-passing, so no user of a library can be surprised that a call performs an allocation.
Defer sounds like a nice improvement over old old languages, but Java's try-with-resources is one of the nicer ways of handling resource cleanup I've seen in a "mainstream" language, it's fairly neat and conceptually similar to some stuff I've seen done with lisp macros or Ruby blocks. It seems like defer is still lacking compared to this.
With defer it's developer's responsibility to free resources in right order, when one depends on another. Maybe something like this in Zig would be better:
try std.fs.cwd().openFile(path, .{}) |file| : file.close()
{
// ... code ...
// file.close() is called at the end
}
Yes, but look at the example in the blog post of this thread- "stat" depends on "file", "file" depends on "path". You can call defer in any order in your code, the language syntactically doesn't enforce you to call defer right after resource acquisition. "try-with-resources" in Java (or "using" in c#) will always call "finalizers" in order opposite to how resources where created. Following the syntax I inveted above, for someone used to Java it would be easier to read than to think how defers are called:
I've never used Clojurescript, but I have played around with Fable (F# to JS transpiler), and from memory I had a bit of a headache with transpiling non-framework dependencies and getting it to talk to Javascript libraries (e.g. Plotly). It wouldn't surprise me if Clojurescript was the same.
It's by no means impossible, but at the end of it you do wonder if the benefits of the language outweigh the hassle of getting things up and running.
I'm not convinced that Zig is the best 'low lovel' language for such kind of context: it's more targeted for'embedded' use when you need 'absolute' control.
A compiled language with a GC like D or Nim seems more productive..
Have written code in all the languages mentioned and the performance characteristics of them are not seriously different enough to warrant the decrease in productivity if this was the goal.
The clear usecase for Zig is in resource-constrained environments (it produces the smallest binaries I've ever seen) or when you want a very strict, Rust-esque type system.
I'm not saying you can't use it outside of that, or that it isn't a great language, but that as far as how many braincells and lines of code go in to solving a problem in Zig vs D vs Nim and very different for what is generally a small amount of performance.
(Also both of those languages have no-GC modes, just FWIW)
I'm disappointing with the author for not trying Modern C++ for himself instead trusting the "others".
I trusted the "others" (Eg Linus and Richard Kenneth Eng) and missed JavaScript and C++ for so long.
Now, I use both of them. Never trust "others". Try yourself and you will see how amazing those languages are.
You fought with borrower checker with Rust but in C++ you don't have to.
With Zig, you have to manage the memory manually but with C++ you don't have to thanks to the RAII
If you went with C++, you probably have saved several hours of your time.
Zig is cool but I am not gonna to use it near time soon unless they add overloading.
I understand they want to keep the language simple. But this same simplicity itself gonna to hurt the language in future when used in large applications.
"what you read is what you get" is what actually failed C in large applications. It's impossible to know everything in whole world. We have to learn to appreciate abstractions.
I would argue however that Rust counts as a functional programming language, however. Algebraic data types, higher-order programming and immutability are all idiomatic features of the language.