No, unless the language evolves substantially. I love Go. I've written a fairly widely-used, large-ish application with it. Go shines in the following respects:
1. They got concurrency right. Writing ostensibly blocking code and letting the runtime yield in the background is The Future.
2. Implicit interfaces and formalizing "composition over inheritance" is the right way to think about reusing functionality.
3. Deployment is stupidly easy with zero-dependency binaries.
4. The cross-compilation tool chain is dead simple. (excepting CGo)
5. The tooling around Go's handling of code (godoc, go vet, go fmt, etc) is superb. Enforcing a one-true coding style makes foreign code easier to understand.
That being said, Go is missing the expressiveness that you expect coming from higher level languages like Haskell/Python/Scala. In many cases, it is a unnecessary step backwards on the thought-to-code spectrum. Not having things like generics and list comprehensions makes my code more verbose and more difficult to understand.
Certainly Go will evolve, although the authors often seem perhaps a little too resistant to change. I suspect that Go's popular successor ten years from now will have stolen Go's best qualities and iterated faster to include the higher-level language niceties that we expect.
I have a longer blog post to expand on this later.
Absolutely. Generics are too powerful an abstraction to do without in 2013. I can't imagine coding without them. Go is a no-go for me.
Everyone talks down on C++ but it's one of the few languages that gets generics right. The only language with implicit RAII (not explicit like C#/Java). The only language to put into practice 0 cost abstractions.
You mean a Go++, designed by committee with all language features known to man thrown together, ranging from meta-programming to dependent types, trying to please everyone, and as a result pleasing no one, and everybody will wish for a simpler language?
Not better enough - and no new platform to carry it unlike JS, Perl, Ruby, Python, PHP, Java (web); Objective-C, Java (mobile); Java, Ruby, Python (cloud).
The problem is that people don't like to switch. They'd prefer their present tool to improve, and they'll support that. So the only way a language can achieve ascendency is when users don't switch. That is, new users. During rapid adoption of a platform, a significant majority can be new users. And that is the only time a new language can take over.
NOTE: it may appear there's an exception with flavour-of-the-month frameworks etc, but this is a combination of rapid turnover of developers/projects in specific areas, plus the enthusiast/techie kind of developers who love to switch (the ones always excited about the newest tech for its own sake, not for its long-term practical benefits: think inventor, not investor). These developers cannot form the basis of language's future, because they will quickly switch to the next new thing.
I agree that a new language has a much better chance of survival if it's part of a new platform. And it's interesting to think about what exactly a "platform" is in this context: an OS, a form factor, a VM, a scriptable tool, a technology stack, a service, a sandbox, a consumer app, a game, new users, a new industry, something that nobody's thought of.
But C++ suggests another path to language survival: present it as an "easy-to-learn" (it started that way) superset of an existing language that addresses a weakness. It's C! With classes!
I see the present in Go. It's a language that's highly useful for solving server software problems today.
The future may not be particularly interested in Go. It doesn't open interesting new research avenues. If it becomes a proverbial "100-year language", it's going to be the legacy mess that some poor soul will hate to maintain in 2110.
I'm not going to be around in 2110 and I'm not a researcher, so I like using Go.
Static typing + type inference is a powerful combination. Go, Scala and Rust are particularly appealing as the mix expressiveness with good performance.
No, I don't see a future in Go. It's not going to replace C or C++ for anything, and it's not going to displace Java. It's not fast enough to be a systems language, and it's not as easy to use as a scripting language.
I personally see much more of a future with Rust, since it actually has a chance of replacing C++.
C++ no and Java probably not, but attracting a huge chunk of devs away Python isn't just plausible, it's already happening. I fully expect Go to appeal to anyone who's ever had reason to gripe about Python's GIL.
Great for server-side apps. Configuration management is a breeze with its single-large-executable approach. I agree with a lot of the design decisions; and find it a nice language to work with.
It suffers a bit from the fact that dynamic languages like Python are (and will always be) nicer and more productive for hacking around in when performance is not a concern; and from the fact that you cannot (yet) beat C for (single-thread) performance.
So, if productivity is everything: use Python, or your dynamic language of choice. If performance is everything, use C (or C++, if you really must).If, on the other hand, you want a nice balance between (good-enough) productivity and (good-enough) performance, Go is a great bet.
I bet that in 10 years time, once the hype has died down, Go will be seen as a middle-of-the-road language for middle-of-the road applications. A low-risk, conservative, sensible, and ultimately boring choice.
Which is great, because that is exactly what Go is trying to achieve.
I bet that in 10 years time, once the hype has died down, Go will be seen as a middle-of-the-road language for middle-of-the road applications. A low-risk, conservative, sensible, and ultimately boring choice.
In ten years, Go will be seen as what Oberon is seen as today: essentially all the things you mention, plus the fact that there will be a dedicated community of people who like the no-nonsense "do more with less" approach that is peculiar to this family of languages and don't want to live without it. Plus, Go will most likely have some evolutionary continuation anyway.
You really think so? I think that implies that it remains unsuccessful, which (given its current trajectory) seems unlikely.
I think it's more likely that in 10 years, Go will be the new Java. Big companies (besides Google) will use it, Hacker News will hate it, consultants will write books about it, and language geeks will be trying to replace it. Recall that Java also had a no-nonsense "do more with less" approach. The problem is that once a language gets popular, it's inevitably pushed into more and more domains where it's unsuitable, folks need to learn it to earn a living, and all the folks who define themselves by what languages they know will move on to greener pastures.
The only way a language can remain cool for decades at a time is to "avoid success at all costs", which was actually one of Simon Peyton-Jones's goals for Haskell (which has remained remarkably true to that ideal). Otherwise Stroustrop's Law kicks in: "There are two kinds of languages: the ones nobody likes, and the ones nobody uses."
I agree that for quickly writing code Python is quicker, but I'm not sure it's necessarily to do with dynamic typing. I've been using Go for about a year and a half and Python for about double that (and other things before that like C#). I'm still trying to pin down the usability differences, and what causes them.
List comprehensions are one of the most obvious things. LINQ and Haskell and co have shown that this is absolutely doable with a static type system.
The lack of genericity is one of those things that will be argued about for the lifetime of Go, I think. Python doesn't need it because of the dynamic typing but the same problems are solved to some extent by the compile-time-duck-typing enabled by its interface system.
I'm not sure I agree re productivity. One on project I reached 30,000 lines of Python, collaborating with 3 other people remotely. Some things would have been a lot easier with static typing. I think.
There's work in progress on type inference and static typing for Python, and Python 3 supports type annotations (PEP 3107). Whether they'll get anywhere remains to be seen - it's a challenging problem, not the least because several of the language built-ins have strange typing rules. (What's the type of multiplication?)
I dislike Google for pulling the plug on consumer products as well, but this is a product designed for use at Google and I understand they are writing/converting a lot of code in it. So I think you underestimate Google's backing in this case, which is probably the reason Go has seen one of the fastest rises in popularity of any language, ever -- if not the fastest.
Go has made me enjoy programming again -- I find it very freeing not to have to use Java or .NET and memorize 40,000 builtin classes. Yes, Go is similar to Java in terms of its being a "middle of the road" conservative language. But (a)it's conservative for the 21st Century, rather than the 20th, and (b)ditching the virtual machine and bloat of Java is a good thing IMO.
I see it being useful for server utility apps. The sort of thing you might in the past have done using Bash, Python, Perl etc. The barebones nature of the language and the ability to package everything into a single executable is incredibly handy for these use cases.
For everything else no. The JVM is going to continue to dominate for medium to large apps with Scala and Clojure offering something new and original whilst allowing for existing code to be reused. And for smaller apps it's hard to look past Javascript.
I don't see any future for it. Authors concentrated too much on "simplicity".
It's the language which doesn't have important modern language features, like generics, and I won't ever use it unless these feature are added which is highly unlikely.
Languages like Mozilla Rust seem to me to be a more adequate replacement for C++.
Parametric polymorphism is not a "modern" language feature, it has been known for many decades. When language designers opt against the inclusion of generics in the year 2007, then you can be sure that they don't do so because they are too stupid to see the benefits of "generics", but because they also consider the downsides. Language design is decision-making in hundreds of trade-off situations.
> When language designers opt against the inclusion of generics in the year 2007, then you can be sure that they don't do so because they are too stupid to see the benefits of "generics", but because they also consider the downsides.
Authors of Java didn't include closures and generics despite the fact that they were aware of them. They thought that these features are too complicated for ordinary developers. Look what this lead to, we now have generics and closures, but they made the language much more complicated and hacky than it would be if they would have integrated into it from scratch.
Right now it's a fad. It will be proven or not over the course of time. But realize that unless you write in something REALLY established like C or Java you have a certain risk with any language will fall by the wayside in 5 or 10 years time.
I personally think that Python is starting to go the way of perl. It's becoming more and more of a mess (perl was a mess to start with, but that was actually touted as a benefit). The last python project I worked on had over 60 separate "pip" requirements, many with specific versions, and deploying on anything but one specific version of one specific linux distro was an exercise in pain. I realize that's just an anecdote but if python wasn't starting to get uncomfortable there would not be so much buzz around Go.
The choice between DIY and depending on third party libraries isn't exactly a language problem, unless you're saying that a language that doesn't have many third party libraries takes that choice away from you. I don't find that very convincing.
Readit News
1. They got concurrency right. Writing ostensibly blocking code and letting the runtime yield in the background is The Future.
2. Implicit interfaces and formalizing "composition over inheritance" is the right way to think about reusing functionality.
3. Deployment is stupidly easy with zero-dependency binaries.
4. The cross-compilation tool chain is dead simple. (excepting CGo)
5. The tooling around Go's handling of code (godoc, go vet, go fmt, etc) is superb. Enforcing a one-true coding style makes foreign code easier to understand.
That being said, Go is missing the expressiveness that you expect coming from higher level languages like Haskell/Python/Scala. In many cases, it is a unnecessary step backwards on the thought-to-code spectrum. Not having things like generics and list comprehensions makes my code more verbose and more difficult to understand.
Certainly Go will evolve, although the authors often seem perhaps a little too resistant to change. I suspect that Go's popular successor ten years from now will have stolen Go's best qualities and iterated faster to include the higher-level language niceties that we expect.
I have a longer blog post to expand on this later.
Everyone talks down on C++ but it's one of the few languages that gets generics right. The only language with implicit RAII (not explicit like C#/Java). The only language to put into practice 0 cost abstractions.
You mean a Go++, designed by committee with all language features known to man thrown together, ranging from meta-programming to dependent types, trying to please everyone, and as a result pleasing no one, and everybody will wish for a simpler language?
Lots of C++ programmers do NOT wish for a simpler language.
Not better enough - and no new platform to carry it unlike JS, Perl, Ruby, Python, PHP, Java (web); Objective-C, Java (mobile); Java, Ruby, Python (cloud).
The problem is that people don't like to switch. They'd prefer their present tool to improve, and they'll support that. So the only way a language can achieve ascendency is when users don't switch. That is, new users. During rapid adoption of a platform, a significant majority can be new users. And that is the only time a new language can take over.
NOTE: it may appear there's an exception with flavour-of-the-month frameworks etc, but this is a combination of rapid turnover of developers/projects in specific areas, plus the enthusiast/techie kind of developers who love to switch (the ones always excited about the newest tech for its own sake, not for its long-term practical benefits: think inventor, not investor). These developers cannot form the basis of language's future, because they will quickly switch to the next new thing.
But C++ suggests another path to language survival: present it as an "easy-to-learn" (it started that way) superset of an existing language that addresses a weakness. It's C! With classes!
The future may not be particularly interested in Go. It doesn't open interesting new research avenues. If it becomes a proverbial "100-year language", it's going to be the legacy mess that some poor soul will hate to maintain in 2110.
I'm not going to be around in 2110 and I'm not a researcher, so I like using Go.
I personally see much more of a future with Rust, since it actually has a chance of replacing C++.
It suffers a bit from the fact that dynamic languages like Python are (and will always be) nicer and more productive for hacking around in when performance is not a concern; and from the fact that you cannot (yet) beat C for (single-thread) performance.
So, if productivity is everything: use Python, or your dynamic language of choice. If performance is everything, use C (or C++, if you really must).If, on the other hand, you want a nice balance between (good-enough) productivity and (good-enough) performance, Go is a great bet.
I bet that in 10 years time, once the hype has died down, Go will be seen as a middle-of-the-road language for middle-of-the road applications. A low-risk, conservative, sensible, and ultimately boring choice.
Which is great, because that is exactly what Go is trying to achieve.
In ten years, Go will be seen as what Oberon is seen as today: essentially all the things you mention, plus the fact that there will be a dedicated community of people who like the no-nonsense "do more with less" approach that is peculiar to this family of languages and don't want to live without it. Plus, Go will most likely have some evolutionary continuation anyway.
I think it's more likely that in 10 years, Go will be the new Java. Big companies (besides Google) will use it, Hacker News will hate it, consultants will write books about it, and language geeks will be trying to replace it. Recall that Java also had a no-nonsense "do more with less" approach. The problem is that once a language gets popular, it's inevitably pushed into more and more domains where it's unsuitable, folks need to learn it to earn a living, and all the folks who define themselves by what languages they know will move on to greener pastures.
The only way a language can remain cool for decades at a time is to "avoid success at all costs", which was actually one of Simon Peyton-Jones's goals for Haskell (which has remained remarkably true to that ideal). Otherwise Stroustrop's Law kicks in: "There are two kinds of languages: the ones nobody likes, and the ones nobody uses."
List comprehensions are one of the most obvious things. LINQ and Haskell and co have shown that this is absolutely doable with a static type system.
The lack of genericity is one of those things that will be argued about for the lifetime of Go, I think. Python doesn't need it because of the dynamic typing but the same problems are solved to some extent by the compile-time-duck-typing enabled by its interface system.
I'm not sure I agree re productivity. One on project I reached 30,000 lines of Python, collaborating with 3 other people remotely. Some things would have been a lot easier with static typing. I think.
The low-risk, conservative, sensible and boring choice exists today. It's Java.
And as enterprises adopt functional programming via Scala/Clojure it will only cement those characteristics.
Go has made me enjoy programming again -- I find it very freeing not to have to use Java or .NET and memorize 40,000 builtin classes. Yes, Go is similar to Java in terms of its being a "middle of the road" conservative language. But (a)it's conservative for the 21st Century, rather than the 20th, and (b)ditching the virtual machine and bloat of Java is a good thing IMO.
For everything else no. The JVM is going to continue to dominate for medium to large apps with Scala and Clojure offering something new and original whilst allowing for existing code to be reused. And for smaller apps it's hard to look past Javascript.
It's the language which doesn't have important modern language features, like generics, and I won't ever use it unless these feature are added which is highly unlikely.
Languages like Mozilla Rust seem to me to be a more adequate replacement for C++.
Authors of Java didn't include closures and generics despite the fact that they were aware of them. They thought that these features are too complicated for ordinary developers. Look what this lead to, we now have generics and closures, but they made the language much more complicated and hacky than it would be if they would have integrated into it from scratch.
I personally think that Python is starting to go the way of perl. It's becoming more and more of a mess (perl was a mess to start with, but that was actually touted as a benefit). The last python project I worked on had over 60 separate "pip" requirements, many with specific versions, and deploying on anything but one specific version of one specific linux distro was an exercise in pain. I realize that's just an anecdote but if python wasn't starting to get uncomfortable there would not be so much buzz around Go.