←back to thread

200 points jorangreef | 10 comments | | HN request time: 0.722s | source | bottom
1. HourglassFR ◴[] No.24294015[source]
I've stumbled upon the Zig language a while back and have been checking in regularly to follow its progress. Recently I took the time to write a very small program to get a feeling for it. My thoughts :

- It's a very low level language. Having written mostly Python for the past few years, it is quite the contrast. I had to force myself to think in C to get the train going

- Getting my head around the error handling took more time than I'm willing to admit. In the end, it's like having exception but being more explicit about it. It feels nice when you get the hang of it

- The documentation of the standard library is severly lacking, to be fair the language is still very young. More worrysome, it feels very cluncky.

- No proper string support. It is sad that a modern language still goes down that route after Python has shown that correcting this is both definitely worthwhile and a word of pain.

- I have the feeling that optional and error union types are a bit redundant, but I have not written enough Zig to have a real intuition on that. Maybe it is just that I understand monads now.

replies(5): >>24294053 #>>24294562 #>>24295081 #>>24298209 #>>24300406 #
2. gameswithgo ◴[] No.24294053[source]
Regarding strings, nobody doubts that having good string support built into a high level language is a good idea, but with a low level language that has a lot of problems. Especially a language whose design principle is to avoid surprising allocations. So that is necessarily going to make things like concatenating strings more complex, and so on.
3. jeltz ◴[] No.24294562[source]
I would hardly use Python as an example of good string support. Of all languages I have worked with it has some of the worst. Look at Rust instead for a modern language with good string support.
replies(1): >>24297569 #
4. AnIdiotOnTheNet ◴[] No.24295081[source]
Standard library documentation is indeed clunky as it is auto-generated for the most part. This is something the community has been working on improving but it isn't a priority at this stage in part because the standard library undergoes breaking changes pretty frequently right now.

Optional and ErrorUnion are a tiny bit redundant in that one could represent the Optional as another value in an ErrorUnion, and that might even happen as an optimization step in the case of ?!/!? types at some point in the future, but they have very different handling in the language as they are used for very different things.

I personally like that Zig doesn't bother with "strings" at a language level at all and just considers everything as arrays of bytes. String handling is a complexity nightmare and I feel that Zig wisely chooses to be simple instead.

replies(1): >>24304652 #
5. earthboundkid ◴[] No.24297569[source]
I believe OP was saying that the Python 2 → 3 debacle shows it's important to get strings right the first time.
6. networkimprov ◴[] No.24298209[source]
Here is a proposal for cleaner error handling, using named catch blocks:

https://github.com/ziglang/zig/issues/5421

7. gautamcgoel ◴[] No.24300406[source]
Can you elaborate a bit more about what your found lacking in Zig strings?
replies(1): >>24304522 #
8. HourglassFR ◴[] No.24304522[source]
Well there are no strings, only byte arrays. Now that's fine if you only pass bytes around in a stream, but if wan't to do any computation it you have to assume an encoding and basically anything outside of straight ASCII will be a pain.

Now you may argue that this can be handled nicely in the standard library without changing the language. This is correct, but there will be some frictions with string litterals.

replies(1): >>24329746 #
9. HourglassFR ◴[] No.24304652[source]
> Standard library documentation is indeed clunky as it is auto-generated for the most part.

I have not expressed myself clearly: the auto-generated documentation is severly lacking. The API of the standard library is clunky. To be fair, both those points are getting better. And yes, the language is very young and I understand that there are more pressing issues with the core language itself.

> I personally like that Zig doesn't bother with "strings" at a language level at all and just considers everything as arrays of bytes. String handling is a complexity nightmare and I feel that Zig wisely chooses to be simple instead.

It is definitely simpler, alas not everything is ASCII and arguing it should be to make life easy for programers is hardly a reasonable stance.

Also, maybe it is not clear in my comments but I actually enjoy Zig.

10. LakeByTheWoods ◴[] No.24329746{3}[source]
What frictions do you anticipate? String literals in zig are utf8 encoded.