201–210 of 338 posts
Earlier quoted context omitted.
Thing is, if Zig is C, why bother at all, we already have C for it.
Zig is warts-free C, but you can use them together. You can gradually refactor your C codebase, Zig can even transpile C. Zig is also a standalone C toolchain, compiling and cross-compiling C is a breeze with it, and it has it's own libc implementation.
Earlier quoted context omitted.
Why Java given the history of programming languages between 1950 and 1996?
Influence. A completely amazing amount of Java was written (is being written) and there's a huge workforce in that language. I think that it's possible if say Gosling hated + concatenating and had provided Java with a different String concatenate (it clearly wants a concatenate operator, but it needn't be named +) we'd see that popularised and while some languages with overloading might overload + it wouldn't be ubiq…
Even BASIC uses it, and it was everywhere during the 15 years that preceded Java.
Let alone all the other languages since Jovial that can't be bothered to dig out just to prove my point.
To me the biggest difference between Rust and Zig in practical terms is that Zig does not offer statically safe resource management like Rust does, and as far as I know they have no intentions of doing so in the future because they think it’s less important than all this stuff about control flow. There are a lot of interesting ideas in the language but my disagreement with them on this issue is so fundamental that I…
There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write…
I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract.
> Zig is C, it's not meant to abstract away memory management.
This is just hiding the ball though. Why don't we want abstractions on memory management? There is no runtime cost to providing the abstraction that Rust does. As such, "machine-oriented" is an ambiguous description of the difference here. The whole lesson of Rust is that there's nothing fundamental about the abstractions the machine itself provides, and we can create better abstractions without losing our orientation to those concerns.
Anyone though that advent of code was unusually hard this year, especially at the start? Nothing unsolvable, but I usually do these with my SO and they got stuck on the second day, wherein we usually get to day 10 or so. Felt like it picked up way sooner.
It was often around the difficulty of the exponential problems, but most were okay if you're very familiar with grid data, hierarchy traversal and caching.
Earlier quoted context omitted.
Blog author here. I'm an Intel i7-8700k desktop. A few years old at this point, but quite beefy. Maybe this is a Windows issue? If I run "zig build" and then immediately run "zig build" again it still takes 3 seconds.
Sounds like something is messed up with your zig cache. I have a medium-size project (30 files, 10s of thousands of lines of code) that takes 0.07 seconds to `zig build` if nothing has changed. This is on a Mac.
Earlier quoted context omitted.
What did you think of the example in the article about vector math? Seems like that's an area where operator overloading actually makes the code more readable. Maybe it depends on the problem domain you're working in.
It’s a bit of a non-issue really. Once you’ve worked with the non-overloaded version for a while you quickly get used to it. The overloaded version is also superficially simple but loses information. For example, multiply versus multiplyScalar versus applyQuaternion on a vector which might all be represented by overloads of the multiply operator.
Earlier quoted context omitted.
> `a+b` will have the same value as `b+a` No, as IEEE754 doesn't even guarantee that `a + b` == `a + b`. You always need to compare the absolute difference of two values against an ε. So a == b |a - b| But for sensible comparison of floats, the addition is commutative.
> No, as IEEE754 doesn't even guarantee that `a + b` == `a + b` What? I'm pretty sure that is plain incorrect. Can you back that claim up with references?
Zig is a very low level language. I think the fancy type system can trip up people into thinking they are working with a high-level language. Zig is basically C with a fancy type system, so you should not expect things like special String types, overloading of index based access etc. I think the author was thinking that Zig was very close to Rust or C++, when in reality it is much closer to C. I had to keep reminding…
> Zig is basically C with a fancy type system, so you should not expect things like special String types, If I can't have nice strings, what should I be expecting from a fancy type system?
Earlier quoted context omitted.
There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write…
> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we wan…
This is technically true, but if I want to write a program that does not call malloc in its steady state, I can't use the stdlib or any library that uses the stdlib.