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 wrong, in order to not disclose some private information. You can log the error, but only if the network is available, and you can only log it to disk if the disk isn't full.
And then there are cases where you could try to explain the error to the user, but the reasons are very complicated and/or require intimate knowledge of the architecture to make sense, and/or require intimate subject knowledge to understand, or even obscure legal reasons.
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 nesting.
Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs.
Hey. Thanks for making Zig. I’m glad it’s moving forward.
Don’t let all the negative comments get you down. It happens to every language author. (See some of the nasty comments on Elm, Clojure, Go, Jai, etc.) I, for one, am happy that all of these languages exist, even those that don’t scratch my itches.
Completely agree — Zig and it’s design philosophy is absolutely fantastic for its domin, and I’m very glad it exists.
I like Rust and other modern languages too, but Zig strikes me as just about the best possible contender for a true C/C++ replacement (due to seamless interop, and a very practical and well designed simple language core — as opposed to the complexity of something like Rust, for example).
> 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 literally doesn't matter which of the thousands of functions up the call stack could have possibly triggered it. The only thing you need to know is the top-level network exception and where your network processing code starts. And if you can't handle a network error, it literally doesn't matter if one was triggered. The best you can do is abort and record a really good stack trace for that type of error.
> 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.
How do you handle those other errors though? If there is a disk I/O error, you're basically done. Permission errors, same thing. You report, abort, maybe retry.
You don't really need to know in the specific what kinds of errors can occur. If it's possible to recover from an exceptional situation, it's only useful to know if that situation is possible so you can avoid writing code you don't need to. But there wouldn't be any harm in writing an exception handler for an exception that can't happen except for that wasted effort.
Well it depends on what I'm doing and why the errors might be thrown right? Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? Whether I retry on network errors can depend on what the error is - if the end service is responding saying my call is invalid for certain reasons there can be a good case to just die immediately rather than slowly backing off trying repeatedly in vain.
The flip side of this is I shouldn't need to worry about exceptions that cannot be thrown. When you say all you need to know is what you can handle and where, that list must be a subset of the possible list of things that can be thrown. There's no point worrying about whether I should be retrying something due to network faults if it never uses the network to begin with.
I think of this way; there are broad categories of exceptions that you can handle and specific exceptions. But those exceptions are significantly smaller than the set of all possible exceptions my code (and the framework code) can trigger. I shouldn't have to worry about every possible exception, just ones I can handle. Checked exceptions/errors means you have to deal with the minutiae.
For your example if retrying network, I prefer to simply have a "ShouldRetry" property/interface on the exception itself since the triggering code has the best knowledge of how it should be handled. No need to know every possible network exception and sort them into retry or not retry.
> Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)?
My favorite error handling is when you can just put a single handler at the event-loop of a UI based project. On exception you just show them the message and continue running. The stack unwinding code ensures the application maintains correct state and that the operation is unwound. If the user clicked "save" and a failure occurred they get the message and can retry if they want.
This [1] article by Raymond Chen is one of my favorite on exceptions.
I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I find reasoning about exceptions significantly increases my cognitive load. Error handling is a place where a little more verbosity is okay because it keeps my focus on the local context rather than having to consider the entire call stack. I basically agree with the TL;DR of the article: "My point is that exceptions are too hard and I'm not smart enough to handle them".
That's the mistake with exceptions; if you assume every method can throw any kind of exception it actually reduces your cognitive load. Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions. Instead of infinite number of places an error can occur and the huge number of possible errors.
The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong.
> Now you just have to worry about what you can handle in the 2 or 3 places in your code you can actually handle exceptions
This is only true if your application has no state or invariants that could possibly be invalidated in the face of exceptions. For instance, what would be your solution to the 'NotifyIcon' example given in the linked article?
> The idea that error states are perfectly knowable everywhere in the code is a myth. Even if that were possible at one moment, the instant anyone changes code anywhere it will immediately be wrong
This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.
> For instance, what would be your solution to the 'NotifyIcon' example given in the linked article?
The notify icon code is poorly structured to begin with. Simply creating a NotifyIcon object adds it to the UI? That's an awful design. If there was an add to UI step then it would be a non-issue; the half-constructed NotifyIcon object would never get added to the UI. This issue is not magically resolved by having to explicitly handle every error; you can make the same mistake with twice as much code.
> This applies equally to both error codes and exceptions. If a method N layers down in your call stack changes its behavior, that's a potential breaking change regardless of your choice of error handling.
I'm not talking about changing behavior, I'm talking about changing implementation. Behavior is part of the contract. But being able to safely change implementation is the fundamental principle of abstraction and is the basis for polyphorphism. If a method today does a calculation using a database but tomorrow is refactored to use a webservice -- as long as the contract/behavior is unchanged -- then the rest of the code shouldn't have to know about it.
> 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.
Once you have checked exceptions, you're basically as verbose as the Error monad anyway. Except that instead of properly encoding it in the function result type, you have a separate mechanism, which is kinda sorta but not quite like a type. In Java, this manifests itself in things such as it being impossible to write a higher-order function that has a signature of "takes some function F, and can throw everything that F can throw, plus some E".
yep! there was a sort of epiphany for me, the first I wrote Java, from Python, when I realized that I can be sure that my code could handle anything the callee could throw at it.
There are still plenty of exceptions that are unchecked, i.e. subtypes of RuntimeException, which do not have to be declared on the callee. As well as people who think it's a good idea to throw instances of Exception and just tack a "throws Exception" on their methods.
Right — that's a failing of Java the language; not the concept of checked exceptions. At least one problem with Java's exception model that Zig does not have is that some exceptions are "unchecked."
The 'failing' of checked exceptions comes from essentially being forced to couple the type signatures of your methods' successful results with their error results. A more explicit way to do this is with Optional/Either types, and now you don't need the checked exceptions feature nor need to get people to remember to check for a global errno or some other data convention like an empty string / null. There's a lot of boilerplate though, just like with checked exceptions.
I prefer a more decoupled/late-binding approach to error handling; so far Common Lisp does it the best I've seen.[0] The key insight CL people had was that often in the face of an error, you need help from somewhere away from your local context to figure out how to resolve it, but then for many cases, you want to return back to where the error has occurred and take the resolution path with your local context. In other languages that automatically unwind the stack to the exception handler, it's too late.
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.
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...
I wasn’t actually thinking about panic, but the associated optional backtrace in Error types with Failure, for example: https://docs.rs/failure/0.1.3/failure/
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.
> 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.
>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.
I think it is safe to assume Zig fits into low level applications, staying closer to hardware, so competition should be with Go instead. SaaS could be out of the circle and often web based having less memory utilization.
I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks!
This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of some huge legacy language design mistakes most people agree on today (e.g. nullable-by-default pointer types, or no way to know at compile time or at a glance what range of exceptions a function may throw).
And of course, the “automatic” interoperability with C is an essential part of any C/C++ replacement contender.
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 have any impact when it can't even be used by anyone other than jblow yet. Even if it ships, I would bet its highest anywhere-realistic impact (which is still damn high) would be to become the PHP of game programming. The mythical C/C++ replacement that everyone will choose when they previously would have chosen C or C++, causing C/C++ to die like COBOL? Much less likely.
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 of null dereference exceptions, without negatively impacting performance or code style!
But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting.
It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin.
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 case I think the modern fashion of trying to eliminate null from PLs won't matter much in the effort to replace C, whereas something like a mandatory GC is an instant no-go (though Java at least was very successful at sparing the world a lot of C++). OTOH a language that makes more kinds of formal verification possible (beyond just type theory proofs) might one day replace C and have null-analysis as a subfeature too.
I think the author of that blog post fundamentally misunderstands the point: The damage of nullable pointers is not that they are nullable, but that compilers allow you to write code everywhere that assumes they’re not null (in fact, this is the only possible way to code, when the language cannot express the notion of a non-nullable reference!)
For example, most older languages with “the billion dollar mistake” have no complaint whatsoever when your write “object.method();” where it’s unknown at this scope whether “object” is null or not.
The fact that such code compiles is the billion dollar mistake; not the fact that the pointer is nullable.
I don’t care if you want to write nullable references everywhere, or whatever else you prefer or your application demands. That’s fine, so long as:
1. Non-nullable reference types must exist.
2. Nullable references types must exist as statically distinct from #1.
3. The compiler must not let you write code that assumes a nullable reference is not null, unless you check via a control flow statement first.
Now to take a step back, the principle behind this certainly applies beyond just nullability (if that was the point you were trying to make): Generally, dynamic, untyped invalidation states are dangerous/bad, while statically typed invalidation states are ideal. And yes, this does include bad states internal to a non-null reference, just as much as to a null reference.
Sum types are the key to being able to statically declare what range of values a function may return (or accept), and ensure at compile time that these different cases are all accounted for. If you aren’t aware of how elegantly sum types solve this, you should look into it — and I suspect it will be quickly clear why nullable references are useless, outdated, and harmful.
But at the very least, we’ve solved the pain of null dereference — and virtually without compromise. So, it’s irresponsible or ignorant IMO to create a new language that doesn’t include this solution in its core.
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.
> 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.
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.
> 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.
While I agree there are rare cases where .unwrap() is the right thing to do, I actually disagree here that it’s anywhere close to 10%: If you want to write a function that accepts only non-null values in Rust, you simply write it as such! In fact, this is the default, and no cognitive burden is necessary: non-nullable T is written simply as “T”. If you have an Option<T> and want to convert it into a T in Rust, you simply use “if let” or “match” control flow statements.
I actually think using .unwrap() in Rust anywhere but in test code or top-level error handling is almost always a mistake, with perhaps 0.001% of exceptions to this rule. I write code that never uses it, except those cases mentioned; while I’ve run into situations where I felt at first .unwrap() was appropriate, I took a step back to think of the bigger picture and so far always find safer solutions to yield a better overall design.
The cognitive burden from Rust comes not from this, but almost entirely from the borrow checker (a completely different toptic), and in some cases, arguably inferior “ergonomics” vs how Zig or Kotlin handle optionals.
For example, in some null-safe languages, you can write:
if (myObject) { myObject.mehod(); }
And the compiler will understand this is safe. Whereas, in Rust, you must write:
if let Some(x) = myObject { x.method(); }
This is not even to mention that Rust has no built-in shorthand for Option<T> (some languages write “T?” for example), but I understand why they chose not to build this into the language; rather, Option<T> in Rust is actually a component of the stranded library! In a way, that’s actually quite cool and certainly is by-design; however, it doesn’t change the fact that it’s slightly more verbose.
IMO it’s not a huge deal, but certainly Rust could benefit from some syntax sugar here at least. Either way, both examples here are safe and statically checked by the compiler.
Yeah I think unwrap is best used when experimenting/prototyping, but it can be very very useful there. Imagine trying to get started using Vulkan or Opengl without it. Big mess. But in production code you might want to lint it as a strong warning or error.
> 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.
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.
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.
The "null problem" is that a static language does a run-time check instead of a compile-time check. By the time the undefined behavior is invoked, compilation ended.
I was looking for a way to do metaprogramming, verified programming, LISP-like programming, and low-level programming. Past few years of searching led me to a lot of verification stuff obviously, PreScheme for low-level Lisp, ZL for Scheme/C, and Red/System for a REBOL-like answer. I was eyeballing Nim, too, since the masses usually hate LISP's syntax. Then, I thought a front-end that let one go with various syntax's, esp inspired by famous languages, with the same underlying semantics or just easy integration.
On a practical note, I noticed that strong integration with the dominant language with little to no performance hit is extremely important. Clojure building on Java in enterprise space is an example. It reuses it's ecosystem. For system space, I started recommending using C's data types and calling conventions where possible in new language so calling it would cost nothing. Then, maybe an option to extract to C for its compilers. So, whatever above languages are created need to integrate with C really well.
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.
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.
My hypothesis is that Zig's compiler passes the equivalent of -march=native to the backend, which is why it should also be given to the C compiler to give a fair comparison (and a speedup of 30% or so).
Much appreciated. Given Zig's design and use of LLVM, for code translated "line by line" (same algorithm) I don't see any reason for Zig's performance not to be substantially identical to C (compiled with Clang).
It wouldn't surprise me if there are reasons Zig can do better or makes it easier to use better algorithms, etc, but you wouldn't expect that to show up in something as computationally straightforward as a cryptographic primitive.
By the way, as a C practitioner, I'm a fan of what you're doing with Zig; keep it up! C++, Go, and Rust don't appeal to me for all of the reasons mentioned in your talk.
Compiling with -march=native makes for brittle binaries, since the binary might contain instructions that are not be available on slightly older CPUs or on virtual machines. So it's only suitable for software that's performance sensitive but won't be distributed to other machines (or at least won't be distributed outside of a strictly controlled environment). It wouldn't make for a good default.
When you are shipping binaries, you usually do not have control over the cpus your users are using. Setting march/mtune to native breaks if the developers machine is noticeably newer than the users machine. Also letting the build machine configuration decide which level of simd to target is too flakey, so most software specifies the target explicitly.
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?
Yes. You can pass the native OS and native arch as the cross compilation target, and produce a binary that runs on your machine and others that don't have the same extra CPU features.
You'd have to ask the compiler communities that. As an observer, I notice that C compilers are extremely conservative about changing defaults in new versions. And I could imagine some benefits of that approach, and downsides. But I am not involved in e.g. gcc or clang development.
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.
The definition of 'perfect software' used in the talk is 'it gives you the correct output for every input in the input domain'. To that end no funny business like hidden allocations or hidden control flow should happen behind your back, because an out of memory error or some exception your code does not deal with explicitly would not be a correct output according to that definition. Of course you do not need that level of control for most projects.
While I agree with the content of your post literally, I think we often underestimate the importance of software reliability and performance, and end up giving it less attention than it deserves.
I understand the place for rapid prototyping etc., and that not every software application deals with life-and-death situations — but even those that aren’t, I think our industry suffers a bit here. For example, to this day the Windows 10 start menu refuses to open sometimes (randomly) when I click on it, even multiple times. You could argue that this isn’t a huge deal, because within 30 seconds it usually “fixes itself” (or something like that), but it still doesn’t shake the overall feeling that we’re tolerating way too much shoddy software in 2018 than we should.
Or in terms of performance: I know not every application needs bare-to-the-metal speed, but something feels wrong with the world when my “supercomputer” (compared to a 1990s PC, for example) literally lags when I’m typing or scrolling in some apps, when a 1990s era PC could respond to essentially the same content interaction with almost zero latency.
Some few decades ago, we had far more klunkier programming languages, far slower hardware, and yet somehow yielded better tangible/functional results in some cases. Therefore, I’m very much in favor of anything that moves us towards higher quality software, and Zig (and Rust, and others) are all exciting examples of that.
In over 6 years working in this industry, in projects with anywhere from dozens of users to millions of users, not a single bug I have encountered was caused by a "hidden allocation" causing the process to go OOM. Not one instance.
One of the two examples he cited in his introduction, the Android one, wasn't even caused by an unhandled OOM error. Android by design will kill unused processes if they're occupying memory that the foreground process needs.
If we want software without bugs, removing hidden allocations in languages is far down in the priority list.
The vast majority of bugs aren't are due to corner cases that the programmer didn't think about. Quickcheck and related techniques expose many more bugs than eliminating OOM bugs.
Yes for most userland applications removing hidden allocations is not a concern, which is why for most general purpose programming languages this is way down the priority list.
Most languages make allocations behind your back so that your code can focus on the logic you actually care about since you could not do anything about running ot of memory anyways.
However there are projects where that level of control matters. For those projects C is currently still the default choice, even though it was designed more than 40 years ago. Some choices made back then might be huge liabilities for code we are writing now, because we still need that kind of language. A modern alternative to C could provide a huge value to all of us, mostly through more correct, secure and/or performant software.
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.
Zig has a bunch of runtime safety checking. It applies to divide by zero as well as integer overflow, using the wrong union field, and many more. The runtime safety checks are enabled in Debug and ReleaseSafe mode and disabled in ReleaseFast and ReleaseSmall mode. (Actually they are used as assertions to the optimizer so that it can rely on extra stuff being undefined behavior.)
Pointers can not be null. However you can have optional pointers which are guaranteed to use the 0x0 value as null and have the same size as normal pointers.
Trigraphs can readily be formed unintentionally, so having a warning when they change the meaning of the program seems valuable. There is a good reason they were removed entirely in C++17.
Many very bright people in the major sects of ML and Scheme tried to achieve perfection, and they have concluded, many times, that perfection implies a mostly-functional strongly (and, perhaps, even statically typed but with optional annotations only, like it is in Haskell) language, possibly with uniform pattern-matching, annotated laziness, and high-order channels, and select and receive in the language itself.
Such a language could be visualized as strict-by-default Haskell (with type-classes, uniform pattern-matching, minimalist syntax - everything, except monads) plus ideas from Erlang, Go and Ocaml.
Perfection and imperativeness, it seems, does not match.
Also, perfection and practicality do not match either, since imperative languages are the most practical for many applications. Pushing software toward perfection gives diminishing returns, and after some threshold, a company will have negative profit due to expensive development costs.
ML is very practical. The only reasons why it did not became popular (or has not been chosen as, say, the basis for Java) are social rather than technical and actually are insults to intelligence.
It is actually a nice informative video, but the title is as dumb as dumbness itself. Software should not be perfect. It should be useful. In places where perfection increases usefulness (s.a autopilot), go ahead make it perfect. In most cases, striving for "perfection" is a profound misallocation of resources.
However, I interpret the message from the video as "Let's make it really easy to achieve perfection".
In other words if we keep improving development tools and technologies, we may eventually be able to achieve perfection in each individual project nearly for free.
Upvoted since this is a useful comment and worth mentioning.
I'd expect some downvotes are based on negative reactions to this part of the comment: "the title is as dumb as dumbness itself." (Dear avip: if your comment said "the title is off-base" you would have made your point just as effectively and without the downvotes.)
I'll put it this way: "perfection" is too overloaded of a word to be particularly useful in this context.
I prefer to say it this way: I want software to adhere to a contract. That implies that we want people that use the software to understand that contract. To be more precise, I'd say that:
(1) a good contract defines the scope of correct behavior.
(2) a contract may (or may not) give some bounds (or constraints) about what happens outside of the scope of correct behavior
Yes, it gives the impression that the author thinks memory allocation errors are the only type of bug. Obviously there are thousands more, so it's kind of odd.
Some of these probably don't come to everyone's minds right away. Please share your favorites.
The behavior(s) that a particular language guarantees is a design question. Once those guarantees are specified, we can objectively evaluate a particular language in terms of how well it does according to its own standards.
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.
Oh come on, we already know that logical systems cannot even self reconcile it's own promises, as Gödel proved, now someone claim software should be perfect?!
Edit: the original title does not mention perfect.
Come on, a title like that isn’t meant to be taken too seriously.
And you’re reaching a bit far. You can write a perfect function that adds two 32 bit integers. There is a subset of code that can be written perfectly. Especially if you don’t need Turing completeness to write it.
Zig just tries it’s best to make it easy to write as much as possible of low level code in a perfect way.
> You can write a perfect function that adds two 32 bit integers.
how ? the problem of adding two 32 bits integers is itself imperfect since you may at some point have big integers to sum, so any solution is inherently flawed, too
The problem can be perfect depending on how it's stated. If you spell out the contract right, then it can be perfect. Some examples:
Given two 32-bit signed integers, produce a 32-bit signed integer that is a sum of the inputs; if the sum doesn't fit into 32 bits, wrap modulo 32 bits.
Given two 32-bit signed integers, produce a 64-bit signed integer that is a sum of the inputs.
Given two 32-bit signed integers, produce either a 32-bit signed integer that is a sum of the inputs if it fits into 32 bits, or an error code indicating that it did not fit.
The problem with languages like C is that they let you be imprecise and get away with in. If you just run with "add two signed 32-bit integers", and implement it as "x + y" in C, it will compile, and it will run, but the result is undefined behavior if it overflows (note: it doesn't even mean that you get the wrong value - it can literally do anything at all). In Zig, if you write it as "x + y", it will panic on overflow, which is at least well-defined and fails fast; and the language provides you with tools to implement any of the three properly defined scenarios above in straightforward ways (i.e. you can add with wraparound, or you can add with an overflow check).
> the problem of adding two 32 bits integers is itself imperfect since you may at some point have big integers to sum, so any solution is inherently flawed, too
Smalltalk solves that problem by promoting the result to arbitrary precision arithmetic. It does the same for integer division. For example, 5 / 2 returns a Fraction, not an Integer.
Yeah. Original title is “Zig: A programming language designed for robustness, optimality, and clarity – Andrew Kelley” and “Software should be perfect” is much more sensational.
If you look at the video, you'll see that "Software Should Be Perfect" is the title slide of the talk (you don't even have to click play, it's there at the start). And then the first words out of the speaker's mouth (other than a sound check) are "I'm going to try to convince all you that software should be perfect".
The "original title" you're referring to is what the person who uploaded the talk to youtube titled the talk, not what the speaker titled the talk.
Questioning if someone read the article or, in this case, watched the video is against the Hacker News guidelines. If you feel a commenter is not fully engaged with the topic you should decline to continue the thread.
Javascript (programming language) and Browser (runtime environment) is a perfect piece of combination.
With JS, you have many choices of implementation.
With Browser, runtime error doesn't crash user's device.
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 wrong, in order to not disclose some private information. You can log the error, but only if the network is available, and you can only log it to disk if the disk isn't full.
And then there are cases where you could try to explain the error to the user, but the reasons are very complicated and/or require intimate knowledge of the architecture to make sense, and/or require intimate subject knowledge to understand, or even obscure legal reasons.