3 ms·

It's generally the sort of thing that would be written in C a few years ago, except C is a horrible language, and Go is the first semi-reasonable replacement. P

It's generally the sort of thing that would be written in C a few years ago, except C is a horrible language, and Go is the first semi-reasonable replacement. Personally, I dislike coding in Go (far too much of my code ends up being manual error checking), but Rust is on the horizon which might subsume a significant part of this space.

ossreality 12y ago
I'm fairly amused that you want Rust after whining about Go's error handling. speaking of which https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14... I'm well aware of Option and try!, etc in Rust. But overall, Rust doesn't mean that you don't have to think about error handling, it just has different mechanisms for reducing the noise in your code. Just reminds me of the people who whine about error handling noise in their code, then ask for help because their code doesn't work, and sure enough there's a n, _ = tcpConn.Read() or some such in there and sure enough....
vertex-four 12y ago
A showdead comment says: > I'm fairly amused that you want Rust after whining about Go's error handling. Fact is, Rust's error handling story is quite nice, with plans to get nicer. It has the try! macro which can automatically convert errors into my own error type with the boilerplate outside the function (thus successfully separating success and error paths to a large extent), and chainable Options and Results for when I need those. With Go, nearly all of my code revolves around handling errors manually, generally repeating how to handle errors several times over, interleaved with the success code, when 99% of the time it's "return an error". EDIT: Another comment: I'm well aware of Option and try!, etc in Rust. But overall, Rust doesn't mean that you don't have to think about error handling, it just has different mechanisms for reducing the noise in your code. Indeed, and I said "most of my code is error handling". I didn't suggest I don't want to think about it - I'd just prefer that I can read what a function does without 2/3rds of the lines in that function being error handling, and thus obscuring what the function does in the success case.
IgorPartola 12y ago
I'm sorry you don't like C. I find it to be a great language for the kinds of things it's good at. I always have a lot of fun when I program using C. No, it's not the most productive language to use, but in some cases you'll be hard pressed to find an alternative; think memory constrained embedded systems, or even VM's, where you are not allowed to use malloc.
adnanh 12y ago
You might want to read [1] :-) [1] http://blog.golang.org/errors-are-values http://blog.golang.org/errors-are-values

ossreality 12y ago

I'm fairly amused that you want Rust after whining about Go's error handling. speaking of which https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14... I'm well aware of Option and try!, etc in Rust. But overall, Rust doesn't mean that you don't have to think about error handling, it just has different mechanisms for reducing the noise in your code. Just reminds me of the people who whine about error handling noise in their code, then ask for help because their code doesn't work, and sure enough there's a n, _ = tcpConn.Read() or some such in there and sure enough....

vertex-four 12y ago

A showdead comment says: > I'm fairly amused that you want Rust after whining about Go's error handling. Fact is, Rust's error handling story is quite nice, with plans to get nicer. It has the try! macro which can automatically convert errors into my own error type with the boilerplate outside the function (thus successfully separating success and error paths to a large extent), and chainable Options and Results for when I need those. With Go, nearly all of my code revolves around handling errors manually, generally repeating how to handle errors several times over, interleaved with the success code, when 99% of the time it's "return an error". EDIT: Another comment: I'm well aware of Option and try!, etc in Rust. But overall, Rust doesn't mean that you don't have to think about error handling, it just has different mechanisms for reducing the noise in your code. Indeed, and I said "most of my code is error handling". I didn't suggest I don't want to think about it - I'd just prefer that I can read what a function does without 2/3rds of the lines in that function being error handling, and thus obscuring what the function does in the success case.

IgorPartola 12y ago

I'm sorry you don't like C. I find it to be a great language for the kinds of things it's good at. I always have a lot of fun when I program using C. No, it's not the most productive language to use, but in some cases you'll be hard pressed to find an alternative; think memory constrained embedded systems, or even VM's, where you are not allowed to use malloc.

adnanh 12y ago

You might want to read [1] :-) [1] http://blog.golang.org/errors-are-values http://blog.golang.org/errors-are-values