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

111–120 of 290 posts

Re: Problems of C, and how Zig addresses them

#111

Post by menaerus »

matklad wrote: post #59
the__alchemist wrote: post #52

Earlier quoted context omitted.

Not quite std, but Rust's heapless lib let's you use a statically-allocated Hashmap. The distinction is its max size is declared on construction.

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?

Re: Problems of C, and how Zig addresses them

#112

Post by andrewedstrom »

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?

Re: Problems of C, and how Zig addresses them

#113

Post by IshKebab »

messe wrote: post #101
IshKebab wrote: post #54

Earlier quoted context omitted.

x86 doesn't have remainder. Other instruction sets do. But yeah I agree with your point. Some targets might not even have multiply.

> x86 doesn't have remainder The code in the comment you replied to is 64-bit ARM assembly.

Oops of course.

Re: Problems of C, and how Zig addresses them

#114

Post by menaerus »

xigoi wrote: post #65
PhilipRoman wrote: post #34

Earlier quoted context omitted.

It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be. I can't name another language for which this is true. I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that…

In C, unlike pretty much every other language, you can't even know how big an integer is.

Sure you can, it's called sizeof(int). Now read the other comment to understand why.

Re: Problems of C, and how Zig addresses them

#115

Post by tialaramex »

WalterBright wrote: post #103
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.

D uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.

I think that trade off made more sense twenty years ago than it does today. So it's understandable that D did this, but doesn't make it a good choice for Zig.

Zig programmers don't need to keep talking about types, so the type (and thus in this case its size) is getting mentioned mostly when that matters, e.g. API boundaries.

Re: Problems of C, and how Zig addresses them

#116

Post by mtlynch »

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?

TigerBeetle is using Zig in production.[0] I imagine some of Zig's other corporate sponsors are using it as well.[1]

[0] https://tigerbeetle.com/

[1] https://ziglang.org/zsf/

Re: Problems of C, and how Zig addresses them

#117

Post by igor_akhmetov »

I really want to like Zig. Honest question: why is Zig so resistant to some kind of RAII? RAII is the biggest improvement that C++ brings over C. Leaving it out of a system programming language 50 years later is just strange? And no, manual defer is not the solution.

Re: Problems of C, and how Zig addresses them

#118

Post by pixelpoet »

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?

Andrew Kelley's intro[0] is probably the best talk I've ever seen, and his continuing leadership seems really great to me and worth supporting. Besides my reservations for its use in graphics programming (see my other comment) it looks very attractive in many practical ways (build system!! fuck CMake!) I could go from how I currently write my hobby code, sometimes a prototype for future commercial code.

[0] https://www.youtube.com/watch?v=Gv2I7qTux7g

Re: Problems of C, and how Zig addresses them

#119

Post by menaerus »

flohofwoe wrote: post #66
astrobe_ wrote: post #50

About macros and comptime: why is the compiler unable to detect that a function is a pure function, and if it is called with constants, the result can be computed ahead of time? At least in the simple cases such as the square example, which are I believe quite common, that would work. Maybe still add an annotation to make sure the compiler will do what the user expects, because humans are terrible compilers after all…

C/C++ compilers will do this when optimization is enabled (I guess the reason that's not done without optimization is to preserve "debuggability"). Notice how the add() function is completely 'disolved' into its result '5' here: https://www.godbolt.org/z/q98svvacW (the main difference to comptime is that this guarantees that the code is resolved at compile time, and if that's not possible you'll get an error). The bi…

Not only the work of the C/C++ optimizer but the exact reason why C++ constexpr was designed - to compute expressions during the compile-time iff all its dependants can be resolved during the compile time. If they don't it's still cool, they behave as a normal runtime function.

Re: Problems of C, and how Zig addresses them

#120

Post by quelsolaar »

steveklabnik wrote: post #91
quelsolaar wrote: post #88

Earlier quoted context omitted.

I know, and its very broken.

In what way? I haven't had the opportunity to try it out myself yet.

It is a feature that sounds like it promises to make something compile time but it doesn't. At the same time it has a bunch of limitations, that in no way reflects what modern compilers can do. Plenty of times you can write an expression and if you say its a constexpr, the compiler is forced to tell you that its not a valid constexper, but if you just remove the constexper qualifier, the compiler the compiler can solve the expression at compile time just fine. So using constexpr gives you:

-No guarantee that its computed at compile time. -Limits what the compiler lets you do when using the constexper keyword. -Adds no performance benefits or guarantees. -Makes your code not portable to most C compilers.

On top of this it adds implementation burden for compiler, and complicates the specification significantly.

Post reply on HN