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

71–80 of 429 posts

Re: Zig, the Small Language

#71

Post by ironmagma »

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.

The most perfect code is no code at all. A language being small means it unlocks power without complexity. Smalltalk is a great example of this as it was rewritten over and over until it was tiny.

Of course, "no code at all" isn't useful, so there's a medium to be found.

Re: Zig, the Small Language

#72

Post by stephc_int13 »

Kukumber wrote: post #50
stephc_int13 wrote: post #29

Earlier quoted context omitted.

The thing about operator overloading is that it was abused during one of the worst era of C++. And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent o…

> I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable

Show me an example and I am pretty sure that I can rewrite it in a way that is neither ugly nor unreadable.

Re: Zig, the Small Language

#73

Post by com2kid »

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?

> hmmm but how much of a performance gain is there from say CPython or even Go?

It depends on what you are doing.

If your python code is mainly calling out to highly optimized math routines, well, not much.

If you are doing lots of computationally intensive work, quite a bit.

If your Python code does a lot of allocating of memory, throws around lots of large objects, or has to parse a lot of inputs, then moving to a native language can be very beneficial.

> 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?

Newer more powerful languages tend to result in more complex software being written. Ignoring CPU and memory limits, no one would have been capable of writing a modern AAA game with the tools available back in 1992.

Re: Zig, the Small Language

#74

Post by ptato »

Graziano_M wrote: post #67

// Arrays may contain a sentinel value at the end, here array.len == 4 and array[4] == 0. const array = [_:0]u8 {1, 2, 3, 4}; Small typo. Len should be 5, I believe.

It's really 4. It doesn't count the sentinel, just the elements. `@sizeOf([4:0]u8)` is 5 though.

Re: Zig, the Small Language

#75

Post by zahllos »

mbrubeck wrote: post #28
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 can be critical when targeting microcontrollers with RAM and storage measured in kilobytes rather than gigabytes.

Yes. For example the Arduino 328P ("Uno" boards) has 31.5k of program flash available to you, while the ATMega 2560 has 256k (minus again 0.5k for the bootloader). The STM32F411RE, a Cortex-M4, has 512k.

In embedded development you can forget the overhead due to binary formats such as ELF (while the toolchain might output these as an intermediate, what is flashed is just the relevant sections), but if you are doing things like loop unrolling all over the place, you're going to get less functionality for static program space.

This is why ARM and PowerPC have "embedded" variants of their ISAs. What this means in practice is a compressed form of their instruction representation. Why? If you have compressed instructions, you can fit more of them in program flash. So both Thumb and VLE are variable length encodings. Thumb, for example, can use 16 bits for many instructions, i.e. two bytes, whereas ARM by default would simply take four bytes for all instructions. (For the avoidance of confusion, they still "address" 32-bits of memory and are thus still 32-bit microcontrollers). PowerPC's VLE is similar.

The driver here is cost. You could put in more program memory (the address space has plenty of room) but that costs more money, and when you don't need it, why do it?

Re: Zig, the Small Language

#76

Post by synergy20 »

is zig still one man's work and has a hit-by-a-bus risk factor? checked it a few weeks ago for a few hours, looks good, but I don't feel I need switch from c to zig yet. will re-try after 1.0 is out.

Re: Zig, the Small Language

#77

Post by 1980phipsi »

WalterBright wrote: post #44
wyldfire wrote: post #14

Earlier quoted context omitted.

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

D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types. Not allowing the overloading of…

What about something like R's custom infix operators? R has %*% for matrix multiplication (and a few other built-in ones), but you can define your own %op%. It lets users know that potentially "here be dragons".

Re: Zig, the Small Language

#79

Post by stephc_int13 »

Kukumber wrote: post #50
stephc_int13 wrote: post #29

Earlier quoted context omitted.

The thing about operator overloading is that it was abused during one of the worst era of C++. And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent o…

> I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable

Matrix multiplication or even worse, matrix inversion, is NOT a basic operation.

This is exactly the point.

Re: Zig, the Small Language

#80

Post by goldenshale »

sakex wrote: post #43

I don't know Zig, but aren't we missing a return here? fn count_nonzero(a: []const i32) i32 { var count: i32 = 0; for (items) |value| { // "for" works only on arrays and slices, use >"while" for generic loops. if (value == 0) { continue; } count += 1; // there is no increment operator, but there are shortcuts for +=, \*=, >>= etc. } }

Also shouldn't the input argument a be named items instead? From what I can see items is an invalid variable as is.
Post reply on HN