undefined

points

[-]

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..

by ACCount374 hours ago|

prev|

[-]

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.

by cornstalks3 hours ago|

parent|

[-]

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?

by ACCount373 hours ago|

parent|

[-]

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?

by cornstalks2 hours ago|

parent|

[-]

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.