Hacker News Reader

Comment by oldpond | Hacker News Reader

Thanks for that interesting viewpoint. I have also done the same survey, and I agree. I did a ChicagoBoss PoC last year, and Elixir and Phoenix are my goto for the next one.

It should also be noted that both are young languages and they are evolving rapidly. This makes them even more exciting to me. Also, I think Go's sweet spot may be a new approach to client/server i.e. applications that work across the network. This is quite different than the browser/app server model. Elixir has similar plumbing that fit this model as well, but what really excites me about Elixir and Phoenix is the ability to build a restful MVC application that can take advantage of Erlang/OTP's scalability.

View on HN

It should also be noted that both are young languages and they are evolving rapidly.

Erlang itself is nearly 30 years old, but it wasn't open sourced until 1998. OTP came shortly after.

Erlang doesn't evolve rapidly at all (at least, not in the typical sense of "Software innovates so quickly - Last year I was using one event loop, and this year another"!). It's remarkably conservative, yet still ahead of the pack. That's what makes it so great.

He was talking about Elixir and Go. Not Erlang.

He might intentionally ignored Elixir, IMO.

> It should also be noted that both are young languages and they are evolving rapidly.

Go will basically get dynamic linking and stop evolving. Its type system is way too simple to support any new significant feature. And go designers have said many time that the language is "done".

My understanding is not that they have said that the language is "done", but that the 1.0 branch is stable and won't get any new major language features. At somepoint they will start rolling out 2.0 and it will have new features, maybe even generics. But why should they worry about that the language is plenty good as it stands for developing and their is plenty of work to do on cleaning up build systems, runtime, gc, etc.

> "The language is done and that's a good thing," Buberel says.

http://finance.yahoo.com/news/google-thinks-knock-one-oracle...

Pike said exactly the same thing(video is on youtube), another Go guy said exactly the same thing in a podcast ...

So yes, Go language is DONE, period.

> But why should they worry about ...

They don't, however people adopting Go and wanting generics shouldn't be tricked into thinking that Go developers are even considering generics , because they are not. If they invest in Go, they should know that they aren't going to get generics at all. As for what the Go team thinks, it doesn't really matter they are not betting their own startup on Go.

> they will start rolling out 2.0 and it will have new features

where did you get that idea? it is impossible to add significant new features without breaking backward compatibility, do you really think Go designers are ready to go that way? of course not. But i'm curious what led you to think that ?by all means, give me official sources like I just gave you.

Nothing in the future is set in stone. I'm curious why you're so sensitive about this issue.

I suspect (because I read minds) that if they _knew_ Go was going to add generics and such in a year or two that they'd be ready to dive in for a big project or two. No point in investing the time in working up a significant Go project if you value Features X & Y but don't believe the language is headed there.

In other words, the frustration is because Go is _close_ to a good language but not quite good enough if we know this is it. Or, maybe even worse, we don't know anything at all about its future direction.

> where did you get that idea?

The core Go developers has said that an eventual implementation of generics won't arrive until Go 2.0, were they will allow breaking backward compatibility. That said, an eventual Go 2.0 release is probably years away.

So yes, Go language is DONE, period.

They don't, however people adopting Go and wanting generics shouldn't be tricked into thinking that Go developers are even considering generics , because they are not.

Wrong:

Generics may well be added at some point. [...] This remains an open issue.

https://golang.org/doc/faq#generics

If you understand one or two things about type theory then you know that generics cannot be added to GO. Go designers know it. They cannot add generics without breaking the language and they will not break the language.

When you have at least 3 core designers of that language saying on record that the language won't have new features, then you know what is written in that Faq ain't going to happen.

So let's not mislead people interested in Go into thinking that it will get generics, it will never have generics.

I think you need to justify that statement, what about type theory says that Go can't have generics?

As a follow-up, would the same logic have proved that Java 1.4 couldn't add generics?

Sorry, I think of the ecosystem around a language as part of the language. Tooling, frameworks, etc.

Reply on news.ycombinator.com