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

Why is Zig so cool?

nilostolte.github.io

Post reply on HN
Print view View original

471–480 of 527 posts

Re: Why is Zig so cool?

#471

Post by pjmlp »

Dylan16807 wrote: post #469
pjmlp wrote: post #351

Earlier quoted context omitted.

Most OSes use either hybrid kernels, or type 1 hypervisors, which are microkernels by another name.

If 10% of your OS code is in a small piece that might be called a microkernel, and 90% is in one huge blob that implements everything else, then you don't really have a microkernel OS. Or to phrase that more directly at the point: for monolithic kernels to be obsolete you have to break up the monolithic part, not just shim a microkernel hypervisor on top of it.

Depends on which OS, there are more than three out there.

Additionally there is a certain irony to use a monolithic Linux kernel, only to drown it on layers and layers of containers with Kubernetes.

Re: Why is Zig so cool?

#472

Post by pjmlp »

smj-edison wrote: post #409
pjmlp wrote: post #350

Earlier quoted context omitted.

Except Zig defaults could be found on the year of our Lord in 1976, 1978, 1983 and 1986. Exercise from other posts of mine which languages those might be.

I've been programming in rust for three years, until I picked up zig recently. I was also worried about memory safety when I started using it, but I've been pleasantly surprised how many safety features it has (it's certainly been easier to debug than the C code I've had to work with). Slices are often mentioned for safety, which they are great, but even better has been all of the casting functions. In Debug and Rele…

You could have achieved the same with Modula-2, which is the mapping to 1978 from those dates.

Re: Why is Zig so cool?

#473

Post by pjmlp »

brucehoult wrote: post #433
pjmlp wrote: post #348

Earlier quoted context omitted.

Ada has them, and I guess we all agree on its systems programming nature.

NOOOO! What Ada (and Rust) calls generics is very different -- it is like template functions in C++. In those languages the version of the function that is selected is based on the declared type of the arguments. In CLOS, Dylan, Julia the version of the function that is selected is based on the runtime type of the actual arguments. Here's an example in Dylan that you can't do in Ada / Rust / C++ / Java. define method…

You missed the way Ada does OOP, and went completely overboard talking about generics.

As you can see from my comment history, I am quite aware of CLOS, Lisp variants and Dylan.

Re: Why is Zig so cool?

#474

Post by pjmlp »

jb1991 wrote: post #461
pjmlp wrote: post #396

Earlier quoted context omitted.

So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

You can write Objective-C and C++ in the same source file, even mixing them in the same line of code, and it compiles together, but no one can say these are not two very different languages.

The name Objective-C++ exists for a reason.

Re: Why is Zig so cool?

#475

Post by pjmlp »

1718627440 wrote: post #435
pjmlp wrote: post #396

Earlier quoted context omitted.

So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

> So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. What do you mean? I don't think I can follow you. > yet the compiler language switches to use C extensions in C++ mode keep being used across many projects. When you use compiler extensions, that just happen to be both available in C and C++, I wouldn't say you are writing C in C++, I mean the extension is…

Only when removing everything that C++ adopts from C, other than low level implementation details that cannot be done in any other way.

That is what writing proper modern C++ is all about, anything else is writing C in C++.

Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style casts,....

Re: Why is Zig so cool?

#476

Post by pjmlp »

1718627440 wrote: post #437
pjmlp wrote: post #395

Earlier quoted context omitted.

Yet those complaining usually make use of plenty C constructs, data types and standard library on their C++ projects, instead of modern C++ practices.

"C-like" code in C++ still has C++ semantics. "modern C++" is a disputed paradigm, but not necessarily how things should be done. When you write C++, but not "modern C++", that doesn't mean you are writing C. There are also modern features in C. https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...

Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style casts,...

Re: Why is Zig so cool?

#477

Post by pjmlp »

materielle wrote: post #432
pjmlp wrote: post #209

Author is apparently unaware of alternatives like Ada, Object Pascal and Modula-2, where most of those "innovations" were already available. It is kind of interesting that packaging the same ideas with a C like syntax suddenly makes them "cool", 40 years later.

I’m actually not a huge Zig person. But yes, avoiding arcaneness for the sake of arcaneness will earn you more users. A big success of Rust has nothing to do with systems programming or the borrow checker. But just that it brings ML ideas to the masses without having to learn a completely new syntax and fight with idiosyncratic toolchains and design decisions.

Or it is another example of younger generations unaware of our computing history, celebrating something that they think is totally new.

Re: Why is Zig so cool?

#478

Post by jhgb »

WalterBright wrote: post #447
jhgb wrote: post #442

Earlier quoted context omitted.

I'm pretty sure the "comptime" keyword only forces you to provide an argument constant at compile time for that particular parameter. It doesn't trigger the compile time evaluation.

That's how the constant is provided - through compile time evaluation.

Yes, but compile-time evaluation in Zig doesn't require the "comptime" keyword. Only specific cases such as compile-time type computation do (but these specific cases are not provided by compile-time function evaluation in D anyway, so language choice wouldn't make a difference here).

Re: Why is Zig so cool?

#479

Post by smj-edison »

pjmlp wrote: post #472
smj-edison wrote: post #409

Earlier quoted context omitted.

I've been programming in rust for three years, until I picked up zig recently. I was also worried about memory safety when I started using it, but I've been pleasantly surprised how many safety features it has (it's certainly been easier to debug than the C code I've had to work with). Slices are often mentioned for safety, which they are great, but even better has been all of the casting functions. In Debug and Rele…

You could have achieved the same with Modula-2, which is the mapping to 1978 from those dates.

That's fair. I was born twenty years after Modula-2 was released, so I definitely have gaps in my language knowledge :D

Re: Why is Zig so cool?

#480

Post by smj-edison »

pyrolistical wrote: post #422
Panzerschrek wrote: post #303

Earlier quoted context omitted.

Destructors aren't just good. They are one of the most important innovations in programming, since they reduce boilerplate and prevent many bugs. Developing a language without them means introducing more bugs which could be avoided.

It violates one of zigs principle of no hidden control flow

Honestly, I don't know if I'd argue on grounds of no hidden control flow, but rather on grounds of fine-grained deinitialization. If I allocate a bunch of data structures in an arena, I don't want their destructors to be run, because I'm managing the memory a different way now. I suppose in Rust you could use `Box::leak` to prevent a destructor from running, but that's not exactly ergonomic (plus iirc you can't free a 'static reference safely). Especially if you've needed to tamper with a data structure's internals, you can't use the normal deinit functions.
Post reply on HN