Another go at the Next Big Language
dave.cheney.net
Another go at the Next Big Language
1–10 of 125 posts
Re: Another go at the Next Big Language
#2My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that.
That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewhere other than the normal sequence (although you may still have some finallys), continuations are quite nice, and the Go/C model pollutes the code but puts the error handling right next to the error detection.
None of these really solve the problem though. How can I have the least amount of error handling code possible, how can I test it, and how can I be sure it is correct, and all while spending my mental efforts on the code that actually does useful things?
Re: Another go at the Next Big Language
#3My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewher…
The Erlang process model seems like the closest thing to a panacea here. It forces you to write robust software automatically. I haven't used that approach enough to know if it gets you the whole way to shipped, though.
(Note: Not specifically advocating Erlang The Language, just its approach to isolation and error recovery)
Re: Another go at the Next Big Language
#4[deleted]
Re: Another go at the Next Big Language
#5My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewher…
You don't want a language to force error handling on you. Error handling is different in every case. Go only tries to force you to deal with errors instead of allowing you to ignore them until an exception is thrown. There is never going to be an all-purpose error handling answer. Its just a matter of deciding where your error handling code is placed.
Re: Another go at the Next Big Language
#6I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it.
Then I tried to build something.
Java-like verbosity. Meh, I can deal with it.
[]byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal.
Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go, there was a bunch of extra stuff that just seemed like noise. Likewise for cypto, Base64, stringwriters, bunch of other stuff.
A bunch of little annoying stuff like that adds up. Eventually I just said fuck it. Maybe I'm not hardcore enough or something, but now I'm back with LuaJIT.
Goroutines are cool, tho. Lua's synchronous threads aren't quite the same. Also google's app engine datastore is sweet. Nice and simple, no screwing around with SQL. If I had to do systems stuff, I'd reach for Go.
LuaJIT is faster anyways.
Re: Another go at the Next Big Language
#7I was really excited about Go. Designed by some gurus, seemed to get everything right, google app engine supported it. Then I tried to build something. Java-like verbosity. Meh, I can deal with it. []byte and string aren't the same. Whatever, a few extra lines and thot cycles here and there, no big deal. Overly complex library functions. Let me explain this one. In Lua, markdown (discount) is a single function. In Go…
> LuaJIT is faster anyways.
This man speaks the truth. Well, actually, I know nothing about Lua. But I do know that Go currently isn't very fast. I mean, compared to highly dynamic languages the performance is fine. But compared to C++ or even modern JVM it's meh.
I feel like there's going to be improvement here, though, and I wouldn't be surprised if the versions of golang used internally at Google aren't faster.
My take has been to use it the way I imagine Google does. If I'm not building something that uses protobuffs and goroutines I do it in Python.
Re: Another go at the Next Big Language
#8My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewher…
The Erlang process model seems like the closest thing to a panacea here. It forces you to write robust software automatically. I haven't used that approach enough to know if it gets you the whole way to shipped, though. (Note: Not specifically advocating Erlang The Language, just its approach to isolation and error recovery)
Rust uses the Erlang model. Generally failing the task on error has worked well in practice, although there are times when we have to use result types and pattern matching (basically error codes, but more reliable since the compiler forces you to use them correctly). The vast majority of errors are handled either locally or by failing the task.
Re: Another go at the Next Big Language
#9My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewher…
My kingdom for someone who can figure out how to solve error handling.
You don’t really seem to want someone who can solve error handling. You seem to want someone who can make it disappear, or at least get as close as possible to that ideal. I feel your pain, but I fear you are asking the impossible. :-(
Some errors are recoverable, and maybe it would be helpful to have default policies like “if the file is read only, have the OS prompt the user to make it writeable and retry” to take care of a lot of the repetitive coding work in those cases. At least then we wouldn’t have to do things like writing a top-level file-handling operation in a loop that tries (in the exception handling sense) to do something, and if any recoverable error occurs, attempts a suitable recovery and goes back to try again. On the other hand, to have some sort of default policy, you’d need something in the semantics of your language to indicate which policies should apply and where. By that point, you might not be doing much better than a try-catch in a loop.
In the end, though, not all errors are recoverable, and that is the fundamental problem. Some errors are fatal, and you just can't carry on as normal or rely on some automatically generated default behaviour, because the semantics of your program are now broken. What would you want to see that you don’t have today in terms of minimising this kind of error handling code or making it easier to test?
I don’t know what kind of testing you have in mind, but one thing I’d really like to see going mainstream is a serious effect system built into the type system of the language. That would be useful for a lot of reasons, one of which might be checking that whatever error handling constructs were available didn’t do things like leaving effects half-applied, transactions open, or resources locked, in the event of a change of plan because of an error condition. I expect some relatively near-future languages will start to pay more attention to formal effect systems as fields like distributed systems, concurrency and security become ever more important in the programming mainstream. But this is a topic far bigger than just error handling...
Re: Another go at the Next Big Language
#10My kingdom for someone who can figure out how to solve error handling. My code consists of some reasonably straightforward sequence of actions with a random smattering of error handling significantly distracting from that. That error handling code is tedious to write, very time consuming to test (and often virtually impossible) and usually not run very often. Exceptions at least let you put the handling code somewher…
You and I sound like we may be cut from similar cloth. I find Go's approach to error handling -- which is to not to do much about the problem at all -- is better than pervasive use of exceptions but worse than some other possible mechanisms (and on this we may disagree).
Although I'm not saying the language Rust has got it right, perhaps some of the thoughts on the mailing list may be useful. However scarily, my mailing list post -- which only asks how to handle errors -- still ranks on top for "rust error handling" on Google:
https://mail.mozilla.org/pipermail/rust-dev/2012-March/00145...
Here I mention the Common Lisp condition system, which has been my favorite so far, but the one of the principal authors of Rust mention a somewhat similar but lighter weight alternative.