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

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

101–110 of 429 posts

Re: Zig, the Small Language

#101

Post by nulltype »

Kukumber wrote: post #7

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…

For operator overloading you can do something like this: https://github.com/christopher-hesse/tenet#interesting-featu...

You have to specify the names more times but you can also do any syntax you want.

Re: Zig, the Small Language

#102

Post by kllrnohj »

wyldfire wrote: post #14
Kukumber wrote: post #7

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.

Then no operators should exist at all. After all, adding 2 ints and adding 2 floats are drastically different runtime characteristics - performance and errors are completely different! Anarchy! Chaos! And let's not forget about all those architectures where the division operator is, gasp, a function call!

Also function overloads should never be allowed, either. After all, that's not explicit and the only thing that ever matters is being obsessively explicit for the sake of being explicit. How can I possibly tell what `min(a, b)` is going to do if function overloads or templates or macros exist?!? UNREADABLE!

I think at this point it's pretty well established that operator overloading is a net-good, and languages that don't have it end up with far more bugs than languages that do. Or they come up with arbitrary nonsense rules on why some types are allowed to have it but not your types you dirty filthy casual. Looking at you, Java, where the Integer class is allowed to overload operators but BigInteger isn't. Which, then again, is something Scala and Kotlin immediately completely reversed.

Re: Zig, the Small Language

#103

Post by flohofwoe »

jstrong wrote: post #16

why do people care about binary size? I have never understood this. Disk space isn't free but the size of the binaries on my machine doesn't seem like a big problem to me in that regard.

For regular PC programs stored on disc it may not be much of an issue, but think about scenarios like embedded programming, WebAssembly running in web pages, or 4K demo contests.

Also IMHO, statically linked programs simply shouldn't contain any code that will never be called, just out of principle.

Re: Zig, the Small Language

#104

Post by adamddev1 »

VyseofArcadia wrote: post #85
jayd16 wrote: post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

> If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. In my experience, languages with complex features still have complex libraries. Library complexity is a constant. If you simplify the language, at least you free up a little cognitive load there. In addition, simplifying t…

Like Smalltalk/Pharo, you have 6 keywords in the language and the syntax fits on a postcard. But all the classes/library/environment is huge and complex.

Re: Zig, the Small Language

#105

Post by linspace »

TakeBlaster16 wrote: post #4

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

Refusing to compile takes the position that the compiler knows more than the developers. Or maybe are the compiler writers thinking they are the ones that know more? Maybe I'm being biased because I could consider using it in my free time and I already have enough bondage at work

Re: Zig, the Small Language

#106

Post by alpaca128 »

TakeBlaster16 wrote: post #4

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

This also makes learning Zig frustrating for people who aren't yet used to this low-level programming style. I gave up after a couple hours because it felt like I wasted half the time commenting and uncommenting code to avoid this error. People will always find ways to circumvent safety measures anyway, warnings are just fine for the developers who care.

Re: Zig, the Small Language

#107

Post by P5fRxh5kUvp2th »

amelius wrote: post #94
10000truths wrote: post #46

Earlier quoted context omitted.

It's usually not the disk space that's the bottleneck, but rather, the CPU instruction cache. On modern Intel and AMD CPUs, the jump from L1 -> L2 alone can triple the latency of a memory fetch. For a "hello world" application, that doesn't really mater, but for, say, an OS kernel, it becomes really important to keep as much of your hot-path code in i-cache as possible.

It requires a special kind of programming. Maybe they should just release the benchmarks instead of saying "small". By the way, I wouldn't be surprised if Rust 2.0 will feature a typechecker that guarantees that everything fits in the L1 cache.

Given that the size of L1 cache can vary, I strongly doubt it. At best it can guarantee everything fits into a specific size, which may or may not be smaller than L1 cache.

Re: Zig, the Small Language

#108

Post by boywitharupee »

kuon wrote: post #40

I love zig but I have two pain points. Function naming convention as camelCase. I can overlook that and use snake_case in my code, which I do and people frown upon me. Second is inability to turn unused var check off.

For unused vars you can do this and the compiler will ignore it.

_ = my_unsed_var;

Re: Zig, the Small Language

#109

Post by flohofwoe »

purim wrote: post #6

why should I use Zig coming from Python/Go ?

It may be interesting for replacing C to write high performance Python extensions (in my experience, C and Python go very well together, and Zig should be able to replace C pretty well in such scenarios).

Re: Zig, the Small Language

#110

Post by ok123456 »

cercatrova wrote: post #100
ok123456 wrote: post #92

Earlier quoted context omitted.

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…

But the problems still remain? The borrow checker is an automated way of what one would normally check by hand, or in their mind. Removing it means that, just as one does in C, one must still check for memory errors and will more likely miss such errors more than the borrow checker does.

They have a build in arena allocator. That would cover a lot of manual frees. Also they have the defer syntax to defer your call to free.

The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures. There are many memory related CVE on common rust libraries.

Post reply on HN