Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failing to Learn Zig via Advent of Code

forrestthewoods.com

Post reply on HN
Print view View original

191–200 of 338 posts

Re: Failing to Learn Zig via Advent of Code

#191

Post by Comevius »

pjmlp wrote: post #185
Comevius wrote: post #183

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…

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.

Re: Failing to Learn Zig via Advent of Code

#192

Post by [deleted] »

pyrale wrote: post #123

The opinion that reimplementing AoC in two languages was not a good idea resonates a lot with my experience. Every year, I see people quitting their AoC run with frustration, because they don't measure their effort and try to complete each puzzle daily. The usual scenario is that, at some point, they block on a problem and spend longer than they should, or they can't solve the problem because they have some other thi…

[deleted]

Re: Failing to Learn Zig via Advent of Code

#193

Post by pphysch »

jhack wrote: post #99

I don't know how a language that sets itself up to be a better C turns into this monster of horrible syntax and patterns that's nothing like C at all.

Hey, it's unreleased so we can project our personal vision of "ideal C" onto it.

Then when those design choices get hardened into a 1.0 it will become just-another-language and we will inevitably feel let down and move into the next attempt at a Perfect Programming Language. So it goes.

Re: Failing to Learn Zig via Advent of Code

#194

Post by Jach »

defen wrote: post #153
cbdumas wrote: post #143

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.

I agree that with vector math, overloaded arithmetic operators are easier to read. However, I don't see how you could add "overloading, but only for actual math" - once it's in, people will repurpose it for all kinds of cursed purposes. The implementation would probably be ugly, but I wonder if it could be implemented by using a comptime string to represent the operation, e.g. something like: fn doMath(comptime op: […

There was a comment several days ago (https://news.ycombinator.com/item?id=29825516) that made me reconsider the whole enterprise of operator overloading even for math, specifically its last paragraph.

The gist is that you can easily build them to preclude useful optimizations and efficient execution, when it's often more desirable to be fast than to have syntactic sugar, hence having explicit function calls like multiply_add(a, b, c) instead of a+b*c. If you really want syntactic sugar when it comes to math, operator overloading probably isn't the way to implement it, it'd be nicer to have something with the full context so there can be optimizing reductions. Lisp macros can do that, or you might have some other kind of parser (that might have to work on strings), or with sufficient cleverness you could build an overloaded operator nest full of context-accumulating operations-to-perform that either require some doMath wrapper at the end or a final overload of operations producing a fully computed return type.

I prefer languages that don't cripple expressive freedom and so overall I'm not anti-operator-overloading in general even if I think some overloads are pretty questionable (I dislike C++'s arrow overload for Optionals) but I no longer think that e.g. a math-focused library is an obvious win or exception to the downsides of the expressive power granted from operator overloading.

Re: Failing to Learn Zig via Advent of Code

#195

Post by [deleted] »

pyrale wrote: post #123

The opinion that reimplementing AoC in two languages was not a good idea resonates a lot with my experience. Every year, I see people quitting their AoC run with frustration, because they don't measure their effort and try to complete each puzzle daily. The usual scenario is that, at some point, they block on a problem and spend longer than they should, or they can't solve the problem because they have some other thi…

[deleted]

Re: Failing to Learn Zig via Advent of Code

#196

Post by ayende »

pjmlp wrote: post #185
Comevius wrote: post #183

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…

Thing is, if Zig is C, why bother at all, we already have C for it.

Defer, comptime, far better cross file model, yo name just a few things

Re: Failing to Learn Zig via Advent of Code

#197

Post by tialaramex »

pjmlp wrote: post #130
tialaramex wrote: post #86

Earlier quoted context omitted.

I also would prefer not to have + as concatenate, and Linus feels strongly enough about it (and has enough influence) that Rust for the Linux kernel does not have Add and AddAssign overloaded on string types, among many concessions. However I think in general purpose programming we lost that battle when Java special-cased the operator. There's no overloading in Java, you can't have + do the Right Thing™ in Java for y…

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 ubiquitous. I can't prove that of course, it's purely my opinion.

Re: Failing to Learn Zig via Advent of Code

#198

Post by cbdumas »

defen wrote: post #153
cbdumas wrote: post #143

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.

I agree that with vector math, overloaded arithmetic operators are easier to read. However, I don't see how you could add "overloading, but only for actual math" - once it's in, people will repurpose it for all kinds of cursed purposes. The implementation would probably be ugly, but I wonder if it could be implemented by using a comptime string to represent the operation, e.g. something like: fn doMath(comptime op: […

I think vector math is a compelling example but it is far from the only one. Bignum arithmetic is probably just as common if not more so, in fact I see that Zig actually has a bignum library built in if I understand correctly. Using that library will be painful because of this choice. There are plenty of other such examples, imagine implementing (and then using) something like SymPy in Zig.

Re: Failing to Learn Zig via Advent of Code

#199

Post by FpUser »

stathibus wrote: post #88
iTokio wrote: post #26

Earlier quoted context omitted.

Reading the source code is very helpful if you are an experimented programmer that already grasped the basics of the language. It helps you to see what are the idioms, what does optimized production code look like. Compare C++ and Go std lib and it’s easy to constate the difference in language goals that they have.

Reading the c++ stdlib source code is never a good idea.

ROFL. Yup. When I look at application level codes those are nice. Looking at stdlib makes me want to walk away immediately.

Re: Failing to Learn Zig via Advent of Code

#200

Post by brandmeyer »

mst wrote: post #170
stephc_int13 wrote: post #60

I disagree from this part: "I also think it's partially wrong. No one in the history of the world has ever been confused or upset by a + b calling a function." It depends. If this is simple math on vectors I think it can be OK but it should probably be a built-in feature of the language as this is common, solved and we all implement it the same way (for short vectors at least) But the + operator has been abused in th…

The DSL I'm currently hacking around on has ++ for string (and list) concatenation and using a -seperate- operator seems to rather help. (I've yet to conclude if stealing ++ for this rather than preinc/postinc was a terrible mistake, so far in context it hasn't seemed to be but I'm still keeping an eye on the question)

Perl uses ~ for string concatenation.

Nothing says that you cannot use both infix "++" for concatenation and unary ++ for increment. "-" is both a unary prefix and binary infix operator, for example.

Post reply on HN