Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm too dumb for Zig's new IO interface

openmymind.net

Post reply on HN
Print view View original

111–120 of 329 posts

Re: I'm too dumb for Zig's new IO interface

#111

Post by kelnos »

stop50 wrote: post #2

I have never understood libraries or imterfaces that want me to allocate buffers for their type. I can't parse them (no need for the lib then) or write to them (would probably break the exchange). The weird interface of go is probably due the fact that some interfaces can be used to extemd the writer like the hijacker interface (ResponseWriter.(http.Hijacker)) and the request object is used multiple times with differ…

> I have never understood libraries or imterfaces that want me to allocate buffers for their type.

That doesn't seem that odd to me. It's a trade off: more flexibility, but more manual work. Maybe I have a buffer that I've allocated that I'm not using anymore (say I have a buffer pool) and want to use it again. If the type allocates its own behind the scenes, I can't do that. Or maybe I'm working in an environment where I need to statically allocate all of my resources up-front, and can't allocate later.

The big downside is that if 90% of people are just going to allocate a buffer and pass it in, it sucks that 90% of people need to do more work and understand more minutiae when only 10% of the people actually need to. The holy grail is to give lots of flexibility, but make the simple/common case easy.

A simple improvement to this interface might be to allow the caller to pass a zero-length buffer (or Zig's version of null), and then the type will allocate its own buffer. Of course, there's still a documentation burden so people know they can do that. Another option could be to have second constructor function that takes no buffer arguments at all, which allocates the buffers and passes them to the fully-flexible constructor function.

Re: I'm too dumb for Zig's new IO interface

#112

Post by kelnos »

benreesman wrote: post #25
pjmlp wrote: post #18

Earlier quoted context omitted.

I mean those and other ones, we already have enough unsafe languages as it is. The age of C++ is going great, despite all its warts and unsafety, thanks to compiler frameworks like GCC and LLVM, games industry, GPGPU and Khronos APIs. Even if C++ loses everywhere else, it has enough industry mindshare to keep being relevant. Same applies to C, in the context of UNIX clones, POSIX, Khronos, embedded. Being like Modula…

Haskell makes guarantees. Modern C++ makes predictions to within a quantifiable epsilon. Rust makes false promises in practical situations. It invented a notion of safety that is neither well posed, nor particularly useful, nor compatible with ergonomic and efficient computing. It's speciality is marketing and we already know the bounding box on its impact or relevance. "Vibe coding" will be a more colorful and bette…

I hope in 100 years we're not using any of the languages available today. I do like Rust, and use it whenever it's appropriate, but it has its warts and sharp edges. Hopefully we'll come up with something better in the next century.

Re: I'm too dumb for Zig's new IO interface

#113

Post by simonask »

flohofwoe wrote: post #106
simonask wrote: post #100

Earlier quoted context omitted.

You put "just" in scare quotes, but that word does a lot of heavy lifting there. Static memory safety is an extremely useful thing, because it enables you to do things competent programmers would never dare in C, C++, or Zig. Things like borrowing data from one thread's stack in another thread, or returning anything but `std::string` from a function. These things were simply not feasible before without a huge bulky r…

> You put "just" in scare quotes ...I don't use them as "scare quotes", it's more like in "can't you just..." - e.g. something that looks simple from the outside but is hard to do / complex on the inside - e.g. I do recognize the work that went into Rust's memory safety, but I question the effort that went into it compared to more traditional memory safety methods, especially when looking at the restrictions that Rus…

I mean, there's no winning here. Either the language is too complex and does too many things, or it's not complex enough and relegates fundamental things to the standard library.

I don't thing there is any substantial difference between `Option` and `@Nullable Thing` or `Thing | null`, I don't think there's anything wrong with choosing `::` over `.` for namespace resolution (it means you can have local variables with the same name as a module), and you have to have some way to declare generic parameters.

Rust generally does not allocate behind your back, but custom allocators is a work in progress. The reason it takes time is precisely that they want to avoid the mistakes of C++. A couple of mistakes were already avoided - for example, async/await in Rust does not allocate behind your back, while C++ coroutines do.

Re: I'm too dumb for Zig's new IO interface

#114

Post by messe »

adwn wrote: post #110
kristoff_it wrote: post #99

Earlier quoted context omitted.

> The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around. Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it, and this ki…

> […] Zig was still using the bootstrap compiler written in C++ that would not free memory […] That sounds strange. Modern C++ requires very little manual memory management, at least when you're writing something high-level like a compiler. C++11 had been out for years when development on Zig started. Were they writing C++ old-school as C-with-classes and malloc() everywhere? Why not use a more appropriate language f…

IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

Re: I'm too dumb for Zig's new IO interface

#115

Post by simonask »

kristoff_it wrote: post #80
simonask wrote: post #45

Earlier quoted context omitted.

I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.

> I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. This has been not my experience at all in the ~6 years I've been writing Zig. I started having very little experience writing C (<1000, lines all written while in university) and since day 1 Zig has been a tremendous improvement over it, even back when it was at version 0.4.0.

Glad you're having a great time with it. :-)

I'm informed by having shipped a lot of C++ code in my time, which has taught me a lot about actually delivering stable software. Being better than C is a very low bar here.

Re: I'm too dumb for Zig's new IO interface

#116

Post by kelnos »

taminka wrote: post #96
simonask wrote: post #75

Earlier quoted context omitted.

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...

To me that's more an indictment of Diesel than of Rust. I've been using sea-orm for a project I'm working on, and my (generic) pagination function is a hell of a lot simpler and readable than that one.

Re: I'm too dumb for Zig's new IO interface

#117

Post by pjmlp »

kristoff_it wrote: post #104
pjmlp wrote: post #89

Earlier quoted context omitted.

Not only, the whole handmade movement puts me off. It is the anti-intelectualism from Go culture, gone wild against C++, Rust, Swift, anything modern, or even tools, using game engines versus doing the whole computer from scratch for a game.

Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software"…

Thanks for clarification.

Depends on the attitude, not using an engine, because one wants to learn the whole stack, makes all sense, after all people need to learn how to make game engines, if nothing else for the next generation.

Not using one out of spite, because we do everything handmade over here attitude, is a completely different matter.

Re: I'm too dumb for Zig's new IO interface

#118

Post by kstenerud »

ozgrakkurt wrote: post #12
8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust

> It is extremely difficult to write low level libraries in Rust

Really? I've not found it at all difficult to write low level libraries in Rust.

Re: I'm too dumb for Zig's new IO interface

#119

Post by kstenerud »

simonask wrote: post #75
sothatsit wrote: post #21

Earlier quoted context omitted.

I love Zig precisely because it is so similar to C. Honestly, if you don't like C, I can totally understand why you wouldn't like Zig. But I love C, and I love Zig. Zig has become my go-to for projects where I would previously have reached for C, largely because Zig has such good compatibility with other C projects. Rust, on the other hand, is a completely different beast. It is very different from C, and it is far m…

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

Quite right. I have 35 years of C under my belt. I can write it in my sleep.

But even so, I can't for the life of me write C code that's as safe as Rust. There are just too many ways to make subtle little mistakes here and there, incrementing a typed pointer by a sizeof by mistake thinking it's a uintptr_t, losing track of ownership and getting a use-after-free, messing up atomic access, mutex deadlocks oh my...

And that's with ALL warnings enabled in CLANG. It's even worse with the default warnings.

Re: I'm too dumb for Zig's new IO interface

#120

Post by Ygg2 »

simonask wrote: post #43
benreesman wrote: post #25

Earlier quoted context omitted.

Haskell makes guarantees. Modern C++ makes predictions to within a quantifiable epsilon. Rust makes false promises in practical situations. It invented a notion of safety that is neither well posed, nor particularly useful, nor compatible with ergonomic and efficient computing. It's speciality is marketing and we already know the bounding box on its impact or relevance. "Vibe coding" will be a more colorful and bette…

There is almost nothing accurate about this comment. "Makes predictions to within a quantifiable epsilon"? What in the world do you mean? The industry experience with C++ is that it is extremely difficult (i.e., expensive) to get right, and C++20 or newer does not change anything about that. Whatever "epsilon" you are talking about here surely has to be very large for a number bearing that sobriquet. As for the mindl…

To be fair to GP, an error bar of 3±300 is still a quantifiable epsilon. Utterly useless, but quantifiable.
Post reply on HN