5 ms·

The article ends with why Rust wasn’t chosen, but not before randomly disqualifying some other arguably more obscure languages; the author ends with saying that

by hnarn 6y ago

The article ends with why Rust wasn’t chosen, but not before randomly disqualifying some other arguably more obscure languages; the author ends with saying that low level languages “suck”, and that garbage collectors are “great”, and yet Go isn’t mentioned once in the entire post? I’m not even arguing that Go would be the best or even a good choice here, but it seems strange to not even mention it as it also qualifies as great judging by the arbitrary statements of what does and doesn’t “suck” at the very end.

ffijo32j 6y ago
Go doesn't even have try-catch. In high level languages you can just write huge amount of code in a try-catch block that runs in a single transaction and if something goes bad, the entire transaction will be rolled back (without writing a single line of code for this to happen). In Go you have to handle return codes after each operation and that is 100x more code. I don't have time for such micro-optimizations.
- throwaway894345 6y ago
  It’s not a micro-optimization, and you really shouldn’t naively optimize for lines of code. The explicit error handling is to encourage programmers to think about errors and to make it easier for readers to trace the error path through the call stack. Making it harder to punt on error handling is the whole point, just like static typing is tedious for the programmer who only cares if their code appears to be correct.
  - ffijo32j 6y ago
    I see absolutely no point in doing this. For example a network connection may occur any time I execute database query. Why should I handle it? Transaction will be automatically reverted to the previous state without me doing anything. Saves a lot of time (because I have to write much less code) and I never had any issues with this in 15 years.
    - throwaway894345 6y ago
      How does the language know whether you care about a particular error or not? Is the actual act of typing really a significant amount of your time? What about time spent reading and debugging code, which actively benefit from clear error tracing? If typing really is a significant part of your time, how would you feel if your editor autofilled `if err != nil { return err }` for you? What if the language added a `try` operator a la Rust (e.g., whenever you type `?`, it expands into `if err != nil { return err }` code behind the scenes)?
- Thaxll 6y ago
  This statement makes no sense, you're confused between DB transaction ( rollback ) and error handling in a programming language.
- dragonwriter 6y ago
  > Go doesn't even have try-catch. This is true in the narrow sense that Go doesn't use the keywords "try" and "catch" . Its false, though, in that the defer/recover/panic set of tools provides similar functionality to try/catch/finally/throw, with somewhat different syntax. Idiomatic Go uses panics and the associated handling infrastructure less than many other languages use exceptions and their handling infrastructure, though.
didibus 6y ago
I think the author values immutability and/or managed mutation quite highly, as well as functional programming. Since their last startup was CircleCI where they picked Clojure[Script] and later for Dark they picked OCaml, and said they were considering F#, Haskell and Rust. So I'm guessing that disqualified non functional mutation heavy alternatives like Go.
- pbiggar 6y ago
  Yeah, that's sorta right. I didn't want to evaluate every language under the sun. Rust I assumed had similar semantics to what I had been using before, which is why it was so heavily considered.
- throwaway894345 6y ago
  Yeah, Go isn’t a very pleasant language for writing parsers, interpreters, compilers, etc albeit in my opinion this has more to do with sum types and less to do with immutability (you can emulate sum types in Go via interfaces but the ergonomics are quite a lot worse than in an ML-inspired language). This has been my experience anyway, as an avid Go enthusiast.
nemothekid 6y ago
>and yet Go isn’t mentioned once in the entire post? The author is coming from OCaml and eventually switched to F#. Having a powerful type system probably eliminated the author from considering Go.
skybrian 6y ago
I can't speak for the author but I can share my experience from porting the Wren interpreter from C to Go as a hobby project: Writing an interpreter in Go is doable, but interpreters are both very CPU-intensive and built on variant data structures that need to be fast, and Go interfaces are the only data type available that does variants containing pointers. Overhead is high compared to C. You don't have low-level access to things like NaN-packing and you also don't have a JIT available at runtime to speed things up. In many cases it's fast enough, but if you really need to write code in a different language that's both fast on a CPU-bound task and interoperates well with Go packages, a better approach might be to write a compiler that generates Go code. It's a bit of a weak point, but for a specialized use case. Most code is either not that performance sensitive or can be written to operate on homogenous arrays.

by hnarn 6y ago

ffijo32j 6y ago

Go doesn't even have try-catch. In high level languages you can just write huge amount of code in a try-catch block that runs in a single transaction and if something goes bad, the entire transaction will be rolled back (without writing a single line of code for this to happen). In Go you have to handle return codes after each operation and that is 100x more code. I don't have time for such micro-optimizations.

throwaway894345 6y ago
It’s not a micro-optimization, and you really shouldn’t naively optimize for lines of code. The explicit error handling is to encourage programmers to think about errors and to make it easier for readers to trace the error path through the call stack. Making it harder to punt on error handling is the whole point, just like static typing is tedious for the programmer who only cares if their code appears to be correct.
- ffijo32j 6y ago
  I see absolutely no point in doing this. For example a network connection may occur any time I execute database query. Why should I handle it? Transaction will be automatically reverted to the previous state without me doing anything. Saves a lot of time (because I have to write much less code) and I never had any issues with this in 15 years.
  - throwaway894345 6y ago
    How does the language know whether you care about a particular error or not? Is the actual act of typing really a significant amount of your time? What about time spent reading and debugging code, which actively benefit from clear error tracing? If typing really is a significant part of your time, how would you feel if your editor autofilled `if err != nil { return err }` for you? What if the language added a `try` operator a la Rust (e.g., whenever you type `?`, it expands into `if err != nil { return err }` code behind the scenes)?
Thaxll 6y ago
This statement makes no sense, you're confused between DB transaction ( rollback ) and error handling in a programming language.
dragonwriter 6y ago
> Go doesn't even have try-catch. This is true in the narrow sense that Go doesn't use the keywords "try" and "catch" . Its false, though, in that the defer/recover/panic set of tools provides similar functionality to try/catch/finally/throw, with somewhat different syntax. Idiomatic Go uses panics and the associated handling infrastructure less than many other languages use exceptions and their handling infrastructure, though.

didibus 6y ago

I think the author values immutability and/or managed mutation quite highly, as well as functional programming. Since their last startup was CircleCI where they picked Clojure[Script] and later for Dark they picked OCaml, and said they were considering F#, Haskell and Rust. So I'm guessing that disqualified non functional mutation heavy alternatives like Go.

pbiggar 6y ago
Yeah, that's sorta right. I didn't want to evaluate every language under the sun. Rust I assumed had similar semantics to what I had been using before, which is why it was so heavily considered.
throwaway894345 6y ago
Yeah, Go isn’t a very pleasant language for writing parsers, interpreters, compilers, etc albeit in my opinion this has more to do with sum types and less to do with immutability (you can emulate sum types in Go via interfaces but the ergonomics are quite a lot worse than in an ML-inspired language). This has been my experience anyway, as an avid Go enthusiast.

nemothekid 6y ago

>and yet Go isn’t mentioned once in the entire post? The author is coming from OCaml and eventually switched to F#. Having a powerful type system probably eliminated the author from considering Go.

skybrian 6y ago

I can't speak for the author but I can share my experience from porting the Wren interpreter from C to Go as a hobby project: Writing an interpreter in Go is doable, but interpreters are both very CPU-intensive and built on variant data structures that need to be fast, and Go interfaces are the only data type available that does variants containing pointers. Overhead is high compared to C. You don't have low-level access to things like NaN-packing and you also don't have a JIT available at runtime to speed things up. In many cases it's fast enough, but if you really need to write code in a different language that's both fast on a CPU-bound task and interoperates well with Go packages, a better approach might be to write a compiler that generates Go code. It's a bit of a weak point, but for a specialized use case. Most code is either not that performance sensitive or can be written to operate on homogenous arrays.