3 ms·

I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivit

I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivity.

afandian 3y ago
I’ve used a number of languages over the years and I have never been more productive than with Kotlin.
Cthulhu_ 3y ago
I'm wondering if there will be a language that compiles to Go, like Typescript is for Javascript, that adds a stricter type system (and fixes other issues) and adds a compiler step, but still has all the other benefits of Go.
throwawa14223 3y ago
Conversely I could go longer between compiles if the type system caught more.
- Cthulhu_ 3y ago
  It doesn't even have to affect compile times per se, it could be a linter/checker task running separately from the main compiler; most type errors are only relevant during development in my experience. Said experience lately is a lot of Typescript, where all type information is no longer relevant at runtime because it's compiled out or just bluntly removed to make it valid JS (I dunno how the TS compiler works).
- arp242 3y ago
  Most of the times when I really care about quick feedback cycles is when I'm experimenting to see what approach does and doesn't work well in the first place. I care a lot less about it for "simple" errors like typing errors, typos, or whatnot. This is mostly trivial stuff compared to "is this entire approach good or not?"
  - throwawa14223 3y ago
    I think I agree with you, but in trivial projects even the infamous slow compilers are fine. Toy Rust projects and small Java projects get compiled very fast.
anta40 3y ago
Yep this is one of the reasons lots of my friends switched to Go: short compilation time (like good old Pascal days). Rust & Haskell is a big no :p
- kuchenbecker 3y ago
  Additionally, codegen and templated metaprogramming is very fast in go. Gen + Compile + Lint + Test on Save with line-by-line coverage overlay in <10s.
- bunderbunder 3y ago
  But we're not talking about replacing Go with something like Rust or Haskell here. We're talking about really basic, inexpensive things like not repeating Tony Hoare's billion dollar mistake yet again. Or actual structured error handling instead of something that's ergonomically quite similar to classic C-style error handling aside from the relatively incremental improvement of not relying on global variables.
  - bborud 3y ago
    I'm not so sure that we're necessarily talking about small, inexpensive changes here. Anything that changes the fundamental character of a language is probably going to have bigger consequences than you might imagine. I've been writing a fair bit of C lately. I'd say that the way Go error handling works has exactly nothing in common with C. Despite spending 15 years mostly writing C on UNIX 20 years ago, when returning to C it was striking how little Go's convention of returning multiple values, with the error being the last, has in common with C. And if by structured error handling you mean things like exceptions: I don't really see how that improves error handling from a readability or security point of view. In Java people can't even agree on whether or not to use checked exceptions (ie neuter any perceived advantage of exceptions), and syntactically, exceptions are a little bit more awkward than return values as you invariably create nested scopes and move the handling of exceptions away from the normal program flow - which is not a readability win. But I'll grant you that the error type in Go was both a bit vague and there was a lack of sensible stuff to, for instance, wrap and accumulate errors initially. But that has gotten better.
hardwaregeek 3y ago
You can make it pretty darn robust! OCaml compiles very quickly and has a good type system. Rust is slow due to LLVM, macros, and the compilation unit being the entire crate. None of these are requirements for a good type system
- bunderbunder 3y ago
  Zig's new compiler is a nice example of how you can do all sorts of inherently slow things at compile time and still have a lightning fast iteration time for developers if you design your toolchain for incremental compilation instead of making the compilation unit be the entire module the way Rust did.

I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivity.

afandian 3y ago

I’ve used a number of languages over the years and I have never been more productive than with Kotlin.

Cthulhu_ 3y ago

I'm wondering if there will be a language that compiles to Go, like Typescript is for Javascript, that adds a stricter type system (and fixes other issues) and adds a compiler step, but still has all the other benefits of Go.

throwawa14223 3y ago

Conversely I could go longer between compiles if the type system caught more.

Cthulhu_ 3y ago
It doesn't even have to affect compile times per se, it could be a linter/checker task running separately from the main compiler; most type errors are only relevant during development in my experience. Said experience lately is a lot of Typescript, where all type information is no longer relevant at runtime because it's compiled out or just bluntly removed to make it valid JS (I dunno how the TS compiler works).
arp242 3y ago
Most of the times when I really care about quick feedback cycles is when I'm experimenting to see what approach does and doesn't work well in the first place. I care a lot less about it for "simple" errors like typing errors, typos, or whatnot. This is mostly trivial stuff compared to "is this entire approach good or not?"
- throwawa14223 3y ago
  I think I agree with you, but in trivial projects even the infamous slow compilers are fine. Toy Rust projects and small Java projects get compiled very fast.

anta40 3y ago

Yep this is one of the reasons lots of my friends switched to Go: short compilation time (like good old Pascal days). Rust & Haskell is a big no :p

kuchenbecker 3y ago
Additionally, codegen and templated metaprogramming is very fast in go. Gen + Compile + Lint + Test on Save with line-by-line coverage overlay in <10s.
bunderbunder 3y ago
But we're not talking about replacing Go with something like Rust or Haskell here. We're talking about really basic, inexpensive things like not repeating Tony Hoare's billion dollar mistake yet again. Or actual structured error handling instead of something that's ergonomically quite similar to classic C-style error handling aside from the relatively incremental improvement of not relying on global variables.
- bborud 3y ago
  I'm not so sure that we're necessarily talking about small, inexpensive changes here. Anything that changes the fundamental character of a language is probably going to have bigger consequences than you might imagine. I've been writing a fair bit of C lately. I'd say that the way Go error handling works has exactly nothing in common with C. Despite spending 15 years mostly writing C on UNIX 20 years ago, when returning to C it was striking how little Go's convention of returning multiple values, with the error being the last, has in common with C. And if by structured error handling you mean things like exceptions: I don't really see how that improves error handling from a readability or security point of view. In Java people can't even agree on whether or not to use checked exceptions (ie neuter any perceived advantage of exceptions), and syntactically, exceptions are a little bit more awkward than return values as you invariably create nested scopes and move the handling of exceptions away from the normal program flow - which is not a readability win. But I'll grant you that the error type in Go was both a bit vague and there was a lack of sensible stuff to, for instance, wrap and accumulate errors initially. But that has gotten better.

hardwaregeek 3y ago

You can make it pretty darn robust! OCaml compiles very quickly and has a good type system. Rust is slow due to LLVM, macros, and the compilation unit being the entire crate. None of these are requirements for a good type system

bunderbunder 3y ago
Zig's new compiler is a nice example of how you can do all sorts of inherently slow things at compile time and still have a lightning fast iteration time for developers if you design your toolchain for incremental compilation instead of making the compilation unit be the entire module the way Rust did.