Easy Interfaces with Zig 0.10

https://zig.news/kristoff/easy-interfaces-with-zig-0100-2hc5

by todsacerdoti • 4 years ago

110 71 4 years ago

hsn9153• 4 years ago

Is it still a feature of the language that it's rules are simple enough so you don't need to debug your knowledge of the language?

Neither this `inline case else` nor the async/await make sense to me. Granted, I don't use the language, but when I tried to read the documentation/tutorials to understand them, I couldn't. With async/await, I read the docs then tried to debug my understanding and the small amount of code I wrote didn't work the way I expected.

ephaeton3• 4 years ago

don't know about the language rules, but I've had to wait for the explanation to understand what was about to happen. Naming is hard, d'oh, but I feel this could have a better name. "inline" does not trigger my brain in a way a "comptime_expanded" or "comptime_generator" would, e.g.

I believe andrew and loris have been with zig for long enough to have their own bias and no longer be aware of it, thus I believe it's the newcomers' job to hold up the simplicity design premise now...

kristoff_it8• 4 years ago

"inline" constructs all behave kinda the same way in Zig, like I've explained in the article. Once you're used `inline for` etc, it all works in a fairly homogeneous way.

This article was mostly about pointing out how `inline else` lends itself really well to writing tagged union interfaces, I would expect anybody who actively writes Zig and has metaprogramming experience to not have much trouble using it.

audunw2• 4 years ago

But "inline" is routinely used in C in "inline functions".. I don't think anyone with a decent amount of experience with C would have trouble quickly seeing what inline means in Zig, and those people are the primary target audience for Zig.

It's short and concise IMO.

frou_dh4• 4 years ago

I believe andrew and loris have been with zig for long enough to have their own bias and no longer be aware of it, thus I believe it's the newcomers' job to hold up the simplicity design premise now...

Zig aside, that's an astute observation in general. I think this is an issue in Python where the old guard that have been part of the project for decades and are extreme experts have gotten bored and started cramming in new language features.

anonymoushn7• 4 years ago

It's a smallish language and a big part of the appeal to me is that I can fit most of it in my head.

Async/await is a sharp corner, easier to start elsewhere.

hansvm2• 4 years ago

The funny thing is async/await is actually fairly easy to understand (IMO a bit finicky to use, partly because manually managing resources with that control flow is tricky, partly because of bugs that need workarounds pre-1.0), but the docs aren't stellar, so you have to experiment a bit or ask the community how certain code is supposed to be have.

As one example, here's a description of "suspend" straight from the docs:

At any point, a function may suspend itself. This causes control flow to return to the callsite (in the case of the first suspension), or resumer (in the case of subsequent suspensions).

That description isn't quite right though. Control flow returns up the call-stack to the most recently executed async-aware bit of code. In particular, that'll either be the most recent _async_ callsite or whoever last resumed this function. It's precisely those semantics which enable one to write a nice event loop API, but the docs tell you something different.

Saying that aloud, I should probably just file a PR and fix that. Off to $WORK soon, but that sounds like a good this-evening problem if nobody grabs it first.

sph3• 4 years ago

This inline else example makes sense when you stop and think what it is doing, but it is in no way intuitive.

Taken at face value, why is it switching on self with no case whatsoever? Why does the else case need to be inlined? This is trying to be smarter than it needs to be.

Meh, not a fan.

attrutt• 4 years ago

The fact that you ask why it needs to be inlined means you haven't understood how the feature works. If you did, you'd be a fan. It's a general mechansim that fits Zig perfectly, along with inline for and while.

audunw2• 4 years ago

The 'inline switch else' seems easy, no? "inline switch" should be self-explanatory. It expands at compile time like inline for loops or inline functions. It is somewhat unique that the switch case gives you a reference to what you matched with |x|, but isn't it essentially just shorthand for self.x? And that |x| is necessary when you want to do self.x.talk() where you don't know x

I can agree that async/await is tricky to understand properly. I managed to use it to write some nice code for a demo of a Verilog simulator, but it took a few tries to get it right, because async/await/suspend/resume definitely isn't intuitive to start with. Once you understand it the rules are quite simple though. I'm sure a well written tutorial could make most people understand it.

And it depends what you're trying to do. Using suspend and resume correctly can be hard. But most of the time that will be done by people writing libraries, and when you have an async aware library and an event loop, using just async and await isn't that hard.

Zig is a new language that isn't really finished. Documentation is sparse and they're still making breaking changes. To me, Zig is a very simple and concise language, much simpler than C in many ways (we're just used to C's quirkiness), and I'm sure when it's stable and there's better documentation and tutorials it'll be easy for most people to get a thorough understanding of it quickly.

anonymoushn7• 4 years ago

but isn't it essentially just shorthand for self.x

At least in the `else` prong of the switch, if you want to do anything with the value you have to capture it, because `self` will be the union type, not the particular type within the union.

I've previously asked about whether this could be done away with, like if you write `if (x != null)`, could that create a scope in which x refers to the non-null value in rvalue-ish contexts but to the nullable value if you want to set it to null? Some compilers like Sorbet do this and call the feature "type narrowing." It seems like it is a bit too magical to make it into Zig though.

davidkunz• 4 years ago

The problem here is that all variants (Cat, Dog, Snake) have to be known when defining the interface (Animal). That makes it not extensible. I prefer Rust's traits.

ephaeton3• 4 years ago

well, that's an innate feature of comptime expansion (or "macro" if you will) and as such this doesn't inhabit the same solution space as dynamic-dispatch interfaces. Benefit of this is it's boiling down to a statically known jump table and thus can be optimized accordingly, ideally boiling down to a direct inline in respective caller paths. The cost for this is whole-program compilation each time. It's a different trade-off, for sure.

mahkoh• 4 years ago

Rust traits do not require dynamic dispatch nor a jump table. Therefore rust traits are inherently faster than zig unions.

They can be used via dynamic dispatch but this is not the default.

randyrand• 4 years ago

Yes, it does seem like something the compiler should automatically define for you.

vegai_6• 4 years ago

If you had that reaction, you might want to take some time to explicitly free your thought process from OOP-isms.

If you have this reaction, perhaps you should take a humility lesson before claiming that a few syntax tricks is all it takes to outsmart people who spent their entire university careers thinking about these problems.

hsn9153• 4 years ago

Nah, OOP is bad. It's been a while since I met anyone, online or offline, who still takes OOP seriously.

vegai_6• 4 years ago

/s, right?

kristoff_it8• 4 years ago

before claiming that a few syntax tricks is all it takes to outsmart people who spent their entire university careers thinking about these problems

I don't think I have written anything of that sort. Thinking in OOP terms in, say, Java is great. Zig is not an OOP language though, and it cares about mapping nicely to CPU instructions more than it cares about mapping nicely to UML diagrams, so thinking in OOP terms in Zig is not that great, more often than not.

I've seen plenty of people coming into Zig expecting it to conform to their expectations towards object orientation or functional purity. Neither will be able to have a good time if they can't let go of their preconceptions.

vegai_6• 4 years ago

Sorry for misunderstanding the mood and context. In context of Zig, this makes a lot of sense, making my calls for humility premature and tad ironic.

matheusmoreira2• 4 years ago

People spend entire careers thinking about object-oriented programming?

vegai_6• 4 years ago

Heh. I'm sure they thought and worked on others things too, but many focused on it, yes.

revskill• 4 years ago

Not quite, people think in Inheritance instead.

pjmlp2• 4 years ago

https://www.sigplan.org/Conferences/OOPSLA/

anonymoushn7• 4 years ago

A lot of people have spent their entire industry careers dealing with these problems, and the result seems to be the sentiment you've encountered in this comment section.

kristoff_it8• 4 years ago

To give some context: this article is meant for people who program in Zig who might be interested in the new `inline else` switch case feature, and the metaprogramming it enables.

If you're looking for more general purpose interfaces (eg vtables) than what tagged unions can provide, then other material will be of more interest to you:

https://zig.news/david_vanderson/interfaces-in-zig-o1c

https://zig.news/david_vanderson/faster-interface-style-2b12

https://www.youtube.com/watch?v=AHc4x1uXBQE

weitzj2• 4 years ago

I have not touched zig, yet. But I hope they will use the duck typing approach how Golang does it, which makes it really nice to wrap APIs, mock APIs without explicitly mentioning an interface

weitzj2• 4 years ago

I guess it is the combination of duck typing + struct embedding + first class functions which let’s you adapt to an api or provide an api in a natural way without jumping through hoops

dist1ll• 4 years ago

Go's interfaces are an example of structural subtyping, not duck typing. The difference is that the structure a function expects is defined at compile time (i.e. in the function's signature) and not dependent of runtime usage of the passed in object.

dontlaugh2• 4 years ago

It's also quite frustrating in practice. It's often hard to understand that an error is actually lack of conformance to an interface (and why) and even worse, it's not uncommon to accidentally implement an interface you didn't intend to.

anonymoushn7• 4 years ago

I hope nothing is done similarly to golang, but you can do this by writing `anytype` which you may know as `auto`

sidlls• 4 years ago

I haven't touched zig, either, but I hope they don't go with structural typing. It leads to bloat: defining an interface explicitly to support unit testing, when stronger typing and appropriate use of fixtures and integration testing are much a much better approach.

rlaitila• 4 years ago

I think this article conflates interface and specification:

interface: describe required inputs in exchange for perceived outputs. No more, no less. Environmental concerns or invariants are the responsibility of the conformer. Interfaces communicate a boundary of incomplete information while allowing interoperability in face of incomplete information. Interfaces are explicitly inclusive.

specification: describe the exact inputs and exact outputs while describing all invariants. specifications communicate the exact conditions in which inputs/outputs can be exchanged and all possible (known) invariants. Specifications are explicitly exclusive.

Per the article:

  const Animal = union(enum){
     cat: Cat,
     dog: Dog,

Is a specification not an interface. At no point can I conform to this "interface" without the "interface" knowing of my existence. Animal must know about all possible invarients to operate correctly, such that it is a specification.

If I want to join two pieces of pipe together, the interface would be the inner diameter say 1". The specification of some use case would say only 1" inner diameter pipes can be joined with other 1" inner diameter pipes that have an outer-diameter of at minimum 1.25" due to "pressure constraints". If I choose a pipe that has the same inner diameter but different outer diameter, I've conformed the interface but failed the specification.

The rest of the article seems to try and affirm the interface argument by jumping into syntax and compilation arguments. I fail to see how this has anything to do with Zig or abstract ideas of interfaces.

anonymoushn7• 4 years ago

Sure, use vtables if you need vtables.

dontlaugh2• 4 years ago

You're right about the difference, but I very much doubt the term "specification" as you use it is common.

It's just a different approach to dealing with the expression problem using sum types.

kristoff_it8• 4 years ago

The rest of the article seems to try and affirm the interface argument by jumping into syntax and compilation arguments.

For the purpose of that post I'm loosely defining interfaces as "runtime polymorphism". The article "jumps" into syntax because that's what I'm trying to show, there really is no argument that I'm making about the abstract idea of an interface.

As stated at the top of the article (and in other comments here), if you want vtable style interfaces, you can have vtable style interfaces: just make a vtable and use it, the language won't stop you :^)

I fail to see how this has anything to do with Zig or abstract ideas of interfaces.

Yep, that's because the article was never about abstract ideas of interfaces. It does pertain Zig specifically because it shows off a new language feature: `inline else`.

encryptluks22• 4 years ago

I want to like Zig but after trying a couple programs it has a few annoying nuances. I believe you can't use tabs which is overly opinionated and the odd print requirement to use empty brackets is overly verbose.

frou_dh4• 4 years ago

Something I found eyebrow-raising is that the expected type of expression `x` in `if (x) { ... }` actually changes based on what syntax is used on an `else` line that comes later.

eatonphil• 4 years ago

I haven't seen that yet. Could you give an example?

stephc_int134• 4 years ago

And all the dots.

trgt• 4 years ago

Zig 0.10.0 allows tabs. I think 0.9.1 also allowed, but I'm not 100% sure.

encryptluks22• 4 years ago

When I use tabs I get "./fizzbuzz.zig:4:1: error: invalid character: '\t'"

pverghese• 4 years ago

I think any text editor can convert tabs to spaces. I've never had this issue for any number of languages

_trackno5• 4 years ago

Does anyone have a real-world example of where this is applied?

Nice to see a new feature that reduces boilerplate, buy I’d rather see a real case where it was useful rather than an artificial one

kristoff_it8• 4 years ago

Does anyone have a real-world example of where this is applied?

When you want to make an array of different structs that can be used in a homogeneous way. For example I made a Redis client library that has a bunch of commands implemented as structs (GET, SET, etc). You can't just put them into an array directly because each is its own type, but they all support being sent to Redis when passed to a client instance.

Putting those commands into a tagged union helps with the creation of things like interactive CLI clients.

stephc_int134• 4 years ago

The feature is nice.

The syntax is not.

Using "inline else" is both weird, confusing and incorrect.

It is allowed to create new keywords for new language features.

And please don't use special symbols, this should be kept to the strict minimum, in my opinion Zig is already using too many symbols.

The use of the static keyword in C/C++ is an example of something that should be avoided.

losvedir• 4 years ago

Aw, I get that this is just showing off use cases for the new inline else feature, but from the title I was hoping it had more to do with this issue[0]. Having only used Zig enough for an Advent of Code, interfaces via a mechanism akin to rust's traits is probably my highest wishlist feature.

If I understand the post here correctly, the version of interfaces shown affects the runtime data representation. And tagged unions have to be at least the size of the largest variant, sometimes plus the tag (right? Or is that just true in rust?).

Ideally, to me, an "interface" can be used as purely a compile time constraint. With rust traits, to use the example in the post, when you define a function that takes an "Animal", it will basically generate a version of the function that takes a Cat, and one that takes a Dog, and double checks that Cat and Dog both have `talk` implementations. So the tradeoff is you get static dispatch with no wasted space in the data representation, at a cost of more code generation.

Zig's comptime is powerful enough, that you can maybe even implement this version of traits in "userland" code, and that linked issue has some neat examples, though I think it would be better in the compiler itself so it can more easily be used throughout the ecosystem and so it interacts better with tooling (e.g. doc generation).

[0] https://github.com/ziglang/zig/issues/1268

kristoff_it8• 4 years ago

And tagged unions have to be at least the size of the largest variant, sometimes plus the tag (right? Or is that just true in rust?).

That's correct. If you have wildly different sizes, you can create a union of pointers. It will require you to manage the memory for the concrete implementation separately, but this way you will not waste space.

    const Foo = union(enum) {
       dog: *Dog,
       cat: *Cat,
       // ...
    };

> With rust traits, to use the example in the post, when you define a function that takes an "Animal", it will basically generate a version of the function that takes a Cat, and one that takes a Dog, and double checks that Cat and Dog both have `talk` implementations. So the tradeoff is you get static dispatch with no wasted space in the data representation, at a cost of more code generation.

Yes, that post is specifically about the need for dynamic dispatch, in Zig you can get monomorphization like so:

    fn makeAnimalTalk(animal: anytype) void {
       // optionally use some metaprogramming to validate `animal`
       // and produce a custom compile error when the trait is not 
       // fulfilled.

       animal.talk(); // will work on any type that can be used like that
    }

Easy Interfaces with Zig 0.10

Related Stories