Live data from Hacker News

Zig: software should be perfect [video]

youtube.com

101–110 of 141 posts

Re: Zig: software should be perfect [video]

#102

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.

> compiles and runs just fine. For fairly low values of those. Creating a null reference is UB, your program is not legal at all.

Sure, we're not supposed to do that. Sometimes it happens anyway, and the C++ compiler isn't much help in that case.

Re: Zig: software should be perfect [video]

#103

Earlier quoted context omitted.

Because your cpu has a base ISA, plus extensions. The compiler doesn't know if you're going to only run this binary on your machine, or distribute it to others that may share your base ISA but possibly not your extensions, so it takes the conservative approach and doesn't use them unless signaled to do so via those compiler flags. Also, I think -march implies -mtune.

In Zig the default target is native, which turns on all the applicable CPU features. If you want to target something other than the native machine you can use --target-os --target-arch parameters. I haven't exposed extra CPU options for cross compiling yet.

Do you consider the default architecture targetted by GCC (e.g. some old Intel) to be cross compiling? That is, can I make a binary that supports most x86 processors rather than just those with the particular extensions I support, with the current Zig compiler?

Re: Zig: software should be perfect [video]

#104
post #51

Earlier quoted context omitted.

It is entirely possible that even if Windows 10 was perfect software according to the "it gives you the correct output for every input in the input domain" definition, it would still not open the start menu every time you clicked on the icon.

Of course we can redefine bugs as features, but to present that as an argument is a “red herring”: I can assure you, the Windows 10 start menu is not i tended to fail or delay opening instantly upon click or system button press.

Why is that a red herring? Isn't it relevant that even if the software is perfect (according to the definition) it might not do what the user wants?

Re: Zig: software should be perfect [video]

#105

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…

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

That would indeed be ironic if that case was the only thing exception-based error handling entails. That is, if every program just let all exceptions go uncaught. Which is nowhere near why exception handling was invented, or how it's used in practice.

Re: Zig: software should be perfect [video]

#106
post #30

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. i.e. checked-exceptions?

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.

Re: Zig: software should be perfect [video]

#107
post #98

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.

>Your code invoked undefined behavior before you did anything with a reference

Since nobody stopped you, the problem is still there.

Re: Zig: software should be perfect [video]

#108

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.

> compiles and runs just fine. For fairly low values of those. Creating a null reference is UB, your program is not legal at all.

If the compiler still accepts it, then that it belongs to the "UB" class of code is not much comfort.

The whole point is to NOT have it be accepted.

Re: Zig: software should be perfect [video]

#109
post #75

Earlier quoted context omitted.

I'm betting on Jai.

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.

Re: Zig: software should be perfect [video]

#110
post #30

Earlier quoted context omitted.

> 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. i.e. checked-exceptions?

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

F# is a language this is a lot like this, and I've recently been unable to get the editor with these features working in Linux, and it makes it rather horrible. If you had to remote in to a server and use vim, it could be rather horrible, and so on.

If we can get something like the language server idea working, really well, on all platforms and supported by all editors, then designing languages around certain IDE assumptions would more often be a good idea I guess.

Post reply on HN