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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

11–20 of 235 posts

Re: A year with Go

#11

Post by mikeokner »

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "teaching" language, nor would anyone call it "mature" at this point, but it does fill a niche and fills it pretty well.

http://blog.disqus.com/post/51155103801/trying-out-this-go-t...

Re: A year with Go

#12

Post by dvt »

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)).

I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it almost at all for the past couple of years :(

Re: A year with Go

#13

Post by Manishearth »

webkike wrote: 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.

I don't see how traits are limited.

Traits are types, though you need to put them behind a pointer (Box or &Trait) if you want to use them as types; and this is dynamic dispatch.

You can use them in static dispatch (generics) too, and in general you should try to do that whenever possible. Plus there are loads of things you can do with them that Go can't (static trait methods, associated items, generics, etc)

The only feature that Go interfaces have that Rust traits don't is auto-implementation, and that's a misfeature IMO. It works okay for Go, but in Rust it makes more sense to explicitly say that you are implementing a trait.

Re: A year with Go

#14

Post by webkike »

kibwen wrote: post #9
webkike wrote: 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).

Take the following example from Go:

    type ExInterface interface { ... }
    type ExStruct {
         arr []ExInterface
    }
Each element of arr need not be the same type, so long as it implements ExInterface. In Rust, the only thing I can do that is similar is:

   struct ExStruct {
        arr: Vec,
   }
Which means that each element of arr not only has to implement ExTrait, but also has to be of consistent type with the rest of the elements. If I want the same level of flexibility the Go gives me, I need to make an enum of each possible type that arr can contain.

Re: A year with Go

#15

Post by zak_mc_kracken »

mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...

Re: A year with Go

#17

Post by solarexplorer »

eloff wrote: post #7
smegel wrote: 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.

Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.

Re: A year with Go

#18

Post by nostrademons »

zak_mc_kracken wrote: post #15
mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

Re: A year with Go

#19

Post by 0xdeadbeefbabe »

zak_mc_kracken wrote: post #15
mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...

> IDE's

Lack of an IDE is a feature not a bug.

Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have.

> tooling

Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools?

Wrong philosophy in my opinion; I could imagine something better.

Re: A year with Go

#20

Post by zak_mc_kracken »

lxcid wrote: post #8
smegel wrote: 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?

Erlang is probably the only true object-oriented language. http://www.infoq.com/interviews/johnson-armstrong-oop

> Erlang is probably the only true object-oriented language.

And it's true because its creator says so right here, in this link!

Post reply on HN