41–50 of 141 posts
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.
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?
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'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…
Earlier quoted context omitted.
Rust's panics and their backtrackes are essentially the same as C++ exceptions.
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/
Looking at the source code https://docs.rs/crate/failure/0.1.3/source/src/backtrace/int..., "failure" uses https://docs.rs/backtrace/0.3.9/backtrace/struct.Backtrace.h... which is the callstack at a single point, not a trace of how an error was propagated.
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 lev…
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.
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…
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.
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).
I'm watching Zig and Jai closely. We need a better C and C++ isn't it. Good luck!
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.
Earlier quoted context omitted.
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.
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?