Hacker News Reader

Comment by lenkite | Hacker News Reader

Would it truly kill Zig to add native interface support ? All that ceremony is quite heavy and also somewhat error prone.

If nothing else, maybe they can add some helpers in the standard lib or codegen in the standard tooling to make stuff like this easier ? So one need not manually code all the function pointer types for methods and the dispatch in the interface type .

Yes, Zig is meant to be a low-level programming language, but stuff like this is basic table stakes nowadays. People will just make custom code generators after Zig 1.0 to do this exact thing - and they will likely be dozens of such custom code generators with subtle differences.

View on HN

There's just one feature Zig lacks, which would have allowed for full automation of interface definitions. In Zig you can programmatically construct data types with compile-time programming, but such types aren't allowed to have methods: https://github.com/ziglang/zig/issues/6709

This is an intentional limitation, because the language creator worries the feature would be abused.

I strongly dislike "this feature could be abused, so we won't add it" as reasoning for language design decisions. It just doesn't sit right with me. I think designing to avoid "misuse" (i.e. accidentally shooting yourself in the foot) is great, but avoiding "abuse" just reads as imposing your taste onto all users of your language. I don't like this, so nobody should be able to do it.

But oh well, if you're using Zig (or any other language using auteur-driven development like Odin or Jai or C3) you've already signed up for only getting the features that the benevolent dictator thinks are useful. You take the good (tightly designed with no feature bloat) and the bad ("I consider this decision unlikely to be reversed").

> avoiding "abuse" just reads as imposing your taste onto all users of your language.

I believe languages are all about bias. A language must represent the preference of the community using it.

We should all learn from the case of Lisp, which is the simplest language and likely the most expressible language. The community suffered from the serious fragmentation driven by the sheer simplicity of the language and tons of NIH syndrome. It took them 30 years to get a standard CL, and another 20 years to get a de facto standard package repository (QuickLisp).

Pascal was like this. Turbo Pascal was just a plain vanilla Pascal which was deemed sufficient. But when Borland themselves wanted to make a GUI, suddenly there were many language extensions added and Delphi was born. Until then the users weren't taken seriously.

Even Ada, Modula-2, Object Pascal eventually got them.

Zig is trying to fix C, by delivering stuff already present in Modula-2, minus comptime, in a C like clothing.

The judge is still out there if it will become something unavoidable in some industry circles, or just yet another programming language to talk about.

From my point of view, being stuck in the past of systems languages design, during the AI age where the actual language becomes slowly irrelevant, it will mean the latter.

I think you have fallen into an AI hype trap. Language choices still matter.

For the time being.

It was not a trap being an early Fortran adopter and envisioning what a couple of decades later would be the future of Assembly programmers.

I already do lots of programming where the underlying language hardly matters.

I think it will turn out that even for AI some language will be much more easily to code systems in than others. We maybe even get languages optimized for this in due time. So I'm not at all on board with languages becoming irrelevant with AI age. I can even see it happening that extreme typing like lean will be best. Sure it will probably take more compute to design a system using it, but that may be offset by the additional mistakes it prevents. No company likes to code in lean, since you require highly skilled people and it takes ages. But AI can defeat both of those while still getting the advantages.

Agreed that native interface support is table stakes for any language now. It would avoid so much boilerplate - nevermind the time wasted examining the code to see what kind of ad-hoc interface any given piece of code is using - and how to retrieve the ridiculous zig vtable data member for each pseudo class instance. It just amounts to useless noise in the code, rather than succinctly stating the intent.

> nevermind the time wasted examining the code to see what kind of ad-hoc interface any given piece of code is using

this is not really a problem I've encountered. did you have a specific case where you got puzzled?

In every different zig project you have to read the source code to see how their specific ad-hoc interface scheme works. Case in point - this article uses a method `pub fn implBy(impl_obj: anytype)` to connect instances to a vtable. The new zig writer uses a `.interface` data member scheme: https://www.openmymind.net/Zigs-New-Writer/ in addition to understanding when and when not to use it.

I wonder if it's possible to not lock themselves into an ABI with a built in vtable implementation? I kinda get where they're coming from: let vtables be a user problem; but, yeah, modern compilers can do magic when they "know" the rules for built in vtables. It kinda feels like they're leaving a real performance opportunity on the ground?

>Yes, Zig is meant to be a low-level programming language, but stuff like this is basic table stakes nowadays.

I think it is table stakes for higher level programming language. Zig wants to be somewhat like high level assembly.

There is still someway to go before 1.0 so may be something will be done. I mean I am still uneasy with them focusing so much on async.

I don’t find the lack of built-in interface in Zig to be a big problem. Yes. It has some boilerplates to roll in by hand, but all of the work are confined in the interface and only required to be done once.

The benefits of the language outweigh the minor inconvenience.

Agreed, this puts me off using Zig. I can’t endure this level of boilerplate any longer.

More than lack of features, what puts me off is the whole anti-intellectualism in language design from these communities, than kind of sprung of Go designers.

So while as language geek, I will spend the time to understand and play with them long enough to be able to know what I am actually talking about, using said languages for project delivery only if it is a customer requirement of some sort.

> somewhat error prone

do you have any evidence for this? what is the error you're proposing here?

I meant human error - easy to mess up when coding this boilerplate, esp if there are more number of methods. Sure some 'perfect' programmers will always get this right but the vast number of us regulars will not. Also, it is not straightforward to discover these interface types in a code base.

I like Zig and eagerly await 1.0, just wish it was not quite so bare-bones.

well if you mess up most basic things won't the compiler catch you? i was wondering what sorts of logical errors you were expecting.

No, I don't think the compiler will catch all errors. Wrong type specified in adapter, for example (typical copy-paste mistake). Signature mismatches between anyopaque and MyType, forgetting to assign a function in the v-table, etc

i think at least forgetting to assign a function is not possible? the compiler will catch that.

Yes, forgetting to assign is caught by the Zig compiler, my bad. (brainfart and confused with C++ there). What the compiler doesn't catch is signature mismatches such as anyopaque to *SomeType or incorrect adapters.

Reply on news.ycombinator.com