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

51–60 of 290 posts

Re: Problems of C, and how Zig addresses them

#51

Post by TwentyPosts »

matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

Minor differences in syntax are not what makes programming (in general, and when it comes to learning a new language) hard.

As an aside, I really like that I can grep source files for a keyword such as `fn ` and get a good idea of how many functions I am defining, and where they are. This gets especially powerful with multi-cursor editing.

Re: Problems of C, and how Zig addresses them

#52

Post by the__alchemist »

matklad wrote: post #28
bodge5000 wrote: post #7

I'm no expert on either languages, but I tried Zig for the first time properly the other day. I really liked it up until I hit hashmaps. One thing that I think goes under-appreciated about C (and other languages with a similar paradigm) is thats its pretty upfront and clear about what it can and can't do out of the box. If you want hashmaps in C, you need to create your own implementation, otherwise think of a way ro…

As counter point, the way that Zig implements hash maps is absolutely instrumental for TigerBeetle. Zig hashmaps _are_ quite a bit more cumbersome than, eg, in Rust --- you need to decided whether you want the allocator to be bundled with the hasmap, and its also up to the user of the hash map to provide equality and hash code (and, of course, there's manual defer instead of RAII). However, this flexibility and verbo…

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.

Re: Problems of C, and how Zig addresses them

#54

Post by IshKebab »

Joker_vD wrote: post #45
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…

> The operations C gives you map 1-to-1 with assembly int test(int x, int y) { return x % y; } test: // @test sdiv w8, w0, w1 msub w0, w8, w1, w0 ret Surprisingly, assembly doesn't have the remainder instruction, but instead it has a multiply-then-subtract instruction which is not corresponding 1-to-1 to anything in C.

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

Re: Problems of C, and how Zig addresses them

#55

Post by tialaramex »

matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

If you just keep C ideas you might almost just as well give up altogether.

C# actually only resembles C rather superficially, idiomatically there's a large gap and of course you should write idiomatic code, for example it's true you can write a C-style for loop in C#, but you almost never should, C# has a (not great, but it's something) for-each loop that's idiomatic.

C#'s primitive types look superficially like C types, but behave more like the modern sized types from a language like Rust. They're technically structures, albeit with a more convenient alias keyword. For example "long" is a signed 64-bit integer type, like i64, not some arbitrarily "maybe bigger than int" type as it is in C.

123.ToString() is a reasonable thing to write in C#, it means "Call the ToString method on this integer 123" much like Rust's 123.to_string() -- you can't do anything similar in C or even in C++

Re: Problems of C, and how Zig addresses them

#56

Post by jstimpfle »

square_usual wrote: post #27

You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.

May I suggest you give arguments why it is not (and why we should care about those arguments from a practical standpoint), and what language should better earn the title?

Re: Problems of C, and how Zig addresses them

#57

Post by throwawaymaths »

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…

Do you mean in zig? It's possible to do arbitrary, bounded computation (compiler quits if you expend "too many tokens") at comptime in zig, unless there is strange statefulness.

This is sensible since you want changes in, e.g. your code tree to taint compiled resources. If your code can go read from the filesystem in an untracked way, you break the incremental compilation model.

Re: Problems of C, and how Zig addresses them

#58

Post by matrix_overload »

Joker_vD wrote: post #47
matrix_overload wrote: post #43

It is nice and innovative, no doubt. But reinventing the syntax from scratch instead of introducing just the minimal amount of changes to the original C is a barrier that will deter 90% of possible adopters. The reason C# took off is that it's as close to C/C++ as possible. If there is a difference, it's due to a fundamental semantic change. E.g. it moved from painstakingly reinterpreting hundreds of small header fil…

Counterpoint: C itself invented lot of syntax compared to the contemporary ALGOLs and PL/I. Yet, it became immensely popular.

I would dare say, different combination of early adopters/pragmatists in your target audience. C/C++ these days is mostly legacy stuff, so if you want to cater to that audience, you deliver small incremental improvements.

Many people that could be bothered to learn Zig syntax, jumped ship to Python/Java/whatever already.

Re: Problems of C, and how Zig addresses them

#59

Post by matklad »

the__alchemist wrote: post #52
matklad wrote: post #28

Earlier quoted context omitted.

As counter point, the way that Zig implements hash maps is absolutely instrumental for TigerBeetle. Zig hashmaps _are_ quite a bit more cumbersome than, eg, in Rust --- you need to decided whether you want the allocator to be bundled with the hasmap, and its also up to the user of the hash map to provide equality and hash code (and, of course, there's manual defer instead of RAII). However, this flexibility and verbo…

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

Re: Problems of C, and how Zig addresses them

#60

Post by k__ »

tmtvl wrote: post #29
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 I believe is being discussed is that dereferencing a pointer after the memory it references is freed does not throw a warning at compile time. This means the programmer has to manually keep track of pointers, making sure not to free the relevant memory until there are no more references to it lingering about. While there are programming techniques which to lesser or greater extent prevent problems from oc…

So, Zig set out to solve all but the biggest issue with C?
Post reply on HN