6 ms·
I don't mind it, but I don't love it either. It's easy to write, but it would be nice if the compiler enforced error handling so that you did not need to run e
by justinsaccount 10y ago
I don't mind it, but I don't love it either. It's easy to write, but it would be nice if the compiler enforced error handling so that you did not need to run errcheck.
I completely fail at writing rust, but their implementation of error handling is much nicer.
Want to call a function, returning the error up to the caller on error? Instead of
res, err := somefunc()
if err != nil {
return err
}
You can just do
let res = try!(somefunc());
If you need the function to succeed, similar to how go has some functions like MustCompile, rust has unwrap and expect:
let res = somefunc().unwrap();
or
let res = somefunc().expect("somefunc broke :(")
> Go forces you to handle the error (or explicitly ignore it).
But that isn't really forcing you to do anything. There are 3 ways you can deal with an error: handle, ignore, or panic. In many cases go programs ignore errors when they really should panic.
It is disappointing that the go "equivalent" that you often see in examples is
res, _ := somefunc()
This is not handling an error or explicitly ignoring it, it is pretending that the function never fails.
rust makes it impossible to ignore the error, while also making it easy to skip error handling if you just want to abort on failure.
if I could write code in go + rust generics + macros and not have to deal with the lifetime borrow checking crap, I would be so happy :-)
- PeCaN 10y ago> if I could write code in go + rust generics + macros and not have to deal with the lifetime borrow checking crap, I would be so happy :-) You might like OCaml. It's easy to write like Go but with a much more useful type system. Downside: concurrency is not as pleasant as in Go… at all. Then again, I see a lot of things written in Go that aren't particularly concurrent and just happen to use Go because the author wanted a moderately high-level compiled language with automatic memory management. OCaml is excellent for those.
- weberc2 10y agoAlso, Reason (a syntax on top of OCaml) makes OCaml look pleasant.
- PeCaN 10y agoOCaml already looks nice <_< (…Once you've used it for a bit. I admit it looks kinda weird at first.) I recall Reason didn't yet support some important part of OCaml syntax, but I don't remember what that was. Though I don't dispute that Reason is a good thing—Erlang saw a lot of growth from Elixir, hopefully Reason will get people into OCaml.
- gnuvince 10y ago> OCaml already looks nice <_< I agree; I find Reason to be a completely pointless project except if Facebook hopes to fracture the OCaml community.
- LeonidasXIV 10y agoFortunately Reason compiles to ordinary OCaml compiled modules, so everything they write can seamlessly interop with regular OCaml in both ways. But yeah, I also don't think the Reason syntax is that massive of an improvement: https://xivilization.net/~marek/blog/2016/05/19/reason-lets-see-what-happens/ https://xivilization.net/~marek/blog/2016/05/19/reason-lets-...
- douche 10y agoIn the same family, but with fairly nice concurrency (as far as I've gone with it) is F#. Even works on Linux, through mono now, and hopefully soon with .net core.
- weberc2 10y agoI thought try! and unwrap() just panic on failure? Isn't that exactly the same thing as `res, _ := somefunc()`?
- PeCaN 10y agounwrap panics on failure; try! is equivalent to match somefunc() { Ok(res) => res, Err(e) => return Err(e) } in Rust; or res, err := somefunc() if err != nil { return err } in Go. Also, while I don't really know Go, doesn't res, _ := somefunc() silently ignore the error instead of panicking?
- fizzbatter 10y ago> silently ignore the error instead of panicking? Correct, with the minor note that it of course depends on your usage. If `res` is a pointer, any usage of it will panic because you ignored the err
- __s 10y agoWhich means if you don't use that pointer for awhile you're going to have to do some backtracking to that ignored error
- giovannibajo1 10y agoWhich is why nobody writes that in production code; it's only used in examples and maybe tests
- fizzbatter 10y agoMy Rust on `try!` is rusty... no pun intended, iirc it is the equivalent of: if err := someFn(); err != nil { return err } Where as `unwrap()` is: if err := someFn(); err != nil { panic(err) } So a little dif than your example, fwiw. (Not agreeing or disagreeing with any of the statements, merely commenting on your question)
- mixedCase 10y ago>In many cases go programs ignore errors This would be an absolutely terrible Go programmer. Like "I only log in as root to avoid typing sudo and my password" level retarded.