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

201–210 of 290 posts

Re: Problems of C, and how Zig addresses them

#201

Post by saagarjha »

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.

Sure there is: when I’m parsing or serializing something it’s pretty important I know what size something is.

Re: Problems of C, and how Zig addresses them

#202

Post by saagarjha »

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.

They’re better than implicit assumptions that int is 32 bits.

Re: Problems of C, and how Zig addresses them

#203

Post by saagarjha »

throwawaymaths wrote: post #184
naasking wrote: post #148

Earlier quoted context omitted.

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.

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

Your atomic increment may turn into a function call if it’s targeting multiple microarchitectures.

Re: Problems of C, and how Zig addresses them

#204

Post by saagarjha »

kristoff_it wrote: post #131
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?

> As far as I know, no one is using it in production after 7 years of development. - Uber uses Zig to produce hermetic builds of their backends and was able to move their C/C++ codebases to arm64 thanks to Zig's C/C++ cross-compilation support. https://www.uber.com/en-US/blog/bootstrapping-ubers-infrastr... - Bun is written in Zig and its sudden success was big enough to cause Deno to have an identity crisis. - Tiger…

Apple shipped a LLVM cross-compiler for Apple silicon on day one? Not entirely sure what you mean here.

Re: Problems of C, and how Zig addresses them

#205

Post by xeeeeeeeeeeenu »

Pannoniae wrote: post #188
lmm wrote: post #176

Earlier quoted context omitted.

The problem with C++ isn't too few features, it's too many.

Not just too many. But inconsistent ones, hard to use ones and badly designed ones. std::unordered_map anyone? The iterator-based APIs are just cumbersome and error-prone to use, etc... it's really easy to shoot yourself in the foot by forgetting to explicitly implement specific constructors, or by passing the wrong iterator (like begin() vs end()) to an STL template. The C# specification isn't significantly smaller…

> basic things are missing from it like a string startswith.

It was added in C++20: https://en.cppreference.com/w/cpp/string/basic_string/starts...

Re: Problems of C, and how Zig addresses them

#206

Post by WalterBright »

saagarjha wrote: post #201
WalterBright wrote: post #103

Earlier quoted context omitted.

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.

Sure there is: when I’m parsing or serializing something it’s pretty important I know what size something is.

The size of `byte` is fixed at 8, `short` 16, `int` 32, `long` 64. There is no ambiguity or uncertainty about it.

Re: Problems of C, and how Zig addresses them

#207

Post by Cloudef »

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.

What I'm really waiting for is zig support for custom range ints https://github.com/ziglang/zig/issues/3806

Also minor nitpick I have is that the interval/range syntax in zig is pretty confusing as it can be both inclusive and exclusive depending on context. Swift does it imo better by ... being inclusive and ..< exclusive

Re: Problems of C, and how Zig addresses them

#208

Post by avgcorrection »

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.

Eh the `ix`/`ux` is just as short and more descriptive. D just clings to C-like design to a fault sometimes.

> Besides, they're just easier to touch type.

These two styles are equally fine for touch typing… as long as you know how to touch type (not just how to touch type on the alphabet rows).

Re: Problems of C, and how Zig addresses them

#209

Post by bodge5000 »

ForkMeOnTinder wrote: post #19
bodge5000 wrote: post #13

Earlier quoted context omitted.

It was a little over a week ago now so my memory is a bit hazy, but I'll try to the best of my knowledge. Without getting into the weeds of why (happy to do so, just want to keep this readable), basically I needed to define and populate a hashmap in a new script and then import it into my main script, which to my mind left me with two options: * Define and initialise it at the same time (my preferred method) as a con…

Here's how you return a hashmap from a function: fn buildMap(allocator: std.mem.Allocator) !std.AutoHashMap(u64, u64) { var result = std.AutoHashMap(u64, u64).init(allocator); errdefer result.deinit(); try result.put(10, 100); try result.put(20, 200); return result; } Your #1 option should be possible once Zig has comptime allocators -- it's on the roadmap, but not possible yet iirc.

If I remember correctly I tried almost exactly that, I think it was just the bang operator I missed out (obviously essential in this case).

Cheers for letting me know though!

Re: Problems of C, and how Zig addresses them

#210

Post by bodge5000 »

hazebooth wrote: post #24
bodge5000 wrote: post #13

Earlier quoted context omitted.

It was a little over a week ago now so my memory is a bit hazy, but I'll try to the best of my knowledge. Without getting into the weeds of why (happy to do so, just want to keep this readable), basically I needed to define and populate a hashmap in a new script and then import it into my main script, which to my mind left me with two options: * Define and initialise it at the same time (my preferred method) as a con…

I think for the first point you wanted a block that evaluated to the map, unsure if that’s what you wanted though

I think so, if I write it out in pseudo code it might make more sense. What I was trying to do was pretty much:

    const mymap = {1: "hello", 2: "world"};
But the only thing I could find any answers for was something more like:

    const mymap; mymap.put(1, "hello"); mymap.put(2, "world");
Post reply on HN