Live data from Hacker News

A year with Go

vagabond.github.io

1–10 of 235 posts

Re: A year with Go

#2
The point isn't about learning something new. It's about trying to apply those things into a language they think is easier to work with.

Re: A year with Go

#3
> if I wanted a language built around concurrency I’d use Erlang or Haskell.

And if you wanted a concurrent language that wasn't a functional language what would you use?

Re: A year with Go

#4
When I use Rust I am constantly annoyed by how limiting traits are in comparison to interfaces. I much prefer interfaces, which are a single type, as opposed to traits, which are sets of types.

Re: A year with Go

#6
post #4

When I use Rust I am constantly annoyed by how limiting traits are in comparison to interfaces. I much prefer interfaces, which are a single type, as opposed to traits, which are sets of types.

How do traits limit you? Could you give an example?

Re: A year with Go

#7
post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

Re: A year with Go

#9
post #4

When I use Rust I am constantly annoyed by how limiting traits are in comparison to interfaces. I much prefer interfaces, which are a single type, as opposed to traits, which are sets of types.

What do you mean by "sets of types"? Traits in Rust handle more duties than interfaces do in Go, but in their role as interfaces the only difference is that Rust traits are explicitly implemented whereas Go interfaces are implicitly implemented (i.e. nominal types vs structural types).

Re: A year with Go

#10
post #2

The point isn't about learning something new. It's about trying to apply those things into a language they think is easier to work with.

I'd argue the point is the opposite of learning new things. As the Go team themselves say, Go is an engineering project. It's about sticking to well understood, well defined ideas that allow large teams of typical skill to develop and maintain good software. Go is boring compared to some other languages that push the envelope and try new things. But that can be a good thing if you start thinking like the business owner instead of a code monkey.
Post reply on HN