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

Zig 0.9.0

ziglang.org

Post reply on HN
Print view View original

101–110 of 250 posts

Re: Zig 0.9.0

#101

Post by xedrac »

jhgb wrote: post #96
jeremyjh wrote: post #91

Earlier quoted context omitted.

It seems strange to compare to C++ when it has none of the features that most define C++ like RAII, OOP & templates. Its not really "simplified" - its something totally different.

Presumably the idea is that lots of things that you basically have to use C++ for today because C alone is weak could be served by Zig instead, not that Zig and C++ are comparable languages.

I really like Zig, but the lack of RAII means we're back to malloc/free style programming, and I would never opt into that unless Rust could not be used (e.g. binary size too large). Having said that, it's way better than C and I hope it does well.

Re: Zig 0.9.0

#102

Post by lmm »

von_lohengramm wrote: post #92
turminal wrote: post #84

Earlier quoted context omitted.

> character slices Sorry, byte slices is what I had in mind. I'm not talking about language level string operations as in concatenation with + or something like that at all, because that certainly wouldn't make sense in language like Zig. I'm not advocating for string functionality in the language, I'm advocating for a way to not allow byte slice functionality on a thing that is clearly not a byte slice.

> a way to not allow byte slice functionality on a thing that is clearly not a byte slice This already exists in the form of structs or opaque types. Both of these approaches would end up being implemented in "userspace" anyways, whether that's standard library or third-party. However, (UTF-8) strings are byte slices. You can do simple manipulation with them as byte slices safely and validly. Split on spaces? Sure. T…

Doing find substring by find byte subsequence won't behave correctly in many cases, where semantically equivalent strings have multiple different bytesequence representation. Treating strings as byte slices exposes a lot of footguns; it shouldn't be easy just as e.g. treating floating-point numbers as byte sequences shouldn't be easy.

Re: Zig 0.9.0

#103

Post by AndyKelley »

pcwalton wrote: post #29
nauticacom wrote: post #23

Earlier quoted context omitted.

I've genuinely never understood this one, especially as a flat-out error instead of a warning. When could not using a variable ever be a bug?

That warning has caught bugs for me when I was copy and pasting code, or writing code on "autopilot". Usually it's pretty obvious mistakes though. Unused variable warnings are a good idea, but making them hard errors is a language design mistake. Warnings are good because they allow programmers to quickly make changes and test things, while providing a reminder to clean things up in the end (which is why the "just us…

Pretty bold to call it a language design mistake so confidently, when you have Rust users committing warning-emitting code to their source control.

Does Rust emit warnings for cached compilation units?

Re: Zig 0.9.0

#104

Post by a-priori »

rmanolis wrote: post #50

I love Zig. But unfortunately there are no use cases for web developers yet that Go and JavaScript does not do already … unless the webassembly replace JS for more cool and futuristic UI.

I say this as a web developer: there's far more to programming than the web.

Re: Zig 0.9.0

#106

Post by forrestthewoods »

Spex_guy wrote: post #57
spekcular wrote: post #2

Exciting stuff. How far away is Zig 1.0, roughly?

Hard to say, 1.0 for us comes when everything is fully stable in both the language and standard library, and we believe that it can last at least 20 years without modification. My estimate is at least 5 years from now, possibly more.

Will there be a Zig 0.10 release?

Re: Zig 0.9.0

#107

Post by squeek502 »

forrestthewoods wrote: post #106
Spex_guy wrote: post #57

Earlier quoted context omitted.

Hard to say, 1.0 for us comes when everything is fully stable in both the language and standard library, and we believe that it can last at least 20 years without modification. My estimate is at least 5 years from now, possibly more.

Will there be a Zig 0.10 release?

Yes: https://github.com/ziglang/zig/milestones

Re: Zig 0.9.0

#108

Post by fastball »

AndyKelley wrote: post #34
diegocg wrote: post #25

Earlier quoted context omitted.

They can put it on the standard library or the core language or wherever they want, but they absolutely need to provide good string handling. And regardless of where they put the code, this is something that needs to be done by the core team. Otherwise you will end with too many string libraries, all of them trying to solve a particular problem and doing bad at everything else, with bad documentation and different AP…

A lot of people reach for string handling when the actual correct thing to do is intentionally avoid string handling, and only handle strings as opaque encoded UTF-8 bytes, that cannot be reasoned about in terms of human language. I would even argue that having string handling in a standard library (or language) has the potential to cause a net increase in bugs, because of people thinking they are handling strings wh…

I don't think I've ever had a problem with Python3's string handling, which is very robust.

Re: Zig 0.9.0

#109

Post by jeremyjh »

xedrac wrote: post #101
jhgb wrote: post #96

Earlier quoted context omitted.

Presumably the idea is that lots of things that you basically have to use C++ for today because C alone is weak could be served by Zig instead, not that Zig and C++ are comparable languages.

I really like Zig, but the lack of RAII means we're back to malloc/free style programming, and I would never opt into that unless Rust could not be used (e.g. binary size too large). Having said that, it's way better than C and I hope it does well.

It is possible they will add a type level resource release obligation at some point. It would not be anything quite like the Rust borrow checker but I think would be a big help. https://github.com/ziglang/zig/issues/782

Re: Zig 0.9.0

#110

Post by turminal »

von_lohengramm wrote: post #92
turminal wrote: post #84

Earlier quoted context omitted.

> character slices Sorry, byte slices is what I had in mind. I'm not talking about language level string operations as in concatenation with + or something like that at all, because that certainly wouldn't make sense in language like Zig. I'm not advocating for string functionality in the language, I'm advocating for a way to not allow byte slice functionality on a thing that is clearly not a byte slice.

> a way to not allow byte slice functionality on a thing that is clearly not a byte slice This already exists in the form of structs or opaque types. Both of these approaches would end up being implemented in "userspace" anyways, whether that's standard library or third-party. However, (UTF-8) strings are byte slices. You can do simple manipulation with them as byte slices safely and validly. Split on spaces? Sure. T…

You are talking about what stringy things can be done with byte slices and I'm talking about all the byteslicy things that shouldn't be done with strings.

Like subslicing. And accessing individual bytes in it.

Post reply on HN