Hacker News Reader

Comment by AndyKelley | Hacker News Reader

I don't know why this article keeps showing up on HN every other year but since it's up, I took the time to read it and fix all the outdated facts.

Notably, when it was written before there was not a package manager available. Now there is, so I rewrote that section. It should finish deploying in a couple minutes.

View on HN

Since you’re updating it anyway, the very first example says "D has @property functions, which are methods that you call with what looks like field access, so in the above example, c.d might call a function.”

It is true that `c.d` might call a function, but it’s not because of @property functions (which exist but are discouraged), it’s because the parens are optional to call a function/method if there are no arguments.

Philosophically speaking, is it really hidden control flow if a function call just happens to look like a attribute access?

I've only seen flow control used in the context of conditional branching, so if the function contains no branches, I don't see why it would. Hidden overhead or indirection, sure, but not necessarily flow control, for the same reason e.g. indirect pointer access isn't.

function calls are, themselves, branches.

underneath there is literally assembly to take current state, push it to the stack, then jump into another location in memory and start executing.

And then when done, do the reverse. jump back to another memory location and pop everything back off the aforementioned stack and into registers.

Yes, but that's not a conditional branch, and that's the distinction I've always seen made for flow control versus indirection

try/catch/finally is also considered control flow and it's not conditional, although, unfortunately I've seen people use it as a control flow mechanism.

interrupts are also control flow but, again, there are no conditionals there.

control flow is about the order of execution, one common way to get there is using conditionals, but it's not the only way.

Having said that, even if you disagree with Andrew's wording, the overarching idea remains. You always know explicitly if the flow changes.

try/catch seems very conditional to me. If there is an error condition, jump to the error handling code. Or am I missing something?

I could also describe a JMP instruction as "if you got here, jump to there", but just because I can doesn't necessarily mean I should.

But Try, catch and throw are in themselves not conditional, they are fancy gotos with bookkeeping. Those constructs don’t typically deal with conditions.

However I think the notion that “flow control” has to do only with conditionals is not a common one. FWIW the definition on Wikipedia, which aligns with my experience is not this restrictive… the lowly goto is flow control. Basically anything that controls the program location is flow control.

Yeah, but raising the error is the conditional in there. Which, to me, makes the try catch conditional as well, but that may be a case of differing semantics.

Yeah, flow control isn't just conditional jumps. You can kinda treat branchless code as a form of flow control as well.

> You can kinda treat branchless code as a form of flow control as well.

That's the common understanding of flow control, the other poster is right in that it's not typically just conditionals. There are a few posters who were under that misapprehension, but that's never been the common understanding of it, it's just that conditionals are typically where people worry over flow control because otherwise it's linear.

I haven’t usually used such a restrictive definition, flow control is any mechanism that directs program location. https://en.wikipedia.org/wiki/Control_flow

And flow control and indirection are not two concepts I’ve ever grouped together as complementary either. A function call is not something I’ve ever heard as “indirection”.

When reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory. Not that it would matter that much, but it's a valid point for some. Reading a field is usually expected to not induce any control flow

> When reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory.

Unless you ditch optimizations completely, it is hard to know without looking at the generated asm. Of course you can make educated guesses.

The idea in D is to make the following unnecessary:

    struct S {
        int m_field;
        int field() { return m_field; }
        void field(int c) { m_field = x; }
    }

just to future proof the field access. Don't bother with the access functions until they are actually needed.

The actual feature that languages should implement is lenses, prisms and optics which are like properties except made properly composable and enabling high-level optimizations, for a similar efficiency to "bare" field access.

I’ve never heard of those. Do you have a link explaining them?

I found a use for the overriding field access once, when there was a large data structure bit-packed into a byte array. I didn't really need to convert it to a different data structure, but to just extract some values, and pack it back to the byte array.

So I overrode the field access that operated directly on the byte array.

PS: It was in Kotlin, using @get/@set, but it doesn't matter for the philosophy.

Yes. That can affect performance and also cause spooky action at a distance. Suppose someone less careful put some code in the accessor function mutates global state. Do you want to be checking all of your objects all the time to see if they are doing something counterintuitive?

Interesting that this is seen as a negative, C# has getters/setters that look like property access, but I don’t think I ever heard anyone complain about this.

zig and c# each scratch a different itch.

Yeah, of course. But the issue would still be the same in this case.

While the issue is the same, context can make things different. In Ruby, I love proxy objects returned from accessors. In Rust, I wouldn't even support adding accessors to the language. Different goals and objectives.

C# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state.

If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.

> because they thought its semantics are property-like,

Suppose you include a logging statement in your accessor, which hides a race condition. You're gonna tear your hair out.

Suppose you do the same in your getWhatever() method instead; what's the difference? If every property access is an explicit method call, the mental overhead on the API client is the same in practice, since most of those method calls are still semantically property-like and are treated as such.

C++ Builder also has them in their extensions to C++. My guess is that it looks convenient for languages that have a de facto GUI framework/library. In Delphi/Object Pascal, C#, C++ Builder, it becomes convenient to, for example, change a button's text as if assigning to its text value. And it is often taken for granted how the form's UI just "magically" updates. I'm pretty sure classic VB's control "properties" work that way as well.

When I was new to their corresponding GUI frameworks, the dot + property notation was appealing because it looked clean. However, as I got more experienced I'm no longer seeing the advantage of saving two parentheses characters at the expense of potentially hiding function calls where anything can happen.

I'm not sure why D joined the club given it doesn't have a corresponding de facto GUI framework, and its users even discourage it.

"If a tree falls in the woods and no one is around to hear it, does it still make a sound?"

Attribute access is reading a value, invoking a function is different (as mentioned, using a stack, etc.), although it is certainly possible a function only reads and returns a value.

All that to say my answer is yes, providing flow control mechanisms makes it flow control... and falling trees make a sound!

Hi Andrew. I once saw a video (at least I think it was a video) where you suggested the possibility of Zig reaching language stability in 2025. Is that still accurate?

The Bun team I guess doesn't care and went ahead with 1.0 launch a few months ago. If they are willing to bet it all on zig, I'm sure it will be around for a while. It's quite mature as it stands now. Personally, I think the road to zig 1.0 should be made methodically and without any timeline.

I don't know that this is an endorsement of zig rather than an indictment of bun.

Total endorsement - thanks for forcing clarification.

I don't recommend choosing technologies this way. Elm is one of many recent, prominent examples of how years of promising language work can still leave production users stranded, both with backwards-incompatible changes that are deal-breakers for many projects, and then stalling further updates anyway even for the users still able to use the latest version.

I'm not saying Zig will go the same way, I hope it succeeds. But success in industry funding is not a guarantee, successful transition to large team contributions is not a guarantee, and even if all of that does pan out, by then the language may be markedly different.

Look at Rust in 2012 vs its 1.0 in 2015 and ask yourself if you'd want you and your team to have to make so many changes to production code. Ask yourself how many unknown costs you are willing to risk in exchange for whatever you believe is the actual upside of using Zig for a particular project.

Sure, somebody has to break that cycle by making those bets, but be sure before deciding to be among them. Somebody else making that bet only changes the odds so much.

Except I’m referring to an ecosystem built on top of zig. Not Zig proclaiming to solve the web’s problems. There’s two teams here that say “we think zig is good”. One, the language team (your Elm reference), the other, the bun team (and all that js ecosystem). I’m pretty confident in saying that it’s not just some plaything or niche language. Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust.

I know what you mean but it's not that simple. The ecosystem clearly depends on the language in a very real way. If Zig changed enough to be a deal breaker for Bun, or even stopped being maintained at all, then Bun is stranded until they can move to a completely different language.

(I'm not even willing to entertain the notion that they would fork Zig and maintain it long term. Even if they somehow did which would be nuts on its own, they'd still be cut off from the rest of the ecosystem and lose out on that front.)

My best case for Zig is that it offers a worthwhile option to clean up existing C & C++ projects without incurring, or at least deferring, the more substantial costs of rewriting outright in Rust, bindings or no. "Maintain it in Zig" is a sensible value proposition, or at least it will be once that Zig code has a compatibility promise so it's not trading one maintenance cost for another.

Look at how costly it was for the ecosystem to migrate from Python 2 to Python 3, even despite how many participants in that ecosystem were themselves large, well-funded corporations. Situations like that are why Go and Rust have made permanent 1.0 compatibility promises even at the cost of some tech debt which they know will only accrue further. Zig will too, but it hasn't yet, and anybody adopting it now risks unknown migration costs.

> Then again, I can’t predict the future and it could very well be that bun and zig both blow up. Same could be said for Rust.

Sure, lots of things are possible, but ask yourself which is more likely. That's all I'm saying here. Rust has already been where Zig is now and is in a meaningfully different place today: a stability promise and substantial industry adoption and contribution. It no longer depends on any one person and a lot of investment is going in to its continued success.

Anything can still fail, but there aren't that many examples of languages outright failing after reaching this point in industry adoption. There are many examples of languages outright failing by pushing backwards-incompatible changes on the industry right in the middle of what should have been a healthy growth curve. There are also many examples of simply not offering enough marginal value to justify their marginal costs.

The title here is "C++, D, and Rust" and, I'm sorry to say, but one of these is not like the other ones. Zig will have a lot of work to do in order to end up more like Rust than D, especially when memory and thread safety are a big part of why the industry is adopting Rust in the first place. Notice how Chromium does not have a Zig branch just like it never had a D branch. It was all C++ until Rust offered clear improvements to safety in exchange for its adoption costs.

“Notice how Chromium does not have a Zig branch just like it never had a D branch. It was all C++ until Rust offered clear improvements to safety in exchange for its adoption costs.”

Chromium has a rust branch because “Rust has X feature”, not because zig does too and there was never a decision: rust or zig.

That’s apples and oranges my friend. All I’m saying is Zig, while lagging behind its corporate sponsored behemoths, is going to be around for quite a while. There’s a lot of game dev happening with zig too. Bun is just an easy target to use as an example.

I do agree with your argument about “why choose X over Y to rewrite your codebase” but to clarify, I never made such comparisons. I wouldn’t recommend zig for a c++ refactor. Maybe a rewrite if it was small. Definitely for green field development. A stability promise is still just a promise. Backwards compatibility is a valid argument to make. Will my code from a decade ago compile today? Zig still has some growing to do before that is true.

They also made a 1.0 release without Windows support, so that already says a lot about what they care about.

Probably because it's a sort of call to arms to those languages to try and improve things where Zig is currently on top :D. Some of those can't be fixed (e.g. hidden control flow, hidden allocations) but some can (e.g. I think D has an alternative allocator API, it can now compile C/C++ code as well, and I believe its package manager is trying to add support for system dependencies as well).

D has a pluggable GC, if that's what you mean. It makes trying out various GC strategies easy without modifying the compiler.

D also supports the following memory allocation strategies:

1. RAII

2. stack allocation

3. malloc/free

4. custom alloctors

Each has its tradeoffs, you can pick the most appropriate one. The D compiler itself uses all of them :-/

New people will constantly be finding zig, and they will constantly be wondering why they should pick up zig, they will find that reference, and share it to educate others!

You can see this happening with the duplicate stories that show up on Hacker News; in general, it's a good thing:

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup

I think most recently, I saw Mitchell Hashimoto endorse it on Twitter.

He's building a terminal emulator with zig: https://mitchellh.com/ghostty

By chance, after I read your comment I found a talk he gave about his project Ghostty.

Ghostty - A new terminal emulator written in Zig - https://zig.show/episodes/32/

Great, concise summary.

Note: the original article title could perhaps be updated to include Golang as it is mentioned a few times.

What about the Go try/catch claim? There is no try/catch in Go. Returning errors and values is closer to Rust and Zig than D and C++.

Go has panics. You can unwind them, and recover from them. Using these for control flow is heavily discouraged and therefore it's rarely ever an issue, but they are a type of exception handling, or at least very close to that.

Rust has panics too, which also unwind, and you can also recover from them; they are also a type of exception handling. Unless the project was compiled with panic=abort, in which case they don't unwind at all and you can't recover from them; the existence of the panic=abort option means one cannot reliably use them for control flow, which makes it harder to abuse. But even then, you still have to make sure your code is "panic safe" when writing library code (usually through clever use of RAII guards, instead of expecting the code flow to always reach the end of a function).

Also worth noting is that while they are discouraged, the very same Go devs who discouraged this pattern chose to use it in the standard library for basic things.

Cool to see the Bun team used Zig.

Reply on news.ycombinator.com