7 ms·
Ask HN: Do you see the future in Go?
- Baliw 13y agoI 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=q http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...
- pavlov 13y agoI 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.
- trailfox 13y agoStatic typing + type inference is a powerful combination. Go, Scala and Rust are particularly appealing as the mix expressiveness with good performance.
- threeseed 13y agoI 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.
- drtse4 13y agoEasy 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?).
- cliveowen 13y agoIf Google were to provide an Android SDK for Go I bet the usage would grow exponentially and that would assure a bright future.
- saljam 13y agoI 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.
- jdiez17 13y agoMapping 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.
- mseepgood 13y agoIt is already growing exponentially. Did you mean Ackermann function growth?
- steeve 13y agoIt's been done: https://github.com/eliasnaur/goandroid https://github.com/eliasnaur/goandroid Hackish, but it works.
- yeukhon 13y agoDo 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.
- harel 13y agoGive 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.
- w_t_payne 13y agoGreat 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.
- gngeal 13y agoI 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.
- nostrademons 13y agoYou 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."
- Tichy 13y agoI 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/ 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.
- gatestone 13y agoHow 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 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
- Tichy 13y agoBut 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?
- mortdeus 13y agoIm pretty confident that Go will be around for at least as long as C/C++, python, and java remain relevant.
- LocalMan 13y agoIt'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...
- neals 13y agoHave 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.
- miloshadzic 13y agoIt'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.
- behrendtio 13y agoI'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.
- pymonks 13y agoCan Go, the so called future systems-language be used for writing device drivers ? if not why ?
- qznc 13y agoMandatory garbage collection. So far, no mainstream operating system includes garbage collection and there seems to be nobody who considers it a good idea. (except the Oberon guys, maybe)
- solomatov 13y agoI 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++.
- mseepgood 13y agoParametric 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.
- solomatov 13y ago> 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.
- mseepgood 13y agoThe people who designed Java are not the same who "extended" it later on.
- Zenst 13y agoYes, 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.
- deleted 13y ago[deleted]
- inconshreveable 13y agoNo, 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.
- mseepgood 13y ago> 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?
- tapank 13y agoGo 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.
- latch 13y agoI'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 http://golang.org/doc/effective_go.html
- Jare 13y agoI 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).
- 6ren 13y agoGo 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.
- nealabq 13y agoI 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!
- ams6110 13y agoRight 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.
- fauigerzigerk 13y agoThe 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.
- Mikeb85 13y agoNo, 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++.
- kibwen 13y agoC++ 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.
- trailfox 13y agoI expect Go to take a large bite out of Ruby and Python and a nibble of of Java.
- kibwen 13y agoIf 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.
- yati 13y agoI 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.
- mseepgood 13y agoDepends on your definition of "systems programming". I personally consider writing services (web servers, database servers, load balancers etc.) systems programming.
- aldanor 13y agoI 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++.
- swah 13y agoUnfortunately I don't think Facebook will invest in D anywhere as much as Google is investing in Go...
- optymizer 13y agoWhat 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.
- iand 13y agoI 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.
- marcus_holmes 13y agoyeah, 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 :)