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

111–120 of 429 posts

Re: Zig, the Small Language

#111

Post by chriswarbo »

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.

Going from N features to N+1 features creates N! new interactions to consider.

For example, if we have a bunch of language features, and we decide to add a new one, e.g. exceptions, we now have to consider:

- How exceptions work

- How exceptions interact with threads; how exceptions interact with dynamic binding; how exceptions interact with dynamic binding in threads; how exceptions interact with mutable variables; how exceptions interact with mutable variables in threads; how exceptions interact with dynamically-bound mutable variables in threads; and so on.

Also, all of the language's tooling needs updating: compilers, linters, documentation generators, static analysers, formatters, syntax highlighters, auto-completers, etc.

Re: Zig, the Small Language

#112

Post by kllrnohj »

10000truths wrote: post #46
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.

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.

The binary size tells you ~nothing about how good it is at effectively utilizing L1 icache. In fact, optimizations regularly increase binary size because it turns out inlining to avoid function calls can be even more important. See also loop unrolling, SIMD paths, etc...

I'm more likely to believe Zig's "small binaries" are more from lack of optimizations than some obsessive focus on L1 icache density. Which, given it's not a 1.0 language, isn't something that can be held against Zig. But it'd hardly be a strength, either.

Re: Zig, the Small Language

#113

Post by bluGill »

linspace wrote: post #105
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

When the code is "done" then I want the compiler to apply those strict checks and refuse to compile because of such issues. Every issue raised above is something that has come back to bite me in some bug later when not fixed. However like the others, I often do make a change for test purposes that I just want to see if it changes (not to be confused with fix!) the current issue, once I understand the problem better and have the right fix I will go back and clean it up, but right now I don't care about those little details when the big picture is wrong. In particular I often write code with TDD, once the current code passes the existing tests I'm going to add more code and then I'll need the thing the compiler is complaining about.

Re: Zig, the Small Language

#114

Post by flohofwoe »

purim wrote: post #23
stephc_int13 wrote: post #18

Earlier quoted context omitted.

Fast code and fast compile time.

hmmm but how much of a performance gain is there from say CPython or even Go? The syntax of Zig appears to be quite user friendly but not sure if there are hidden pitfalls. I am excited for Zig but careful in adopting new languages but if this takes off, what sort of changes might we see? Cheaper C/C++ programmers?

It sounds like from your point of view, Zig, C, C++ and Rust are all pretty much interchangeable. I like Zig a lot, but don't expect that it will turn the world upside down. None of the new programming languages will make C, C++ or Rust more or less popular (not by a huge amount at least), they are just additional options to choose from. For instance C is alive and well at age 50, it will probably survive the next 50 years just fine (unless we switch to a completely different computing paradigm - but this would kill all other existing programming too).

Re: Zig, the Small Language

#115

Post by davidatbu »

ok123456 wrote: post #110
cercatrova wrote: post #100

Earlier quoted context omitted.

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.

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim.

For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).

Re: Zig, the Small Language

#117

Post by bluGill »

dangets wrote: post #56
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.

As the total number of ways to accomplish a task increases it puts more burden on a programmer to recognize the usage and understand the semantic differences between the options. How many ways are there to iterate over a collection in say C++? Libraries _can_ hide some of this, but then that might also be yet another function or operator that does the same thing. Internalizing when to use one method vs. another adds…

The number of ways to do something isn't the problem with C++, it is the number of inconsistent ways, some of which have big footguns. If the different ways were all consistent it would make it a lot easier to remember which was the right one to use in any particular context.

Re: Zig, the Small Language

#118

Post by steveklabnik »

TakeBlaster16 wrote: post #86
simlevesque wrote: post #61

Earlier quoted context omitted.

Eslint has `// eslint-disable-next-line no-unused-variables`, it is very useful. I'd prefer `eslint-expect-error-next-line` instead to warm me when the comment is actually useless but it's better than what Zig seem to do.

There's a nice eslint plugin for disable-line hygiene: https://www.npmjs.com/package/eslint-plugin-eslint-comments I do wish Rust had something like this too

https://play.rust-lang.org/?version=stable&mode=debug&editio...

You can put it at the top of your file with a #! too, if you want it to apply to the whole file.

Re: Zig, the Small Language

#119

Post by olodus »

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.

Yes THAT problem still exists. Zig does not try to solve that problem (currently). It tries to solve a lot of other problems with C. Using the ownership model is one way of solving memory problems. There are others. I've seen discussions that zig could have an ownership model at some point, or maybe it will have something other. To lock in on that the ownership model is the be-all-end-all of memory problem solutions is a bit much I would say. Don't get me wrong, the ownership model is a good one and I like that Rust is pushing the frontier in that area, but there is room for other system languages that take other approaches to its design and tries to solve other problems first.

Re: Zig, the Small Language

#120

Post by ok123456 »

davidatbu wrote: post #115
ok123456 wrote: post #110

Earlier quoted context omitted.

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.

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory
Post reply on HN