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

141–150 of 290 posts

Re: Problems of C, and how Zig addresses them

#141

Post by syntheweave »

pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

As a comptime macro, yes, you should be able to slot in a DSL for all your vector math and essentially "pass in a string, get the function calls back". It would not be that hard, if you're up on your parser-writing skills, and definitely much cleaner than any C-style equivalent.

Re: Problems of C, and how Zig addresses them

#142

Post by dralley »

andikleen2 wrote: post #126
travisgriggs wrote: post #18

Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.

Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.

Just because your code compiles on a new platform doesn't mean the prior assumptions of the prior behavior of the types remains valid.

Re: Problems of C, and how Zig addresses them

#143

Post by Ygg2 »

andrewedstrom wrote: post #112

I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?

HN needs a way to counteract all Rust hype.

Re: Problems of C, and how Zig addresses them

#144

Post by matklad »

menaerus wrote: post #111
matklad wrote: post #59

Earlier quoted context omitted.

That's not quite it: with heapless, memory is fully static, the size of hash map is a compile-time parameter, which is a part of HashMap's type. In Zig, the map could be initialized and sized at runtime, but you still can enforce, statically, that it doesn't do any allocations after that. In both nightly Rust and Zig, heapless version can be expressed by passing a fixed-buffer-backed allocator to the standard hash ma…

I don't quite understand how do you change the size of a zig hashmap in runtime by, for example, inserting 1M items at some point but at the same time being able to enforce in compile-time that such operation will not result with dynamic allocation?

Compare these two methods:

https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c...

https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c...

One of them requires passing an allocator (and can allocate), the other doesn’t have an allocator argument (and thus can’t allocate). If you only pass allocator to `init` method of your application, and don’t store it anywhere, only init will be able to call allocating methods, the rest of the app will be allocation free, by construction.

Re: Problems of C, and how Zig addresses them

#145

Post by renox »

pjmlp wrote: post #129
gorjusborg wrote: post #15

Earlier quoted context omitted.

Rather than offer drive-by criticism, perhaps you could illustrate 'the problem' you are suggesting is being hidden?

The problem is that Zig is basically Modula-2 for C syntax lovers, plus metaprogramming. It is hardly safer than Modula-2 already was over C already in 1978. We are in 2023 now.

You're right, but it doesn't matter: Modula-2 didn't catch up, Zig has a small chance to succeed thanks to its focus on embedded and on its good tooling for cross-compilation.

Re: Problems of C, and how Zig addresses them

#146

Post by dagmx »

gorjusborg wrote: post #15
pjmlp wrote: post #6

Naturally it doesn't show how it tackles use-after-free cases.

Rather than offer drive-by criticism, perhaps you could illustrate 'the problem' you are suggesting is being hidden?

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.

Re: Problems of C, and how Zig addresses them

#147

Post by jacquesm »

pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

It would be nicer still if vectors and matrices were first class citizens. That way you can hide all of that stuff and it opens up across the board optimization routes that are otherwise much harder.

Re: Problems of C, and how Zig addresses them

#148

Post by naasking »

flohofwoe wrote: post #86
pixelpoet wrote: post #83

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-... ), plus maybe a similar @Matrix builtin up to 4x4.

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

Re: Problems of C, and how Zig addresses them

#149

Post by gpderetta »

IshKebab wrote: post #139
coliveira wrote: post #98

Earlier quoted context omitted.

Of course you can, but this is implementation defined. So you need to create code that does different things based on the underlying implementation. Every reasonably large C code base checks the current implementation to define what type of integers, pointers, etc. they're dealing with. This is by design, because C was created do deal with disparate processors and OSs. When it was crated it would be difficult and unw…

> When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes It was still a bad design. Of course this is in hindsight, but history has taught is it would have been much better if the default was for specific sized integers, with an option to use `uint_fast32_t` or whatever.

Then we would be stuck with 16 bits integers. We are lucky to be in a point in time where integer types have been stable for a while, but it wasn't always so.

Re: Problems of C, and how Zig addresses them

#150

Post by naasking »

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.

A prefix and a namespace aren't really that different in practice.
Post reply on HN