Hacker News new | ask | show | jobs
by MomsAVoxell 27 days ago
Individual developer convenience takes priority early in projects like this, in lieu of actually thinking about the consequences of the design. It was convenient to have package management in the compiler, it meant the developers didn’t have to think about things outside their own scope - but as the language and its tooling gets wider adoption these personally-beneficial features become liabilities to adoption.

It happens in many projects .. devs will just ‘do something convenient so they dont have to do the work to do it properly’ and then that just becomes the convention, because nobody else wants to do hard work to do things properly, either.

2 comments

I can accept this for a hobby project language that unexpectedly blew up in popularity. Go is not that language. Zig's developer also had grandiose plans for his project language, based on his writings, so I had expected more care put into its design.
You underestimate the difficulty of designing a language by at least an order of magnitude.

You've basically arbitrarily focused on a particular flawed design decision of a language while ignoring a thousand others that they may well have gotten right.

It's not possible to just sit down and get everything 100% right up front. The language design space has too much both depth and breadth to it.

If he had left that coupling at 1.0, I’d agree that would be careless. But he didn’t; that one expedient choice was reversed before mass adoption.

IMHO, you may be confusing “care” for legibility. The creator(s) made a choice that you disagree with and that you may not understand. They also haven’t justified or explained their choice to you. That illegibility might feel careless, even a little mean, but I reckon their focus was on figuring out the language, not seeking widespread approval.

Fair, but with all the new C-alternative languages I also see a lot of Chesterton's Fences being teared down. In part, this is also perfectly fine for experimentation, but sometimes it leaves me wondering as well.
Software is a social activity, therefore it follows social mechanics, organically. As time goes by, all these fences will need to be maintained or removed.
It is exactly because software is a social activity that one should try to understand the purpose of a design before changing it.
Well then go ahead and dig for that understanding :) From hearing interviews with some of the zig developers it's imho pretty clear, how deeply involved they are with their work.
I would agree that the zig developers know what they are doing. But not necessarily all fans of the language...
So in the context of future newbie Zig users, I think this package re-tooling is wise.
Always. Without an effort to understand, there is no social action, nor activity.

Which is why it’s so frustrating when bikeshedders use indecipherable shades of paint.

Good code is best made understood at scale .. or at least, that’s how it used to be.

Anyway I think the Zig folks are pretty clever and know what they’re doing .. I”m sure there are holes to poke in all of it, but I wonder what the big Zig projects will do with this change…