[ACCount37]

No, I get that, but Zig being low level is kind of why I don't get why it would be a good tinkering language?

When I want to tinker, I just want my logic to work, first of all. In 9 cases out of 10 that means going for high level. Even if the resulting code works with low level things like binary structures.

[andyferris]

Low-level programming gets a bad name because C has many footguns and the spec leaves much behavior undefined - a fact that implementers use almost adversarially (which I'd support, if the goal was to refine the spec...).

C++ adds more high-level conveniences without actually removing the footguns and undefined behavior (much C code compiles in a C++ compiler).

Zig tries to keep the low-level C philosophy but have things more well factored and well defined. The result is you _can_ tinker in high-level code, yet "drop down" into low-level code as you desire.

(Compared to rust, you get fewer compiler-enforced guarantees, but unlike C the language isn't trying to make high-level code adversarial).

[jcul]

It made me laugh to think of C implementers being adversarial! It can feel that way.

I haven't really used modern C, not sure if it's evolved as much as modern C++, which I feel is a joy to use, and a lot safer. But then I've been writing C++ for decades.

I feel like C evolved from basically syntax sugar for assembly, so that's where all the footguns come from, rather than being actually adversarial.

[robinsonb5]

If some of the things that the C standard left undefined had instead been made implementation defined then the compiler would at least be obligated to do something that makes sense on the target architecture, rather than having license to take the lawful-evil route. (Plenty of architectures have addressable RAM at location zero, for instance.)

For some reason this always brings to mind that moment in Red Dwarf where Kryten, devoid of his behavioural chip, deems it appropriate to serve roast human to his crewmates. "If you eat chicken, obviously you'd eat your own species as well, otherwise you'd just be picking on the chickens!"

[uecker]

Both C and C++ compilers (in fact, they share this part) very aggressively exploited undefined behavior for performance. But I this was certainly not adversarial. Programmers also regularity picked optimizations over safety. I think nowadays the unsafety of C with modern tooling vs the safety of - say - Rust is very much exaggerated.

[pjmlp]

Basically what the world has lost by ignoring Modula-2 and Object Pascal, and going down the C path.

[archargelod]

The spirit of Pascal lives on in Nim.

It's arguably the closest modern language (with a sizeable community) to the Wirthian languages.

[jodrellblank]

There’s a spirit of Pascal in Odin, although not a sizeable community.

http://odin-lang.org/

[pjmlp]

I would add that Delphi still follows along, enough for an yearly conference in Germany, and that C# since getting Native AOT and the low level programming improvements, is close enough to Modula-3 design.

There is Swift as well, although quite far from Wirthian compile times.

[mcdonje]

You have a weirdly restrictive definition of "tinker"

[maccard]

Almost all of my tinkering is “download this thing, cache it (because it’s huge), run a program or a series of programs on it, and package the output up somewhere.” When I’m writing the thing that does the work I’m not tinkering any more..

[ACCount37]

Not really?

I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever.

Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor.

The tooling around embedded devices though? Python.

[cornstalks]

When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?

[ACCount37]

Most of the time "make something faster than anyone else has done" is just not worth doing? Good enough is good enough. Unless it's some super hot path and it's the speed that's the main goal, nothing else. Which is rarely the case.

If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?

[cornstalks]

No, I’m saying that it’s how I like to tinker. Others have their own ways of tinkering that are just as valid!

I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process.

I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.

[brabel]

Tinkering means different things to different people! Want to tinker with your hardware, as bare metal as possible? Or extract every inch of performance out of your CPU? Zig is great for that.

[pmarreck]

> I just want my logic to work

what the heck has convinced you that logic is somehow flawed in a new low-level language? LOLLL