Ask HN: Do you see the future in Go?
29 comments
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.
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.
> I suspect that Go's popular successor
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?
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?
Go is to C as plan 9 is to unix.
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.
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!
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.
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++.
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.
I expect Go to take a large bite out of Ruby and Python and a nibble of of Java.
If you've already chosen Ruby over Python then you're probably a big fan of the sort of expressiveness that Go eschews, so I doubt that very many Rubyists will flock to Go. I expect Ruby devs who want speed and concurrency to make an attempt at Scala first.
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.
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.
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 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."
You really think so? I think that implies that it remains unsuccessful, which (given its current trajectory) seems unlikely.
Oops. I meant "seen technically", not "seen socially".
I think it's more likely that in 10 years, Go will be the new Java.
I'd rather think of Go as the new C. :-)
Also, as far the "do more with less" and "no nonsense" stuff is concerned - have you seen the spec of Java on one side, and the specs for Go and Oberon on the other? There's quite some difference.
Oops. I meant "seen technically", not "seen socially".
I think it's more likely that in 10 years, Go will be the new Java.
I'd rather think of Go as the new C. :-)
Also, as far the "do more with less" and "no nonsense" stuff is concerned - have you seen the spec of Java on one side, and the specs for Go and Oberon on the other? There's quite some difference.
C is very successful and barely hated (C, not C++).
I like C, but I also like the type-safe, efficient containers and generic algorithms of C++.
In many ways, the containers and generic algorithms of C++ may not be necessarily that efficient: http://datadraw.sourceforge.net
Yeah, C and to some extent Python seem to be exceptions to Stroustrop's Law. There was a poll on this recently:
https://news.ycombinator.com/item?id=6527104
My pet theory on why is that both of these languages didn't try to be middle-of-the-road, good-for-everything languages, they were created to solve a specific problem and were very well designed for that niche. So programmers use C for systems programming and when they need to be close to the metal, they don't use it for large applications with ambiguous requirements - and so all the hate that the latter engenders gets directed to C++ and Java. And programmers use Python when they need to prototype stuff, script things, or write a quick tool where performance doesn't matter - and when performance does matter, they either end up calling out to C (which is actually good for that) or they end up rewriting in Java and cursing out that language.
https://news.ycombinator.com/item?id=6527104
My pet theory on why is that both of these languages didn't try to be middle-of-the-road, good-for-everything languages, they were created to solve a specific problem and were very well designed for that niche. So programmers use C for systems programming and when they need to be close to the metal, they don't use it for large applications with ambiguous requirements - and so all the hate that the latter engenders gets directed to C++ and Java. And programmers use Python when they need to prototype stuff, script things, or write a quick tool where performance doesn't matter - and when performance does matter, they either end up calling out to C (which is actually good for that) or they end up rewriting in Java and cursing out that language.
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.
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?)
type(3 * 5) => int
type(3.0 * 5) => float
type(3 * 'foo') => string
type(3.0 * 'foo') => TypeErrorIsn't operator type can be defined using 2 parts:
1. What object calls the operator relevant method
2. Looking at the code of the relevant operator call, we'll see something like if type(obj)==str , do X . so depending on the type of obj , we can deduce output type automatically .
Another option is to use the approach mypy uses: let the language mix static type and dynamic type freely, and if we cannot determine type, let the code by dynamic , with the relevant warning .
Yes mypy isn't written yet, but it would be interesting to see how useful this approach would be.
1. What object calls the operator relevant method
2. Looking at the code of the relevant operator call, we'll see something like if type(obj)==str , do X . so depending on the type of obj , we can deduce output type automatically .
Another option is to use the approach mypy uses: let the language mix static type and dynamic type freely, and if we cannot determine type, let the code by dynamic , with the relevant warning .
Yes mypy isn't written yet, but it would be interesting to see how useful this approach would be.
There are a few big problems with that...
The first is that multiplication is...well, not always commutative in Python, but it has two operands and either of them can be the method receiver. For example:
The other problem is that you cannot in general determine the type of an expression by inspecting code, unless you apply some rules to the legal expressions in the language. For example, take this code fragment:
I suspect that any working solution involves some sort of constraint solver that gathers up all the constraints, simplifies them, determines if they're compatible, and then outputs a list of possible types it could be, each subject to certain assumptions on the input types.
The first is that multiplication is...well, not always commutative in Python, but it has two operands and either of them can be the method receiver. For example:
type(5 * 3) => int
type(5 * 3.0) => float
type('foo' * 3) => string
type('foo' * 3.0) => TypeError
The other problem is that you cannot in general determine the type of an expression by inspecting code, unless you apply some rules to the legal expressions in the language. For example, take this code fragment:
def foo(fn):
if typecheck.static_type(fn) == int:
return 'a string'
else:
return 0
I suspect that any working solution involves some sort of constraint solver that gathers up all the constraints, simplifies them, determines if they're compatible, and then outputs a list of possible types it could be, each subject to certain assumptions on the input types.
Again i'm missing the problem.
If typecheck.static_type evaluates type on an object , typecheck.static_type(foo) returns type 'function'. And our function will return 0 , meaning type == int.
if typecheck.static_type does something else , more complex , we could always tell our tool that fn is dynamic.
If typecheck.static_type evaluates type on an object , typecheck.static_type(foo) returns type 'function'. And our function will return 0 , meaning type == int.
if typecheck.static_type does something else , more complex , we could always tell our tool that fn is dynamic.
typecheck.static_type is supposed to give you the full type of the object - not just 'function', but 'function(int) -> int'. Or I guess I in this case I was just looking at the return type, so 'int'. Hence the problem - foo is defined so that if its type is int, it returns a string, while if its type is string, it returns an int.
The problem with giving up and returning 'dynamic' is that dynamics tend to propagate through the code if you're doing anything moderately complex. If we give up, then any expression that calls foo() now typechecks as 'dynamic', and any expression that calls one of them typechecks as 'dynamic', and so on. You end up with a typechecker that doesn't tell you anything useful about your program, other than that it was dynamically typed.
If this is restricted to a few special cases like, say, Django ORM classes or namedtuple, it's not a huge problem, because you can hardcode in specific rules for them (or put in a plugin mechanism). But tricky typing rules abound even in the basic language features; as mentioned above, multiplication does not even have concisely expressible typing rules in Python.
The problem with giving up and returning 'dynamic' is that dynamics tend to propagate through the code if you're doing anything moderately complex. If we give up, then any expression that calls foo() now typechecks as 'dynamic', and any expression that calls one of them typechecks as 'dynamic', and so on. You end up with a typechecker that doesn't tell you anything useful about your program, other than that it was dynamically typed.
If this is restricted to a few special cases like, say, Django ORM classes or namedtuple, it's not a huge problem, because you can hardcode in specific rules for them (or put in a plugin mechanism). But tricky typing rules abound even in the basic language features; as mentioned above, multiplication does not even have concisely expressible typing rules in Python.
No. In 10 years time it will sadly be forgotten like many of Google's experiments.
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.
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.
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.
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 don't think it's the fault of the VM. There have been other languages that worked with intermediate code, and they weren't inefficient. It's just that fixing old stuff after you get millions of users leaves you with a very strange language, even a stranger one than if you add completely new stuff along the way. The latter is inevitable, but the former ought to be avoided. The Java people probably didn't realize in the beginning what they were building. (Well, of course, who would have, in their place?)
I think enterprises will rather adopt functional programming via Java.
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.
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++.
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.
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.
The people who designed Java are not the same who "extended" it later on.
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.
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.
I kind of gave up on it when I realized how complicated it is to sort a list. Hopefully they'll improve that in future versions.
Still could see myself using it for specific use cases.
But for the future I'd wish for something cooler to win :-)
Edit: check out the sort module and decide for yourself http://golang.org/pkg/sort/
It has some interesting, if confusing, properties. But why not just let me write
list.sort(function(a,b){ return 1, 0 or -1...}) like JavaScript does?
While the examples in the sort module are perhaps more generic than necessary (hence the interesting but confusing properties), any sort still requires the definition of 3 functions, and they can't be defined inline (on the fly) either, afaik.
Still could see myself using it for specific use cases.
But for the future I'd wish for something cooler to win :-)
Edit: check out the sort module and decide for yourself http://golang.org/pkg/sort/
It has some interesting, if confusing, properties. But why not just let me write
list.sort(function(a,b){ return 1, 0 or -1...}) like JavaScript does?
While the examples in the sort module are perhaps more generic than necessary (hence the interesting but confusing properties), any sort still requires the definition of 3 functions, and they can't be defined inline (on the fly) either, afaik.
How is it complicated to sort a list? The only challenge is to provide a corresponding swap function for your list (or for any ordinal "collection" you need), like in this example for arrays, when it is trivial:
func (s Organs) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
http://golang.org/pkg/sort/#example_Interface
Also note two things:
- This is the efficient and type safe way to handle polymorphism in Go
- The standard packages documentation is very nice with live, runnable examples
func (s Organs) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
http://golang.org/pkg/sort/#example_Interface
Also note two things:
- This is the efficient and type safe way to handle polymorphism in Go
- The standard packages documentation is very nice with live, runnable examples
But you also have to implement Len() and Less(), don't you?
Maybe you can create a better way, but it is not implemented in the sort package by default.
Also I suppose you need to "convert" your list to some other type with the said functions provided (dervied from the standard go lists, forgot the name). Maybe that is a standard go mechanism, but it still amounts to more lines of code.
Maybe complicated is the wrong word, longwinded might be better?
Maybe you can create a better way, but it is not implemented in the sort package by default.
Also I suppose you need to "convert" your list to some other type with the said functions provided (dervied from the standard go lists, forgot the name). Maybe that is a standard go mechanism, but it still amounts to more lines of code.
Maybe complicated is the wrong word, longwinded might be better?
Easy to use and learn, good standard library, it gets the work done.
Does it have a future outside google? I'd say yes, even in the enterprise world, mostly in mixed architectures where it could be used to build a lower layer that handles networking/transaction processing/jobs handling (replacing python,ruby,etc...) while upper layers could be built with a functional language (based on the jvm? clojure?).
Does it have a future outside google? I'd say yes, even in the enterprise world, mostly in mixed architectures where it could be used to build a lower layer that handles networking/transaction processing/jobs handling (replacing python,ruby,etc...) while upper layers could be built with a functional language (based on the jvm? clojure?).
I think it will stand the test of time. The simplicity and explicitness of its syntax means anyone can understand a Go program within minutes. That's going to be a huge positive for code maintenance in situations where the original application team has moved on and code has to be maintained by 2nd or 3rd generation programmers.
I wish Go was not just a "server language". I know you can write command line apps and there are opengl bindings and SDL and other GUI and client-y things, but that side doesn't get enough attention and in my experience has been very inconvenient (good luck if you're on windows).
I don't see much future in Go either -- unless Google takes some steps to promote a certain niche for it like Android integration (which they most likely won't).
Since someone mentioned Python here.. my go-to language has always been Python lately, but large Python projects tend to often converge into a wtf mess; and there's also all kinds of performance issues... I've recently (to my shame) discovered D language which is kinda like C/C++ on steroids without all the ugliness and verbosity, with a mix of Scala/Python. Type inference, concurrency, first class functions/arrays/maps, runtime reflections, mixing, templating, compile-time evaluation, it's got it all. Kinda like Go, it also falls inbetween C++ and Python, but much closer to C++.
Since someone mentioned Python here.. my go-to language has always been Python lately, but large Python projects tend to often converge into a wtf mess; and there's also all kinds of performance issues... I've recently (to my shame) discovered D language which is kinda like C/C++ on steroids without all the ugliness and verbosity, with a mix of Scala/Python. Type inference, concurrency, first class functions/arrays/maps, runtime reflections, mixing, templating, compile-time evaluation, it's got it all. Kinda like Go, it also falls inbetween C++ and Python, but much closer to C++.
Unfortunately I don't think Facebook will invest in D anywhere as much as Google is investing in Go...
Give it a go (excuse the pun). I did a small project using Go, and I was surprised to see how easy it was to pick up and just roll with it. The syntax makes it feel like you're writing in C and therefore your muscles harden expecting direct impact and physical harm, but its all a rather pleasant experience. So after trying it, reading other people's experiences with it and seeing who is currently using it in production - I'd say its got a potential of a bright future.
Yes, pedegree aside it I see many old and new programmers loving it.
Now if I was Google I would be seriously looking at getting it into the android ecosystem so people can develop in GO as well as C for low level system codeing above the abilities of java on android.
That said I'm a shell prompt type of chap and with that somewhat biased and blinkered in languages that you can code in vi. Certainly visual programming interfaces will have there day one day. After all much code is down to string libarys together and then stringing those functions/modules together until your pretty much coding lego style using off the shelf bricks with rare occasions of custom bricks being needed. That is still a way off from mainstream acceptance and closest break out into mainstream would of been the old mac card stack system (which was neat in its days though well dated now).
So methods and approaches to coding change over time and languages adapt and some better designed to handle changes. C been good and the same could be said for GO by definition.
But another way to look at this is what out of COBOL or GO will be around in years from now and you then get down to the main crux - is it used in production and needing code to be maintained and with that yes it is. Though different area's and platforms GO easily available for and known are different from COBOL (mainframe legacy bias) systems. If you asked a Linux dev to install GO then they would just do it, ask them to do the same with COBOL and they will be hitting google with a bewildered face. Yet both exist and are available, just different mentalities keep them going.
Now if I was Google I would be seriously looking at getting it into the android ecosystem so people can develop in GO as well as C for low level system codeing above the abilities of java on android.
That said I'm a shell prompt type of chap and with that somewhat biased and blinkered in languages that you can code in vi. Certainly visual programming interfaces will have there day one day. After all much code is down to string libarys together and then stringing those functions/modules together until your pretty much coding lego style using off the shelf bricks with rare occasions of custom bricks being needed. That is still a way off from mainstream acceptance and closest break out into mainstream would of been the old mac card stack system (which was neat in its days though well dated now).
So methods and approaches to coding change over time and languages adapt and some better designed to handle changes. C been good and the same could be said for GO by definition.
But another way to look at this is what out of COBOL or GO will be around in years from now and you then get down to the main crux - is it used in production and needing code to be maintained and with that yes it is. Though different area's and platforms GO easily available for and known are different from COBOL (mainframe legacy bias) systems. If you asked a Linux dev to install GO then they would just do it, ask them to do the same with COBOL and they will be hitting google with a bewildered face. Yet both exist and are available, just different mentalities keep them going.
If Google were to provide an Android SDK for Go I bet the usage would grow exponentially and that would assure a bright future.
I see this request very frequently, but I wonder how feasible it really is. The Android API is very Javasque, a 1:1 mapping to Go would just be unnatural.
Or are you suggesting they rewrite the API for Go? My knowledge of the internals of the Java parts of Android is limited, so I could be wrong, but that feels like a huge task.
Or are you suggesting they rewrite the API for Go? My knowledge of the internals of the Java parts of Android is limited, so I could be wrong, but that feels like a huge task.
Mapping a Javaesque (strange word, but I know what you mean) is not super hard. Encapsulate the Java stuff as opaque pointers and provide a functions that act on the objects. I actually think you could represent the Android API as a Go API fairly elegantly, although it would require a fair amount of glue code with some nontrivial hooks into the Go runtime.
It is already growing exponentially. Did you mean Ackermann function growth?
It's been done: https://github.com/eliasnaur/goandroid
Hackish, but it works.
Hackish, but it works.
What I don't think has been mentioned so far is the Go Library. You get a lot out of the box: encryption, archiving, web server, json/xml/etc, arg parser, md5/sha1 hashing, templates, POSIX and trivial concurrency!
Channels and blocking until a result is ready is really a big plus.
Overall, I am very pleased with switching from Node.js to Go, but YMMV.
Channels and blocking until a result is ready is really a big plus.
Overall, I am very pleased with switching from Node.js to Go, but YMMV.
I think a lot of people are beginning to see a bright future for Go.
Word seems to be spreading. There's certainly a growing interest.
http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...
Word seems to be spreading. There's certainly a growing interest.
http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...
I'd say go does have a future. I'm a long time php developer who switched over to ruby a while ago and I've to say that go is pretty nice, even coming from a ruby background.
The syntax might look weird in the first place, but once you get used to it, it's actually somewhat sexy, given the fact it's compiled and statically typed.
Since go has a very good solution for concurrency, compiling takes seconds and it's already adopted in a few well known companies besides google (heroku, canonical, shopify and more), I think it will gain even more traction (already under top 20 languages on github).
Plus: The standard library is very impressive and huge. You can build many different web apps and daemons without any external library involved.
I kinda miss class based inheritance tho.
The syntax might look weird in the first place, but once you get used to it, it's actually somewhat sexy, given the fact it's compiled and statically typed.
Since go has a very good solution for concurrency, compiling takes seconds and it's already adopted in a few well known companies besides google (heroku, canonical, shopify and more), I think it will gain even more traction (already under top 20 languages on github).
Plus: The standard library is very impressive and huge. You can build many different web apps and daemons without any external library involved.
I kinda miss class based inheritance tho.
I think people will(I would) use Go more for writing services than doing actual systems programming. It is a very nice language and I hope it succeeds, but I am personally betting for Rust.
Depends on your definition of "systems programming". I personally consider writing services (web servers, database servers, load balancers etc.) systems programming.
It's probably the best language for writing small unix programs. I personally, wouldn't write very large software in it but obviously there's a lot of people doing just that. It's statically typed with a rather simple type system and doesn't do functional programming very well. Those things aren't appealing to me. What it has is a great toolchain, fast compilation and is a lot like a nicer C.
Do you see a future in Perl in 2006, 2007? Apparently people are taking it seriously again (think DuckDuck Go). I can't tell but I think it has a good promise. The language has been out like three years and many HN posts have been on migrating to Go from X language. I probably will be skeptical about Rust. It won't be stable for another year or two and the adoption will probably be slower.
It's easier to evaluate the language than to predict human behaviour.
The language is very good and has excellent support and libraries.
People, though, are somewhat mysterious...
The language is very good and has excellent support and libraries.
People, though, are somewhat mysterious...
Im pretty confident that Go will be around for at least as long as C/C++, python, and java remain relevant.
yeah, I do see a future in it. Love coding in it, it solves all the problems I have without the learning cliff usually required.
I think the direction for Go is shown by the fact it doesn't have a UI library, but has a really easy route to making web servers: it's a language for writing servers in, and html/js is the UI.
The only other language I can see threatening this space is Rust, though obviously the corporate boys will carry on coding in Java and there's always going to be a ton of old C/C++ code kicking around that needs maintaining.
But language choice is personal. I'm really enjoying coding in Go, but I get why others prefer other languages. Diversity is good, we get better results that way :)
Have been using it as a tool for parsing and generating content for our game engine. I can parse all the vertices and polygons in our entire game world in under 22 seconds where our other toolchain required 10+ minutes.
We will be using GO in our toolchain in the future aswell.
We will be using GO in our toolchain in the future aswell.
Go lang will reach a tipping point when a good book becomes available for newbies to learn this language. Yes, fewer programmers read books these days, but a good book does get a lot of readers, and helps spur adoption of a language.
I've considered it, but I find Effective Go (1) a more than adequate introduction. It's never been clear to me what I'd add on top of it. The Little GoLang Book? Meh.
(1) - http://golang.org/doc/effective_go.html
(1) - http://golang.org/doc/effective_go.html
[deleted]
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.