badtuple · HackerTrans

الشهر الماضيdiscuss

Honestly, same. I spend most of my time on Lobste.rs, private blogs, and chat communities rather than HN for this reason. I check in every so often out of habit and can catch some business news here or there...but the joy, growth, and curiosity have moved to smaller bastions specifically to avoid the slop and its glorification.

badtuple

قبل شهرينdiscuss

I've worked with many people over the years. A bunch of product people have struck out to make their own thing now that they can get a feedback loop going. I just keep in touch with people. They know my services are available, so if they have a need they reach out.

The greatest asset in this type of work is genuinely liking people, being good at what you do, and keeping in touch. My email is easily findable for a reason.

badtuple

قبل شهرينdiscuss

I've already done a handful of these gigs for early vibecoded products that had collapsed in on themselves. The scope of work was to stabilize the product and only make existing features work.

The issues have all been structural, not local. It's easier to treat it like a rewrite using the original as a super detailed product spec. Working on the existing codebase works, but you have to aggressively modularize everything anyway to untangle it rather than attack it from the top down.

All of these projects have gone well, but I haven't run into a case where a feature they thought was implemented isn't possible. That will happen eventually.

It's honestly good, quick work as a contractor. But I do hope they invest in building expertise from that point rather than treating it like a stable base to continue vibecoding on.

badtuple

قبل 3 أشهرdiscuss

Interfaces can still be expressed using vtables. You just have to write the vtable yourself rather than have the language do it for you.

Also, Zig's tagged unions (enums with payloads in Rust) are really ergonomic and often what you want instead of interfaces. Alot of languages that use interfaces simply don't expose a good way of doing it so everyone reaches for interfaces by default. But if you don't need an actual interface then this way you don't even have to pay the cost of runtime dynamic dispatch.

badtuple

قبل 5 أشهرdiscuss

That is one theory of creativity. It is extremely far from proven.

badtuple

قبل 6 أشهرdiscuss

Does your opinion change if they use it to train a commercial program to do a similar task?

badtuple

قبل 7 أشهرdiscuss

Ideally you'll be working with the investors and leveraging their expertise and connections. If you're choosing an investor that you'll be working with for years, it's worth looking for things in addition to money.

badtuple

قبل 8 أشهرdiscuss

Something akin to interfaces, but weaker. Right now people roll their own vtables or similar, and that's fine...I actually don't expect these to be added. But because of Zig's commitment to "everything structural is a struct", a very very simple interface type would likely end up being used more like ML's modules.

The need for this jumped out at me during Writergate. People had alot of trouble understanding exactly how all the pieces fit together, and there was no good place to document that. The documentation (or the code people went to to understand it) was always on an implementation. Having an interface would have given Zig a place to hang the Reader/Writer documentation and allowed a quick way for people to understand the expectations it places on implementations without further complications.

For Zig, I don't even want it to automatically handle the vtable like other languages...I'm comfortable with the way people implement different kinds of dynamic dispatch now. All I want is a type-level construct that describes what fields/functions a struct has and nothing else. No effect on runtime data or automatic upcasting or anything. Just a way to say "if this looks like this, it can be considered this type."

I expect the argument is that it's unnecessary. Technically, it is. But Zig's biggest weakness compared to other languages is that all the abstractions have to be in the programmer's head rather than encoded in the program. This greatly hampers people's ability to jump into a new codebase and help themselves. IMO this is all that's needed to remedy that without complicating everything.

You can see how much organizational power this has by looking at the docs for Go's standard library. Ignore how Go's runtime does all the work for you...think more about how it helps make the _intent_ behind the code clear.

badtuple

قبل 8 أشهرdiscuss

I was also curious what direction the article was going to take. The showcase is cool, and the features you mentioned are cool. But for me, Zig is cool is because all the pieces simply fit together with essentially no redundancy or overloading. You learn the constructs and they just compose as you expect. There's one feature I'd personally like added, but there's nothing actually _missing_. Coding in it quickly felt like using a tool I'd used for years, and that's special.

Zig's big feature imo is just the relative absence of warts in the core language. I really don't know how to communicate that in an article. You kind of just have to build something in it.

comments