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

Problems of C, and how Zig addresses them

avestura.dev

Post reply on HN
Print view View original

261–270 of 290 posts

Re: Problems of C, and how Zig addresses them

#261

Post by naasking »

SkiFire13 wrote: post #247
naasking wrote: post #225

Earlier quoted context omitted.

A few ways. The compiler could enforce commutativity, associativity and other properties of those operators. Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.

Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable. Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.

It's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators".

New types also don't have to inherit the properties of the operators they use.

In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.

Re: Problems of C, and how Zig addresses them

#262

Post by coliveira »

xigoi wrote: post #246
coliveira wrote: post #211

Earlier quoted context omitted.

History says otherwise: C was so successful it is still widely used.

Just because something is popular doesn't mean it's good. Tobacco smoking is also popular.

Some of the best software we have to date was written in C. If you like it or not, it is a magnificent tool.

Re: Problems of C, and how Zig addresses them

#263

Post by xigoi »

coliveira wrote: post #262
xigoi wrote: post #246

Earlier quoted context omitted.

Just because something is popular doesn't mean it's good. Tobacco smoking is also popular.

Some of the best software we have to date was written in C. If you like it or not, it is a magnificent tool.

It would still be good if it was written in a different language. Probably even better because the developers would have more time to improve the software instead of reinventing wheels, writing boilerplate code and chasing down segfaults.

Re: Problems of C, and how Zig addresses them

#264

Post by coliveira »

xigoi wrote: post #263
coliveira wrote: post #262

Earlier quoted context omitted.

Some of the best software we have to date was written in C. If you like it or not, it is a magnificent tool.

It would still be good if it was written in a different language. Probably even better because the developers would have more time to improve the software instead of reinventing wheels, writing boilerplate code and chasing down segfaults.

> It would still be good if it was written in a different language.

But it wasn't, C made all these software tools possible.

Re: Problems of C, and how Zig addresses them

#265

Post by dagmx »

psychoslave wrote: post #256
dagmx wrote: post #146

Earlier quoted context omitted.

Isn’t that a pretty clear, if terse, description of the problem? Use-after-free is a well known problem in the memory managed programming space and one that Zig infamously does not tackle. For those who aren’t familiar, it’s the use of a resource (a pointer) after it is no longer available for use (or has been freed). Which can in turn result in accidentally accessing unexpected data or crashing.

I never tried Zig, but can’t you, instead defer the actual resource release, replace it with one which crash at compile time? This is a naive suggestion based on lousy inferences of features that seems highlighted in Zig, comptime and deffer.

compile time may help for some stuff but if you’re passing pointers to a function, you don’t know what will happen there. You might get a use after free or a double free.

Like with all languages, if you’re leaving default safety up to programmer convention, the programmer will let you down eventually. Rust, swift and any language where raw pointers are the exception not the rule (any GC, ref counted or borrowing language really), they all switch the defaults around so that you’re not dealing with memory management yourself unless you absolutely want to.

Re: Problems of C, and how Zig addresses them

#266

Post by rixed »

vanderZwan wrote: post #239
rixed wrote: post #216

Earlier quoted context omitted.

The hash map I'm used to in C uses intrusive lists so it's pretty much allocation free. Would they fit the bill?

"Pretty much" is great in most contexts, but in this one I think GP is pretty darn strict about having absolutely zero dynamic allocations

By "pretty much", I meant that the bucket lists are already allocation free thanks to intrusive lists; of course the hash table itself can uses allocation when it's resized, or not, depending on user choice. It's trivial to preallocate it or use an arena or whatever, since it's just a flat array.

Re: Problems of C, and how Zig addresses them

#267

Post by sieabahlpark »

flohofwoe wrote: post #87
sieabahlpark wrote: post #84

Earlier quoted context omitted.

It sounds like you got some refactoring to use since you didn't namespace your own core types?

C doesn't have namespaces. The only sane way to deal with name collisions is either to use C stdlib types in library APIs (e.g. uint8_t), or use a library specific prefix (e.g. mylib_u8) - which is of course even more awkward than just using the standard uint8_t.

[dead]

Re: Problems of C, and how Zig addresses them

#268

Post by Cyberdog »

veber-alex wrote: post #161
Cyberdog wrote: post #121

Earlier quoted context omitted.

I can't answer you why Zig keeps showing up on HN (except for the surface-level answer that people keep submitting and upvoting it) but in terms of not being used in production, the Bun project, a Node/Deno alternative, is seeing a good deal of momentum by the people who like JavaScript a bit too much. It's probably the most widely used Zig project so far, including in production. https://bun.sh

Who uses bun in production? Seems totally insane to me to use a pre-1.0 application written in a pre-1.0 language in production considering Node and Deno basically do the same thing.

I'd argue that nowadays a pre-1.0 version number usually means "this doesn't have all the features I want it to have yet" more often than "this is buggy and shouldn't be used in production yet," at least nowadays. I can't speak for Bun but I know Zig has an extensive test and timing suite to help avoid bugs or significant slow-downs making it into new releases.

As for who's using Bun in production, I don't know. But it's been around for a while and seems to have decent buzz around it in the JS community when observed from a safe distance (the proper way to observe the JS community), so I assume someone is. Take that for what it's worth.

Re: Problems of C, and how Zig addresses them

#269

Post by Cyberdog »

lpapez wrote: post #179
veber-alex wrote: post #161

Earlier quoted context omitted.

Who uses bun in production? Seems totally insane to me to use a pre-1.0 application written in a pre-1.0 language in production considering Node and Deno basically do the same thing.

When the company you work for is burning VC money with no hope or intention of profitability, the only rational technology choice you can make as an engineer is to pick a promising but unproven technology which could boost your resume and help you land your next gig more easily. Or you simply pick it because you like and want to work with it and there is no one to stop you. I'd be very happy to hear I am wrong about…

> Or you simply pick it because you like and want to work with it and there is no one to stop you.

Is there a problem with this? If you have a problem to solve and nobody's telling you you have to use certain tools to solve it, why not try a new tool yourself and see if it solves it better than the old ones? I do this whenever I can on client projects and I've found some rather pleasant tools this way.

Post reply on HN