←back to thread

302 points Bogdanp | 1 comments | | HN request time: 0.222s | source
Show context
rednafi ◴[] No.44392307[source]
I’m glad that Go went the other way around: compilation speed over optimization.

For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

replies(9): >>44392470 #>>44392882 #>>44393976 #>>44394789 #>>44395314 #>>44395527 #>>44395624 #>>44398142 #>>44398420 #
mark38848 ◴[] No.44393976[source]
What are obnoxious types? Types either represent the data correctly or not. I think you can force types to shut up the compiler in any language including Haskell, Idris, PureScript...
replies(4): >>44394280 #>>44395145 #>>44396684 #>>44408670 #
1. IshKebab ◴[] No.44408670[source]
That's not true. There's a spectrum of typing complexity all the way from TCL everything-is-a-string to formal languages like Lean where the types can prove all sorts of things.

As you go further towards formal verification you get:

* More accurate / tighter types. For example instead of `u8` you might have `range(0, 7)` or even a type representing all odd numbers.

* Better compile time detection of bugs. (Ultimately you are formally verifying the program.)

* Worse type errors. Eventually you're getting errors that are pretty much "couldn't prove the types are correct; try again".

* More difficulty satisfying the type checker. There's a reason formal verification of software isn't very popular.

So it's definitely true that "more obnoxious types" exist, but Go is very far from the obnoxious region. Even something like Rust is basically fine. I think you can even go a little into dependent types before they really start getting obnoxious.

TL;DR, he's just lazy and doesn't really care about bugs.