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

Zig: software should be perfect [video]

youtube.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Zig: software should be perfect [video]

#111

Post by gameswithgo »

Ace17 wrote: post #88
AndyKelley wrote: post #24

Earlier quoted context omitted.

I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nestin…

> the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. That's the whole point of exceptions.

there are a lot of points in language design that people don't all agree on, or that might be appropriate for one kind of work and not for another.

Re: Zig: software should be perfect [video]

#112

Post by gameswithgo »

electrograv wrote: post #73
Jach wrote: post #60

Earlier quoted context omitted.

There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will hav…

Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility…

> the compiler will statically guarantee the impossibility of null dereference exceptions,

almost every language that gets rid of nulls with something like the Option type will let you still bypass it and get a null reference exception. Rust lets you unwrap, F# lets you bypass it. You could at least enforce a lint that doesn't allow the bypasses in projects where that is desired though.

Re: Zig: software should be perfect [video]

#113

Post by gameswithgo »

Jach wrote: post #80
electrograv wrote: post #73

Earlier quoted context omitted.

Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility…

Null isn't that bad -- or rather, the concept of a missing value. Certain languages handle null better than others, but even then, it seems like the more costly mistake has been the accumulation of made-up data to satisfy non-null requirements.[0] More costly for non-programmers who have to deal with the programmers' lazy insistence that not knowing a value for some data in their system is forbidden, anyway. In any c…

It doesn't seem like you are familiar with how option types get rid of null. You don't have to make up data to satisfy things not being null. You set them none, and the language either forces, or encourages usually, you to always check if the option is none or some.

Re: Zig: software should be perfect [video]

#114

Post by gameswithgo »

skrebbel wrote: post #90
muthdra wrote: post #75

Earlier quoted context omitted.

I'm betting on Jai.

I hadn't heard of Jai yet, but wow! That's a lot of hype (and even tool support ) for something that doesn't work yet. At first glance, Zig vs Jai reminds me a lot of the Linux vs GNU Hurd thing (or a lot of other "worse is better" examples). A couple of geniuses locking themselves up telling the world "Just wait! It'll be awesome!" seldomly produces something that lasts.

>seldomly produces something that lasts.

of course, but sometimes it does.

Re: Zig: software should be perfect [video]

#115

Post by Jach »

gameswithgo wrote: post #113
Jach wrote: post #80

Earlier quoted context omitted.

Null isn't that bad -- or rather, the concept of a missing value. Certain languages handle null better than others, but even then, it seems like the more costly mistake has been the accumulation of made-up data to satisfy non-null requirements.[0] More costly for non-programmers who have to deal with the programmers' lazy insistence that not knowing a value for some data in their system is forbidden, anyway. In any c…

It doesn't seem like you are familiar with how option types get rid of null. You don't have to make up data to satisfy things not being null. You set them none, and the language either forces, or encourages usually, you to always check if the option is none or some.

I use Option in Java quite a bit because I'm real sick of NPEs and cascading null checks in all-or-nothing flows. I would have preferred Java starting with something like Kotlin's approach where T is T not T|nil. You and the sibling might be missing the point of the post I linked, I think. It can be convenient to have formal assistance via e.g. the type checker that a function taking a non-null String returns a non-null Person with a non-null FirstName and LastName. But in the zeal to be rid of null to make programmers' lives a bit easier, when faced with a name that doesn't compose into 2 parts, someone has to decide what to do about that and who needs to care down the line. You can make up data ("FNU" as in the blog), set a convention (empty string), throw an exception, or declare either the whole Person structure Optional or at least certain fields. If you use a dynamic late-binding language you may have other options. Whatever you do, it ought to be consistent or robustly handled where the references interact with your DB, your processing programs, and your data displays. Finally when these references escape your system, as lots of real world data does, they necessarily escape any static criteria you once had on them, thus it's important to consider those third party systems have to live with your choice. Null is a convenient choice, not something to be villified so casually.

Re: Zig: software should be perfect [video]

#116

Post by electrograv »

gameswithgo wrote: post #112
electrograv wrote: post #73

Earlier quoted context omitted.

Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility…

> the compiler will statically guarantee the impossibility of null dereference exceptions, almost every language that gets rid of nulls with something like the Option type will let you still bypass it and get a null reference exception. Rust lets you unwrap, F# lets you bypass it. You could at least enforce a lint that doesn't allow the bypasses in projects where that is desired though.

Yes, but there’s a big difference between the default member access operator crashing conditionally based on null-ness — vs — the same operator guaranteeing deterministic success (thanks to static type checks), with the option to circumvent those safe defaults if the programmer really wants to (in which case they usually must be very explicit about using this discouraged, unsafe behavior).

It may seem to be just semantics, but it’s really quite important that the default (and most concise) way in these languages to read optional values is to check if they’re null/None first in an if statement, after which you can call “object.method()” all you like. It’s important that you can’t just forget this check; it’s essential to using the content of the optional, unless you explicitly type something like “.unwrap()” — in which case there’s almost no chance the programmer won’t know and think about the possibility a crash. Take this in contrast to the chance of crash literally every time you type “->” or “.” in C++, for example.

Re: Zig: software should be perfect [video]

#117

Post by kungtotte »

coldtea wrote: post #109
kungtotte wrote: post #85

Earlier quoted context omitted.

Really? You're betting on the one language out of all the one's mentioned that you can't actually use yet?

Never underestimate the power of hype and marketing over rational assessment.

Yeah I guess. The only charitable thing I can think to say is that maybe they've tried all the others and found them lacking somehow (what language is perfect, after all?) and so they put their hopes to the one as yet untested.

It could, theoretically, be perfect. Since it's all theoretical at this point I mean.

Re: Zig: software should be perfect [video]

#118

Post by coldtea »

gameswithgo wrote: post #110
coldtea wrote: post #106

Earlier quoted context omitted.

Or just a compiler / IDE warning saying "X, and Y exceptions could be thrown here but are unhandled". Then it's "checked" but catching is optional.

Yeah there are a lot of interesting things you can do if you design languages around an editor. Like complete, recursive type inference, so you don't have to annotate types on function signatures, but the editor can display them, which is very useful, or showing what exception can be thrown even if the language doesn't make it explicit. This works out great when the editor is available on the platform you need and wo…

That's all very true, and it's sad that we haven't explored this space more.

It's a nice in-between something like a Smalltalk image-environment-IDE / Lisp Machine and a dumb IDE/editor that starts from source code and has to parse into AST into its own...

Re: Zig: software should be perfect [video]

#119

Post by imtringued »

gameswithgo wrote: post #112
electrograv wrote: post #73

Earlier quoted context omitted.

Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility…

> the compiler will statically guarantee the impossibility of null dereference exceptions, almost every language that gets rid of nulls with something like the Option type will let you still bypass it and get a null reference exception. Rust lets you unwrap, F# lets you bypass it. You could at least enforce a lint that doesn't allow the bypasses in projects where that is desired though.

Perfect is the enemy of good. By reducing the possibility of null dereference exceptions from 100% to 10% you have reduced the cognitive burden by 90%. Removing the bypass would result in a 100% reduction in cognitive burden, only 10% more than the second best solution. However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those 10% fall under. In those cases handling the error "correctly" is actually an additional cognitive burden that can ruin the meager 10% gain you have obtained by choosing the perfect solution.

Re: Zig: software should be perfect [video]

#120

Post by skrebbel »

gameswithgo wrote: post #114
skrebbel wrote: post #90

Earlier quoted context omitted.

I hadn't heard of Jai yet, but wow! That's a lot of hype (and even tool support ) for something that doesn't work yet. At first glance, Zig vs Jai reminds me a lot of the Linux vs GNU Hurd thing (or a lot of other "worse is better" examples). A couple of geniuses locking themselves up telling the world "Just wait! It'll be awesome!" seldomly produces something that lasts.

>seldomly produces something that lasts. of course, but sometimes it does.

True, but we're casting bets here :-)
Post reply on HN