Zig: software should be perfect [video] • Hacker News Board

Re: Zig: software should be perfect [video]

#91

Post by Mesopropithecus » Sun, Nov 11, 2018, 9:37 AM UTC

otabdeveloper2 wrote: post #86

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…

> 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. Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.

What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.

Re: Zig: software should be perfect [video]

#92

Post by IanCal » Sun, Nov 11, 2018, 9:48 AM UTC

wvenable wrote: post #79

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…

> It's too easy to call functions without being aware of the set of possible errors. But that's entirely fine! Programmers are far too obsessed with exactly which functions trigger which errors when it absolutely doesn't matter. All you need to know is what errors you can handle and where in the code you can handle them . If there is a network exception and can recover and retry it at the start of the operation, it l…

> All you need to know is what errors you can handle and where in the code you can handle them.

Surely also what errors can occur. Can the network using library throw disk IO errors? Permissions errors? Maybe it handles all the network errors internally to the library and I don't need to deal with those at all.

Re: Zig: software should be perfect [video]

#93

Post by c3534l » Sun, Nov 11, 2018, 10:17 AM UTC

tomp wrote: post #6

So... the perfect programming language has error-prone manual memory management and rampant undefined behaviour (well at least it can build the code to crash instead of “nasal deamons”)? Yeah right.

No one said the language was perfect. The language is to help you write perfect cod which was immediately defined at the start as code which does not produce errors on any valid inputs.

Re: Zig: software should be perfect [video]

#94

Post by black-tea » Sun, Nov 11, 2018, 11:25 AM UTC

Avamander wrote: post #35

loeg wrote: post #20

Re: performance claims, I wonder if the C sha256 implementation would have been more competitive with -march=native -mtune=native?

Why isn't `-march=native -mtune=native` enabled by-default for every piece of software compiled unless explicitly specified otherwise?

It is if you compile everything yourself on every system you use. Every Gentoo user does it (or at least, the equivalent of it using explicit flags in case they use distcc). But most people don't do that. They use software compiled by other people on very different machines.

Re: Zig: software should be perfect [video]

#95

Post by masklinn » Sun, Nov 11, 2018, 11:52 AM UTC

Mesopropithecus wrote: post #91

otabdeveloper2 wrote: post #86

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. Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.

What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.

> compiles and runs just fine.

For fairly low values of those. Creating a null reference is UB, your program is not legal at all.

Re: Zig: software should be perfect [video]

#96

Post by tinus_hn » Sun, Nov 11, 2018, 11:53 AM UTC

AndyKelley wrote: post #24

perlgeek wrote: post #19

There's a certain irony that the presenter quickly dismisses exception-based error handling, and then the first example handles an error by printing a message and exiting -- exactly what an unhandled exception does. This is more than a small piece of irony with a somewhat artificial example. Often, there simply isn't very much you can do with an error. In a SaaS world, you might not be able to tell the user what wron…

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…

Many languages have the possible exceptions as part of the function signature so you can't call a function without either handling, converting or passing any exceptions you may receive. It's a drag though.

Re: Zig: software should be perfect [video]

#97

Post by masklinn » Sun, Nov 11, 2018, 11:53 AM UTC

otabdeveloper2 wrote: post #86

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…

> 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. Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.

> Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.

That's useful, until you realise that all its smart pointers are semantically nullable (they can all be empty with the same result as a null raw pointer) and then nothing's actually fixed.

Re: Zig: software should be perfect [video]

#98

Post by ethan_g » Sun, Nov 11, 2018, 11:58 AM UTC

Mesopropithecus wrote: post #91

otabdeveloper2 wrote: post #86

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. Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.

What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.

No the gp is correct, references in c++ can't be null. Your code invoked undefined behavior before you did anything with a reference, namely *a which is a null pointer dereference.

Re: Zig: software should be perfect [video]

#99

Post by tomp » Sun, Nov 11, 2018, 12:17 PM UTC

c3534l wrote: post #93

tomp wrote: post #6

So... the perfect programming language has error-prone manual memory management and rampant undefined behaviour (well at least it can build the code to crash instead of “nasal deamons”)? Yeah right.

No one said the language was perfect. The language is to help you write perfect cod which was immediately defined at the start as code which does not produce errors on any valid inputs.

Isn’t that by definition? After all, if the code produces an error, then obviously the inputs weren’t valid...

Re: Zig: software should be perfect [video]

#100

Post by the_why_of_y » Sun, Nov 11, 2018, 12:39 PM UTC

ethan_g wrote: post #98

Mesopropithecus wrote: post #91

Earlier quoted context omitted.

What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.

No the gp is correct, references in c++ can't be null. Your code invoked undefined behavior before you did anything with a reference, namely *a which is a null pointer dereference.

> namely *a which is a null pointer dereference.

Which is a textbook example of the null reference problem.

Edit: There may be some terminological confusion here: when programming language folks talk about "references", they include in that definition what C/C++ call "pointers". See for example the Wikipedia article, which gives as the C++ example not C++ references, but C++ pointers.

https://en.wikipedia.org/wiki/Reference_(computer_science)