4 ms·

I can't speak for Go, but what you describe isn't really a thing in Rust. Functions in Rust that might encounter an "exception" typically return something like

I can't speak for Go, but what you describe isn't really a thing in Rust. Functions in Rust that might encounter an "exception" typically return something like `Result<T, E>` where `T` is the type of what we hope we get and `E` is a type that encodes the details of the errors/exceptions we might see. It's an enum type that comes in two flavors: `Ok(T)` and `Err(E)`. You can't just go happily along treating an `E` like it's a `T`, because the compiler won't allow it. So I'm not sure how you might get into a "corrupt state". You only have three choices: panic, return and pass the error back up the call stack, or handle it explicitly. All those choices short circuit what you were doing and don't leave you with anything that you could mistake for a valid result at any level of the call stack (again, this is enforced by the compiler). Whether it's ergonomic is another question. I happen to like it, but for sure doing exceptions in Python means fewer LOCs, if that's what you're after. I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows.

pmarreck 10y ago
Good point. I am not very familiar with Rust (good to hear it seems to treat this well, however!) but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. > I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows. So let me guess, you too have worked on very large spaghetti codebases? ;) Because I am also interested in that very same end-goal! And that is actually why I've decided to only focus on functional langs for now (right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho), because the resulting code just feels more maintainable
- caconym_ 10y ago
  > but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. I'm not sure whether this is a thing in Go, but I tend to think that having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe and is basically a misfeature outside of C. > So let me guess, you too have worked on very large spaghetti codebases? ;) Because I am also interested in that very same end-goal! And that is actually why I've decided to only focus on functional langs for now (right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho), because the resulting code just feels more maintainable Sure have :). My personal opinion is that rich type systems like Haskell's (and Rust's, they are actually very similar in many ways) are really nice for managing complexity, maintaining and refactoring with confidence, and cutting off lazy design decisions at the roots. It takes a fair amount of experience (and I don't think I'm 100% of the way there yet by any means) to use them in a way that gets them out from under your feet and makes them really work for you, but it's experience worth having IMO. Haskell is really great, IMO well worth learning even if you end up not using it professionally. Also, it's not built on the JVM; you might be thinking of Scala?
  - pmarreck 10y ago
    ah, I wasn't trying to imply that Haskell was a JVM language (I know it has its own compiler- GHC), I was referring to Scala and Clojure. I should have probably used a semicolon in between those two instead of a comma! > having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe In practice I haven't really seen this causing problems, for languages like Ruby and Elixir where the only "falsey" values are nil and false. And it enables some very readable code.
- leshow 10y ago
  >right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho FYI, Haskell is not a JVM language. It compiles to binaries, the compiler is called GHC. Elixir runs on the Erlang VM, also unrelated to JVM.
  - pmarreck 10y ago
    I was not trying to suggest that Haskell was a JVM language. I said I wasn't a fan of the JVM languages (like Scala and Clojure), but I can see how someone might think that due to how I worded it, perhaps a semicolon instead of a comma would have helped, there
    - leshow 9y ago
      The subject of your sentence never changed, and the "though" (used as "however" in this case) make the topics related. I think it's more of a solecism than a difference in interpretation. Glad we're all on the same page though haha.

pmarreck 10y ago

Good point. I am not very familiar with Rust (good to hear it seems to treat this well, however!) but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. > I tend to be more interested in how the features of a language help programmers to keep writing correct and maintainable code as the complexity of a project grows. So let me guess, you too have worked on very large spaghetti codebases? ;) Because I am also interested in that very same end-goal! And that is actually why I've decided to only focus on functional langs for now (right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho), because the resulting code just feels more maintainable

caconym_ 10y ago
> but a cursory examination of Go code shows that runtime errors can end up being entirely ignored and that seems crazy to me. I'm not sure whether this is a thing in Go, but I tend to think that having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe and is basically a misfeature outside of C. > So let me guess, you too have worked on very large spaghetti codebases? ;) Because I am also interested in that very same end-goal! And that is actually why I've decided to only focus on functional langs for now (right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho), because the resulting code just feels more maintainable Sure have :). My personal opinion is that rich type systems like Haskell's (and Rust's, they are actually very similar in many ways) are really nice for managing complexity, maintaining and refactoring with confidence, and cutting off lazy design decisions at the roots. It takes a fair amount of experience (and I don't think I'm 100% of the way there yet by any means) to use them in a way that gets them out from under your feet and makes them really work for you, but it's experience worth having IMO. Haskell is really great, IMO well worth learning even if you end up not using it professionally. Also, it's not built on the JVM; you might be thinking of Scala?
- pmarreck 10y ago
  ah, I wasn't trying to imply that Haskell was a JVM language (I know it has its own compiler- GHC), I was referring to Scala and Clojure. I should have probably used a semicolon in between those two instead of a comma! > having a ubiquitous null object in your language that's "falsey" is responsible for a lot of problems like what you describe In practice I haven't really seen this causing problems, for languages like Ruby and Elixir where the only "falsey" values are nil and false. And it enables some very readable code.
leshow 10y ago
>right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho FYI, Haskell is not a JVM language. It compiles to binaries, the compiler is called GHC. Elixir runs on the Erlang VM, also unrelated to JVM.
- pmarreck 10y ago
  I was not trying to suggest that Haskell was a JVM language. I said I wasn't a fan of the JVM languages (like Scala and Clojure), but I can see how someone might think that due to how I worded it, perhaps a semicolon instead of a comma would have helped, there
  - leshow 9y ago
    The subject of your sentence never changed, and the "though" (used as "however" in this case) make the topics related. I think it's more of a solecism than a difference in interpretation. Glad we're all on the same page though haha.