Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Golang Is and Is Not

danmux.com

Post reply on HN
Print view View original

11–20 of 279 posts

Re: What Golang Is and Is Not

#11

Post by catnaroek »

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one.

Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program.

Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!).

(inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)

Re: What Golang Is and Is Not

#12

Post by omni »

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?

This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck

Re: What Golang Is and Is Not

#13

Post by knucklesandwich »

catnaroek wrote: post #11
bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality.

Re: What Golang Is and Is Not

#14

Post by ehsan_akbari »

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

Hey, Are `integration tests` potato here!?

Re: What Golang Is and Is Not

#15

Post by themgt »

viach wrote: post #10
sergiotapia wrote: post #3

The author is quite correct. Go is super boring, and runs fast. Two great points for it. For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit. The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of c…

Elixir is nicer to look at, Go is easier to understand.

I find "nice to look at" and "easier to understand" tend to converge over time. Elixir pushes me to expand my mental maps a bit more than Go, but once I grok it the code reads much more coherently and concisely.

Go to me reads like an ELI5 programming language.

Re: What Golang Is and Is Not

#16

Post by TillE »

catnaroek wrote: post #5
scriptproof wrote: post #2

If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds.

Swift 3 looks good, though. They've learned the right lessons.

Re: What Golang Is and Is Not

#17

Post by Gankro »

catnaroek wrote: post #11
bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taki…

Honestly parametric polymorphism is a big slippery slope feature. There's always Just One More Thing -- higher rank/order/kinded types, where clauses, dependent types, specialization... or else you force people to use dynamic checks/allocations/casts that reduce your type-safety and bog the code down relative to the "optimal" design.

Don't get me wrong, I love me some parametric polymorphism, but it's by no means a simple thing as far as I've seen. Especially if you care about the effeciency of things (you can fudge a lot more wih lots of indirection/allocation, like Java does).

Re: What Golang Is and Is Not

#18

Post by dominotw »

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy.

Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

Re: What Golang Is and Is Not

#19

Post by catnaroek »

TillE wrote: post #16
catnaroek wrote: post #5

Earlier quoted context omitted.

C++, otherwise a deeply flawed language, gives you more abstraction than Go and allows you to optimize and micromanage things more.

I love how C++ has had simple features like default arguments / function overloading for decades, while modern languages like Go and Rust require awkward workarounds. Swift 3 looks good, though. They've learned the right lessons.

Default arguments, at least as done in C++, complicate the language's semantics (e.g., template specialization selection) far more than they raise the level abstraction. Definitely not a well-designed feature.

And Rust's traits are a far more principled (and thus better!) approach to overloading than anything C++ has (Boost's concept checks?). Traits turn concepts into language entities that are directly expressible in Rust syntax, rather than in awkward English documentation.

Re: What Golang Is and Is Not

#20

Post by namelezz »

bluejekyll wrote: post #6

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to…

> This is a huge improvement over Java, and something every language should have an option for.

I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.

Post reply on HN