Hacker News Reader

Comment by adontz | Hacker News Reader

I'm confused by "No hidden control flow"

To me control flow is "if", "switch", "?:", etc. What article describes are abstractions. Abstractions are not bad. They, just like anything else, can be abused. Maybe one may argue are easy to abuse or tend to be abused. But "Zig has no abstractions" is hardly a selling point.

On the other hard there are statements like "defer" and "try" which actually are very hidden and unusual control flow statements. Why the naming? Who the hell knows. I see try, I look for catch/except/finally, but there are none. Try in Zig means something else. "defer" is literally "try/finally", but less explicit about the scope.

"A Portable Language for Libraries" "A Package Manager and Build System for Existing Projects" "drop-in GCC/Clang command line compatibility with zig cc"

Is it still so after ditching LLVM?

View on HN

It means that control flow is determined by the code you're looking at.

"if" and "switch" determine control flow, but you can see the control flow when you're reading that code.

In languages like C++ and Java, if you have a sequence like:

    foo();
    bar();

whether execution continues to bar() after foo() returns depends on the implementation of foo(), which you can't infer from the callsite. If foo() throws an exception, bar() won't execute.

In Zig, the compiler forces you to handle exceptions (errors) at the callsite, so you can see from looking at function calls at the callsite what the potential control flow looks like.

If you saw the foo(), bar() sequence in Zig, you'd know that bar() always executes after foo(). If it were possible for foo() to return an error, that code wouldn't compile unless the callsite handled the error explicitly with a try. The try tells the reader that there's a potential control flow depending on whether foo() throws an error.[0]

[0] https://ziglang.org/documentation/0.11.0/#try

In Rust, foo() might panic but this is only supposed to be used for truly unrecoverable errors. For most recoverable failure conditions you're supposed to use foo()?; which makes it clear that execution might not proceed to bar();

> In Zig, the compiler forces you to handle exceptions (errors) at the callsite, so you can see from looking at function calls at the callsite what the potential control flow looks like.

Damn, if only Java had something like that. Where you can see from function declaration whether it can throw something. Like if you could check exception. We could call it checked exceptions. And community would certainly like them.

That still doesn't show you at the call site.

Yeah but in Zig there is flexibility how you want to handle the error opposed to Java. You don't need to rewrap everything in RuntimeException and error sets allows to specify extended set of errors without much boilerplate.

I don’t think you can ever argue that a small (and only non-runtime exception, right?) signature at the top of the function makes it easy to see what lines throw.

Even if a function is small, each and every line could be the thrower and not allow the rest to execute.

Java exception specifications are annoying for two reasons. Firstly, there's no syntactic sugar to easily rewrap and propagate. Secondly, there is no way to generalize your error handling logic - i.e. for one component to say "I want to use something that implements this interface, and I don't care what errors it throws, but I do want to propagate them all". Zig doesn't have either problem.

Java has @SneakyThrows. Fight me.

Java has a whole system of annotations that seems designed to make it impossible to figure out what code will actually be run, apparently designed by someone who thought lisp macros were too explicit.

Which is a hack that amounts to throwing one's hands up and declaring, "we couldn't make it work properly".

Who couldn't make it work properly, the language designer, the stdlib writers or the Java programmers?

There is no way to make e.g. InterruptedException "work properly" as a checked exception since there is nothing intelligent one can do about it that's specific to this exception class. Rewrapping as RuntimeEx is just as much weaseling out but using more code and messing up stack trace for no good reason.

Also, thanks for answering my request for a fight. Winter is boring.

The language designers, because they wanted to have checked exceptions without the complexity of genericizing them.

Exceptions that aren't meant to be handled really shouldn't be exceptions in the first place, but that's a separate design issue.

This is why I will never stop trying to insert throws declarations into code I write. For some reason, Java developers seem to like hiding the fact their function can throw exceptions.

The syntax problem gets mentioned a lot ("we'll just end up catching and rethrowing it anyway") but at that point you can just add throws to the calling method.

Can't foo() call std.os.exit()? Then you don't know that bar() will always execute after foo() in Zig.

Yes, but I don't really think of that as hidden control flow. I know that if foo() returns, bar() will execute next, but foo() might not return (due to panic, program shutdown, or infinite loop).

From my experience, when there's surprising behavior in software, I've frequently been surprised by silent exceptions, but I can't think of any time when I was surprised by control flow because a function intentionally shut down the program.

Basically your argument is that strncat is more readable and easier to understand than std::string::operator+

I think you have a different interpretation of “hidden” than Andy.

He is talking about control flow that is not visible to the programmer at all. In Zig, you can understand the control flow of a particular code snippet just by learning Zig. In some other languages, operator overloading means that when you are reading unfamiliar code, you can never be sure what functions might be called.

>> operator overloading means that when you are reading unfamiliar code, you can never be sure what functions might be called.

This just means abstraction were abused. Which as I said, they can be. Nevertheless most popular programming languages (C++, C#, Python, Java, etc.) have overloaded operators, you can write "hello " + "world" (or equivalent) in any of these languages.

Where does the memory for the combined string come from? Even if Zig had operator overloading it's not clear how a runtime `string1 + string2` could work.

Something like this would do https://en.cppreference.com/w/cpp/named_req/Allocator

In practice what would the actual code look like (pseudo-code is fine). How would I concatenate strings at runtime using `+`, once with one allocator and then again with another allocator?

>> once with one allocator and then again with another allocator?

I would:

1. Prohibit concatenating strings with different allocators. Strings with the same allocator can be concatenated.

2. Provide StringBuilder for concatenating anything in an effective manner. It's not only about different allocators, but supporting C-style strings and reducing number of allocations.

So '+' is only for strings with same allocator, same UTF encoding, same everything. I'm really not fond of implicit type conversions.

> operator overloading means that when you are reading unfamiliar code, you can never be sure what functions might be called.

How so? It’s clear that `a + b` calls the `+` function.

I would rephrase it as "no hidden function calls". Hidden function calls can make it a nightmare to debug code. It happens way too often in C++ code, less often in C#. But here's a C# example to illustrate the problem: https://web.archive.org/web/20021003203744/http://www.geocit...

As I said, abstractions can be abused. OK, your terminology, hidden function calls can be abused. Does not mean not having them is good.

Having fewer footguns is a good thing. When you inherit a codebase, if it is written in a language that has fewer footguns than one that does, that can make a big difference.

By this logic assembler is the best, as the most explicit language. I believe "number of footguns" is a metric people use for C++ exclusively. C++ is a mix of a few generations of a few languages, but most importantly several cultures. C++ is not bad. Qt code which uses STL here and there and a few unwrapped C libraries is bad. In that situation you really don't know what a "+" does in a particular case.

In Python or C# situation is quite different. For example I struggle recall a single case from my experience when property was confusing or was used in a confusing manner.

I don't think the point is about abstractions... it's how much you can understand about how the code executes by reading it.

Abstractions are fine, of course. In Zig, though, they should be explicit and clear. E.g., the only way to call a function is by name, using the function-calling syntax. Control flow depends only on keywords and syntax directly in front of you.

I think they do assume you known the language -- if you don't then I guess a lot might be unclear when reading code! -- but on the other hand, it's on the simpler, smaller side.

All examples are abstractions, so if point is about something else, maybe article needs different examples.

Aren't all computer languages entirely composed of abstractions, essentially?

I don't think you can infer anything from the examples being abstractions.

> Is it still so after ditching LLVM?

Zig hasn't ditched LLVM, nor does it really plan to. What's planned is for the main Zig executable to not directly depend on LLVM, that way contributors to the compiler can still develop on the code base without needing to set up and compile LLVM on their systems. Zig does plan to eventually supersede LLVM's functions with their own custom backends, but in the short term, this only means using the new backend as a debug compiler (for faster compilations, to allow for a better developer feedback loop) and it won't be until the distant future that LLVM could feasibly be dropped as a dependency entirely, if the devs ever decide to actually go through with that.

> What article describes are abstractions. Abstractions are not bad.

Abstractions are still possible, the only difference is the syntax with which they're presented. For instance, you need an "add" function for your addition abstraction, rather than overloading the + symbol.

The only thing missing in Zig is the syntactic sugar of such abstractions; the argument being that such sugar obscures more than it illuminates.

> To me control flow is "if", "switch", "?:", etc. What article describes are abstractions.

Thank you for articulating this, I also don't understand why the author puts operator overloading in the same bucket as exceptions and `defer()`. Yes, `+` might call a function, but it will never affect the control flow of the parent function. Not more than a regular function call, at least.

see my response here: https://news.ycombinator.com/item?id=39092430

I guess it's probably clearer if it's clarified as "no hidden function calls". It looks like the author wanted to generalize it because of no language level exception handling, but this could be misleading since platform level exception handling can override anything which makes it technically false.

defer has one important difference to try/finally - it places the cleanup code right next to initialization, which makes things easier to read overall.

Developer may place defer close enough, it does not have to be close. RAII is better by this logic, but too "hidden" by Zig standard I guess.

Reply on news.ycombinator.com