Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges cleaned up and so forth.
Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.
So it's unsurprising that many infrastructure developers are jumping to Go. There's just enough new things to incentivize a switch, but not too much that it dissuades from it.
I'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C.
Golang feels very much like an offspring of Java and Python to me.
I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.
The problem with Go is likely a result of having the kinds of stated goals that it has. The designers of Java deliberately created a language that was for people they didn't trust. The result is a hammer that looks and works like a dildo.
So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something?
One last analogy. What would you prefer: a pilot who has been certified to fly that aircraft and has a minimum number of flight hours or giving every passenger a joystick sticking out of their seat tray so that maybe collectively they won't crash the plane?
I don't like how Go's design turnoud to be, but I surely appreciate that it means less C code and more memory safe code.
Eventually C will be squeezed into an Assembly like niche, used only for shaving out ms out of an application, kernel stuff or those little code tricks not exposed on the safe layer.
It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")
Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interface{}" tend to be needed too often. Other than that, there are few killer problems with the language when doing server-side stuff.
The libraries for doing web server type stuff are available and well debugged. When you use a Go library that came from Google, you're probably using code that's executing a few million times a second on Google servers. (As I mentioned on here a few months back, I recently ported a medium-sized production Python program from Python 2 to Python 3. I found library bugs which would have been found long ago were the code heavily used.)
So yes, Go is doomed to succeed. That's not a bad thing.
As for Rust, while I like Rust personally, it may be too complex. The borrow checker concept is brilliant, and a huge advance in understanding how to avoid a big class of bugs. We'll see that again in future languages. The type and generic system, though, pick up where C++ left off, and seem to lead library developers to develop very complex interfaces.
Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun. Go is for people who have a job to do.
That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo.
Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional. Safety is not optional. They are my job. If I opposed language features that are needed for competitive performance or safety on the grounds of complexity, I would be failing to do my job.
I'm responsible for a lot of Rust's features. I have never posted on LTU, and I've never written more than 50 lines of Haskell. I find most of the Rust community's philosophical language debates tiring and pointless; languages to me are tools, not philosophies. The entire core team is largely with me here. I think you have a deep misunderstanding of the language design if you believe Rust has features "just because".
> Rust is for people who debate language semantics on
> Lambda the Ultimate and program in Haskell for fun. Go
> is for people who have a job to do.
This is a mischaracterization of Rust to the point of incredulity. I've been talking to companies experimenting with Rust and all the engineers I've spoken to have praised Rust for its ability to let them do their jobs with confidence. These engineers are in domains where GC is intolerable and C++ is considered too much of a risk (in fact, one of my biggest surprises in this current endeavor is discovering how few people in industry will describe themselves as comfortable with C++ to the point of being willing to use it in greenfield projects with confidence). Without Rust, these companies would be forced to buy more hardware to throw hardware at the problem or hire C++ specialists to throw at the problem; fortunately Rust threads the needle and provides extreme business value.
Rust was created to solve a specific pain point. It's not some language that sprang fully-formed and perfectly-designed out of the ether. It solves problems that no other language even attempts to solve (no, Ada doesn't do what Rust does (and likewise, Rust doesn't do what Ada does)), and the mechanisms that it uses to do that took years of iteration and concerted effort on large codebases.
Not everyone needs to be working at the level that Rust does, and I think that's great. I'm a polyglot programmer myself, and I like Rust because at last there exists a language that lets me perform at the level of C with the same level of memory correctness that I expect from Python (or really, any language designed post-1995).
I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that feels like a high level one.
> C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")
Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts.
Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc support on the web. I suspect however it's popular also because it isn't FP and doesn't favor immutability. It plays well with the haters who refuse to understand how good GC/list fusion/stronger types/better abstraction can make code easier to understand and way faster.
But the bottom line is no Google, no Go. Just like no Sun, no Java. It's simply unbeatable to have a mega tech corp paying folks to write docs libs and patches. But it doesn't save it from being yet another turing tarpit.
Right, Google just needs to will something to succeed, and poof, the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success.
Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient condition.
You characterize certain language features as objectively better. Indeed, those who do not use the particular approach you advocate (FP) or the feature you desire are "haters who refuse to understand". Is this really a charitable way to look at other programmers? As people who, because they do not use your preferred language or languages, are apparently full of hatred and -- not a lack of understanding, but a _refusal_ to understand?
How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours.
Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either.
Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?
The article claims, and tries to "prove", that Go succeeds because it was designed from the very beginning to be a mainstream language, trying to stay simple enough to be accessible to most programmers. You're not discussing this in your comment.
You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point.
The paragraph about Erlang was not a "potshot". The author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.
> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community.
Very true.
This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but rather to create one that has a high enough abstraction to be productive but simple enough so that people coming from different backgrounds can acquaint themselves with it quickly.
I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems.
I really like it.
To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.
Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.
This is sort of the conclusion I've come to in the last few weeks as I think about and research in preparation for my next startup. I learned to code with C / Perl in the late 90's, moved to scripted/interpreted "web" languages like ColdFusion, PHP, RoR, JS, and about a year ago I finally decided to build a toy project with Go for Google App Engine. I found the process really instructional, but ultimately pretty frustrating. I fall very much into the author's second camp; it's not the language for me, for what I want to use it for. I'm building a pure web app, with very little systems orchestration need (outside standard devops). Go seems like a great fit for building Docker, but a poor fit for building AirBnB. Especially at first, when I'm likely to be the only programmer for 12-18 months, it seems to me that Go is a poor choice to begin with. It loads too much technical debt (probably the wrong term) onto our startup at a time when we need to move fast and break things. If we are hugely successful and we end up with 20 programmers in 3-5 years, then maybe it'll be time to re-architect key microservices in golang. Until then, I think RoR makes the most sense for us.
I've been looking for someone to verbalize this train of thought for a few weeks.
I keep wondering whether the lack of generics is in part intended to make people not even try and implement Hibernate but to accept using a lower level of abstraction instead.
>To understands why Go is the way it is you need to know why it came to exist in the first place: "The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source"
The problem with this idea is that, for the exact same goals, there could be a much better design for the language and much better implementation of various details.
You don't need to be Haskell or anything. Just Go + generics for example would result in a much cleaner language (no special casing for things like "make" for example), a vastly improved code library and data structures story, etc. This horse has of course been beaten to death (including by people working extensively with Go, so it's not like some "outsider's misconception" as some dismiss it).
If Go succeeds is because noone else with the same kind of visibility and resources tried to compete in this space (easy concurrency, static builds, fast compiles, static, fast-ish, decent batteries included etc).
You have e.g. Rust which is incomplete and too complex, Nim which is too niche, from very small vendor (a guy) and has some bizarro ideas, and that's pretty much it. That said, Swift might make a dent in this area when its Open Sourced if it has nice tooling.
>Many critics I find though, fall into the second bucket. The answer to those critics is always the same: “Go is just not for you”. Some people see this attitude as stubbornness from the community, aversion to improve which will doom Go in the long run. They just don’t realize that some people want different things.
This trivializes all critique to "to each his own".
That some people "want different things" doesn't mean all things people want are equally valid.
Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn't require warmup and can be delivered as a single native binary -- but I just can't think of giving up the JVM's deep monitoring, low-overhead deep profiling[1], polyglotism[2], dynamic code loading and hot-swapping, and the awesome hacking power that comes with runtime bytecode manipulation[3] for long-running, important server applications.
[1]: Java Flight Recorder is the most powerful low-overhead profiler I've ever seen.
[2]: We use Java, Kotlin and Clojure all in the same project.
[3]: The ability to inject ad-hoc tracing code into your server and then take it out -- all while the server is running at full speed -- or to shadow binary dependencies so they don't clash, or to use (or write) a time-travelling debugger is like having magic powers. Bytecode manipulation is ultimate hackability.
Without a definition of "succeed", this cannot be argued against or agreed to. Like every other language, Go will be used by some people and not used by other people.
Go's success has me confused. My team enjoys using Go, but to me it feels like i'm a prisoner. The designer's slavishly followed opinions are laser focused on reducing variation across go codebases. There's definitely less to learn than most languages. Unfortunately, sometimes the blessed way of doing things doesn't work well for your problem and not only are you left with a hammer to cut the wood, but making a saw is outlawed.
The article hits on this but doesn't bring up Google's high turnover rate.
Google is a resume tick box. Go over to AngelList and look at lists of startups. Take a drink every time you see 'worked at Google' listed as a qualification. You'll be destroyed in an hour or so.
Thus people get jobs at Google, put in a year or two, and go off for a higher paying and/or sexier job or a startup of their own.
Go is laser focused on simplicity, maintainable code bases, and uniformity to allow the next crop of Valley recruits to pick up where the last crop left off.
What a strange idea. The whole point of a programming language is to enable abstraction. I suppose assembler doesn't let you "abstract yourself in the foot" (whatever that means) either.
>TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community.
I think this premise could not be more wrong. The open source community is not a project team, and open source project teams are very likely much more homogenous and stable than teams working on commercial software.
Yes there may be non core contributors, but if contributions are not up to standard, they are simply rejected. If that means slower progress an open source project can live with that. A commercial project can not, because it has deadlines.
It's an interesting language test, of how easy it is to understand an open source project.
Looking at github, the lines of code are usually easy to understand in C and java. What's difficult is how the parts of the project fit together (which is never documented). Does Go help with that?
I think it can help with that in the sense that Go packages don't have complex boundaries and the type system is simple and self-contained. You don't have to trace an inheritance hierarchy to understand any given type, so a project of multiple packages is generally easy to understand just by reading each piece independently.
This got downvoted but I think there's more truth here than on much of the rest of the thread, though I might use words other than "engineering" and "craft". I'm fond of saying that Golang isn't a particularly great programming language, but is one of the great programming tools.
I highly recommend replacing any occurrence of, “Go is just not for you”, with "Go is probably not the right tool for what you're trying to do."
The former can seem, snide or condescending, even when that is 100% not the intent.
I write both C++ and C# frequently. I love both languages. But I deal with people who use either language exclusively and continually gripe about the other. And the proper response is, "it's probably just not the right tool for the thing you're trying to do."
> accept that they won’t change anything. The Go team has said time and again that the language is done for the foreseeable future. You are too late to the party. Some might cry about this, but this stability promise brings more long term benefits than any language improvement could. Breaking changes, even if for the better, are not always welcome
The promise of stability from a large software corp puts in place a solid language foundation people can rely on when building apps in the language. Someone building a successful app using the language shouldn't be able to dictate future changes to the language based on their own needs only, ignoring smaller or less popular apps. Golang's language spec is a big help with this.
When you've tried working with a language whose backers cancel work on a spec for 10 years, then tailor the language's functionality for the one application they themselves are building, you appreciate the promise of stability. When the language's backers open up their AST to programmer addons via annotations, then later duplicate the functionality of the most popular addon, you appreciate the backing company's understanding that long term benefits come from nurturing the community.
When you see a backing company suddenly retrench all the staff working on a programming language, you appreciate that Google is using Golang internally and is unlikely to do the same. Although Golang was born of a Google internal need, let's hope the needs of their own systems won't dictate future changes at the expense of the external community, and that they keep their stability promise.
"TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community."
This would almost be right, but Go has much poorer language interop than C due to the GC and non-C compatible ABI. This means unless we're going to a monoculture of GoAllTheThings (not likely), Go will never succeed C as being the basis of fundamental open source community projects.
For myself, I was and remain mildly interested in Go as my next move off of Python(2). And still believe Go is a better move than porting to Python3- which as an aside makes no sense technically, but the coercion/threats from the Python3istas are beyond reproach (as if the existing Python2 community is the problem), and set me solidly against it.
Of this new generation of languages, Swift was always my ideal. Both in language and implementation. Now that it's going to the server I can't help but find the attraction of serverside Swift and getting in on the groundfloor of that ecosystem. While gaining skills in the language of iOS to be irresistible.
[+] [-] vezzy-fnord|10 years ago|reply
Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.
So it's unsurprising that many infrastructure developers are jumping to Go. There's just enough new things to incentivize a switch, but not too much that it dissuades from it.
[+] [-] tptacek|10 years ago|reply
Golang feels very much like an offspring of Java and Python to me.
[+] [-] aaggarwal|10 years ago|reply
[+] [-] nickbauman|10 years ago|reply
So we're likely headed to where the commensurate Go analogy to Java is a hammer that looks and works like a catheter or something?
One last analogy. What would you prefer: a pilot who has been certified to fly that aircraft and has a minimum number of flight hours or giving every passenger a joystick sticking out of their seat tray so that maybe collectively they won't crash the plane?
Oh, and you kids get off my lawn (waves cane)! ;)
[+] [-] pjmlp|10 years ago|reply
Eventually C will be squeezed into an Assembly like niche, used only for shaving out ms out of an application, kernel stuff or those little code tricks not exposed on the safe layer.
[+] [-] Dewie3|10 years ago|reply
[deleted]
[+] [-] Animats|10 years ago|reply
Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interface{}" tend to be needed too often. Other than that, there are few killer problems with the language when doing server-side stuff.
The libraries for doing web server type stuff are available and well debugged. When you use a Go library that came from Google, you're probably using code that's executing a few million times a second on Google servers. (As I mentioned on here a few months back, I recently ported a medium-sized production Python program from Python 2 to Python 3. I found library bugs which would have been found long ago were the code heavily used.)
So yes, Go is doomed to succeed. That's not a bad thing.
As for Rust, while I like Rust personally, it may be too complex. The borrow checker concept is brilliant, and a huge advance in understanding how to avoid a big class of bugs. We'll see that again in future languages. The type and generic system, though, pick up where C++ left off, and seem to lead library developers to develop very complex interfaces.
Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun. Go is for people who have a job to do.
[+] [-] pcwalton|10 years ago|reply
Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional. Safety is not optional. They are my job. If I opposed language features that are needed for competitive performance or safety on the grounds of complexity, I would be failing to do my job.
I'm responsible for a lot of Rust's features. I have never posted on LTU, and I've never written more than 50 lines of Haskell. I find most of the Rust community's philosophical language debates tiring and pointless; languages to me are tools, not philosophies. The entire core team is largely with me here. I think you have a deep misunderstanding of the language design if you believe Rust has features "just because".
[+] [-] kibwen|10 years ago|reply
Rust was created to solve a specific pain point. It's not some language that sprang fully-formed and perfectly-designed out of the ether. It solves problems that no other language even attempts to solve (no, Ada doesn't do what Rust does (and likewise, Rust doesn't do what Ada does)), and the mechanisms that it uses to do that took years of iteration and concerted effort on large codebases.
Not everyone needs to be working at the level that Rust does, and I think that's great. I'm a polyglot programmer myself, and I like Rust because at last there exists a language that lets me perform at the level of C with the same level of memory correctness that I expect from Python (or really, any language designed post-1995).
[+] [-] neverminder|10 years ago|reply
[+] [-] serge2k|10 years ago|reply
Which is why Java gets used instead.
[+] [-] codygman|10 years ago|reply
What about the people who program in Haskell for work?
> Go is for people who have a job to do.
People use Go for fun.
[+] [-] reagency|10 years ago|reply
[+] [-] octatoan|10 years ago|reply
Very smooth. /s
[+] [-] ngrilly|10 years ago|reply
Which ones?
[+] [-] ads_are_shite|10 years ago|reply
[deleted]
[+] [-] biggerbob|10 years ago|reply
[deleted]
[+] [-] spopejoy|10 years ago|reply
Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts.
Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc support on the web. I suspect however it's popular also because it isn't FP and doesn't favor immutability. It plays well with the haters who refuse to understand how good GC/list fusion/stronger types/better abstraction can make code easier to understand and way faster.
But the bottom line is no Google, no Go. Just like no Sun, no Java. It's simply unbeatable to have a mega tech corp paying folks to write docs libs and patches. But it doesn't save it from being yet another turing tarpit.
[+] [-] freyr|10 years ago|reply
Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient condition.
[+] [-] muraiki|10 years ago|reply
How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours.
Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either.
Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?
[+] [-] ngrilly|10 years ago|reply
You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point.
The paragraph about Erlang was not a "potshot". The author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.
[+] [-] gamesbrainiac|10 years ago|reply
Very true.
This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but rather to create one that has a high enough abstraction to be productive but simple enough so that people coming from different backgrounds can acquaint themselves with it quickly.
In other words, it is a language for teams.
[+] [-] latch|10 years ago|reply
I really like it.
To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.
Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.
[+] [-] jhardcastle|10 years ago|reply
I've been looking for someone to verbalize this train of thought for a few weeks.
[+] [-] mst|10 years ago|reply
[+] [-] jjawssd|10 years ago|reply
[+] [-] yo-code-sucks|10 years ago|reply
[deleted]
[+] [-] coldtea|10 years ago|reply
The problem with this idea is that, for the exact same goals, there could be a much better design for the language and much better implementation of various details.
You don't need to be Haskell or anything. Just Go + generics for example would result in a much cleaner language (no special casing for things like "make" for example), a vastly improved code library and data structures story, etc. This horse has of course been beaten to death (including by people working extensively with Go, so it's not like some "outsider's misconception" as some dismiss it).
If Go succeeds is because noone else with the same kind of visibility and resources tried to compete in this space (easy concurrency, static builds, fast compiles, static, fast-ish, decent batteries included etc).
You have e.g. Rust which is incomplete and too complex, Nim which is too niche, from very small vendor (a guy) and has some bizarro ideas, and that's pretty much it. That said, Swift might make a dent in this area when its Open Sourced if it has nice tooling.
[+] [-] coldtea|10 years ago|reply
This trivializes all critique to "to each his own".
That some people "want different things" doesn't mean all things people want are equally valid.
[+] [-] pron|10 years ago|reply
[1]: Java Flight Recorder is the most powerful low-overhead profiler I've ever seen.
[2]: We use Java, Kotlin and Clojure all in the same project.
[3]: The ability to inject ad-hoc tracing code into your server and then take it out -- all while the server is running at full speed -- or to shadow binary dependencies so they don't clash, or to use (or write) a time-travelling debugger is like having magic powers. Bytecode manipulation is ultimate hackability.
[+] [-] xyby|10 years ago|reply
[+] [-] modulus1|10 years ago|reply
[+] [-] api|10 years ago|reply
Google is a resume tick box. Go over to AngelList and look at lists of startups. Take a drink every time you see 'worked at Google' listed as a qualification. You'll be destroyed in an hour or so.
Thus people get jobs at Google, put in a year or two, and go off for a higher paying and/or sexier job or a startup of their own.
Go is laser focused on simplicity, maintainable code bases, and uniformity to allow the next crop of Valley recruits to pick up where the last crop left off.
[+] [-] dawkins|10 years ago|reply
[+] [-] jamesfisher|10 years ago|reply
[+] [-] myg204|10 years ago|reply
[+] [-] fauigerzigerk|10 years ago|reply
I think this premise could not be more wrong. The open source community is not a project team, and open source project teams are very likely much more homogenous and stable than teams working on commercial software.
Yes there may be non core contributors, but if contributions are not up to standard, they are simply rejected. If that means slower progress an open source project can live with that. A commercial project can not, because it has deadlines.
[+] [-] hyperpallium|10 years ago|reply
Looking at github, the lines of code are usually easy to understand in C and java. What's difficult is how the parts of the project fit together (which is never documented). Does Go help with that?
[+] [-] dsymonds|10 years ago|reply
[+] [-] orian|10 years ago|reply
[+] [-] sapek|10 years ago|reply
[+] [-] tptacek|10 years ago|reply
[+] [-] rwmj|10 years ago|reply
[+] [-] gtrubetskoy|10 years ago|reply
[+] [-] lohengramm|10 years ago|reply
[+] [-] nobullet|10 years ago|reply
[+] [-] DubiousPusher|10 years ago|reply
The former can seem, snide or condescending, even when that is 100% not the intent.
I write both C++ and C# frequently. I love both languages. But I deal with people who use either language exclusively and continually gripe about the other. And the proper response is, "it's probably just not the right tool for the thing you're trying to do."
[+] [-] vorg|10 years ago|reply
The promise of stability from a large software corp puts in place a solid language foundation people can rely on when building apps in the language. Someone building a successful app using the language shouldn't be able to dictate future changes to the language based on their own needs only, ignoring smaller or less popular apps. Golang's language spec is a big help with this.
When you've tried working with a language whose backers cancel work on a spec for 10 years, then tailor the language's functionality for the one application they themselves are building, you appreciate the promise of stability. When the language's backers open up their AST to programmer addons via annotations, then later duplicate the functionality of the most popular addon, you appreciate the backing company's understanding that long term benefits come from nurturing the community.
When you see a backing company suddenly retrench all the staff working on a programming language, you appreciate that Google is using Golang internally and is unlikely to do the same. Although Golang was born of a Google internal need, let's hope the needs of their own systems won't dictate future changes at the expense of the external community, and that they keep their stability promise.
[+] [-] aroman|10 years ago|reply
What a brilliant sentence.
[+] [-] BuckRogers|10 years ago|reply
This would almost be right, but Go has much poorer language interop than C due to the GC and non-C compatible ABI. This means unless we're going to a monoculture of GoAllTheThings (not likely), Go will never succeed C as being the basis of fundamental open source community projects.
For myself, I was and remain mildly interested in Go as my next move off of Python(2). And still believe Go is a better move than porting to Python3- which as an aside makes no sense technically, but the coercion/threats from the Python3istas are beyond reproach (as if the existing Python2 community is the problem), and set me solidly against it. Of this new generation of languages, Swift was always my ideal. Both in language and implementation. Now that it's going to the server I can't help but find the attraction of serverside Swift and getting in on the groundfloor of that ecosystem. While gaining skills in the language of iOS to be irresistible.
Count me in as one eager for Swift 2.0. I believe Swift is the language that is doomed to succeed. http://www.tiobe.com/index.php/content/paperinfo/tpci/index....