Google’s Go has some coders raving
arstechnica.com
arstechnica.com
1) created for people less smart than the designers (even if not intentionally: maybe Gosling and Pike really do believe that generics and HOF are too difficult for the average programmer)
2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java. I guess it remains to be seen if Go will have added as many features in 15 years time as Java has in the last 15.
I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
Am I supposed to infer some opinion from you on that? I'm not sure if you were just summarizing or have a fundamental disagreement with the stance, which you thought would be self evident.
"I don't mean to boast, but I'm awesome" would be a similar statement. Trying to defeat criticism by deflecting the critique at the root, while actually fulfilling said critique is a common argumentative tactic that, while noble in its attempts to avoid offense, is intellectually dishonest.
The designers are not omniscient, and their desires mean nothing in the real world, beyond how the product of their will is actually used.
All that's just a long winded way of saying that who it's made for and who finds good use out of it are not entirely equivalent. As such the tptacek's statement seemed very neutral to me.
He will use the best language for the problem/domain at hand.
Even if OP is right and GO is a "simpler" language than others, if it allows to solve a range of problems without the added mental load required by, say, C++ why should't he use it ?
Since sharing source code with as wide an audience of programmers as possible will almost always bring increased value to your system, then using a language that can be widely understood and modified safely makes it the best language for the problem/domain at hand.
I can agree with that. I also believe that using a simple tool does not presuppose simple outcomes. To me the rewording looked like a fairly neutral assessment of a few language features.
What I was fishing for was if there was some positive of negative opinion behind them and what it was driven by. Without that the comment seemed fairly useless, and I'm fairly sure tptacek's not shy about sharing his opinion. ;)
That is a false dichotomy, and a particularly dishonest one at that. The options are not write complicated code in a modern language vs write boring code in an obsolete language. Go is bad because it gives the programmer poor tools to write any kind of code to solve difficult problems, boring or otherwise. Basic simple functionality that has been established for decades is being ignored because people insist on pretending that having a good language is somehow a problem and makes code complicated.
Assuming you are saying that those things are a contradiction I don't agree. It's a perfectly legitimate position to design a language to have fewer 'advanced' features; it makes it easier to learn, there are fewer ways to trip yourself up unexpectedly. Of course on the other hand you may find yourself re-inventing the advanced language features yourself, probably not as well, or committing errors that could have been prevented. I don't think there is a right answer. Go takes a position, and that position is similar to the one taken by the original Java.
Anyway, you took my post in the wrong light. I used insults like those because I was using the language of Java critics[1], which was, you know, the joke. The intelligence one in particular was a riff on an insult by a good friend of yours:
Like the creators of sitcoms or junk food or package tours, Java’s designers were consciously designing a product for people not as smart as them. — Paul Graham
The Go creators definitely enjoy their language themselves. They designed the language that they personally would want to work with.
"For too long to admit to here, C was my language of choice, but I have used many languages through my career. Nowadays almost everything I write is in Go; it is the most productive language I have ever used and has displaced C completely from my toolbox." [0]
https://developers.google.com/events/io/sessions/332768653
You're absolutely right that it's an opinionated language, but having used both for production code, I don't at all see the parallel to Java.
Reducing the mental load of a programming language has nothing to do with how "smart" anyone is, it's about making everyone more productive. Otherwise, the smartest programmers would all be clamoring to use C++.
Now flexibility certainly comes with a cost: there's just that much more you need to understand about theory and architecture to be able to account for all the different code permutations. That said, it also allows for those who dedicate themselves to programming as a science to write exceptionally and more productively.
I would say Go raises the average productivity compared to more complex languages but dramatically caps the upper bound as well. Whether that's good or bad is as much philosophical as practical.
Productivity during creation isn't worth the cost of maintenance later. At least, not the psychological cost.
The language designers have not ruled out generics, and are fully open to providing them at some point. The issue is that they have yet to find an implementation that fits within the language design goals.
Yes, if you jump on the mailing list, and propose that they somehow "use" .NETs generics, and you actually have no idea how that would be implemented, or impact the compiler and runtime, you're not going to be greeted cordially. This happens fairly frequently, and is probably why people think the community is totally against generics.
The Go team wants generics, when they find the right way to handle them within the language. In the meantime, most heavy users seem to agree that lack of generics is better than poor generics.
Plus, something of this magnitude may need to be in a theoretical go2, so they can break whatever needs to be broken.
most heavy users are self selected.
Outsiders may have suggestions for improvements, they may even be outsiders because they would like to see those suggestions realized, but when is that ever not the case?
This statement, part of the standard Go talking points, seems to be designed to persuade the unsure to give the language a chance, "and generics will be around later once we figure it out." Not likely.
I think the designers know that no perfect shining implementation of generics--compatible with all of Go's existing design decisions--is going to arise deus ex machina after eluding researchers for all these years.
There has been some talk, but it's mixed in with a lot of noise too.
I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea. I think this is more along the lines of how can we pragmatically introduce generics without messing up too bad. From what I've seen, I personally think some form of templating has the most promise (though I am far from qualified to actually comment on its viability).
That already happened. In 1976. There is simply no excuse for this disingenuous "oh but go is magic and special and can't do it the same way everyone else can" nonsense. If people want that argument to be taken seriously, then they need to start offering actual specific problems with parametric polymorphism as it would apply to go. Not just saying "we're special".
Implementing generics requires tradeoffs of some sort -- compile-time and size, runtime efficiency, or language-complexity. The creators didn't want to accept any of these compromises, at least for the initial release of go.
As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.
Where? I can find nothing of the sort. And given that we have proof otherwise (compare D to go for example) it seems likely that you are choosing to interpret "some languages made their compilers slower" with "parametric polymorphism must make a compiler slower".
Really, if you have a language, compiler, and operating systems designer of the caliber of Rob Pike saying that generics introduce a lot of issues, I'm going to need some damned good evidence to the contrary.
"He also co-developed the Blit graphical terminal for Unix; before that he wrote the first window system for Unix in 1981. Pike is the sole inventor named in AT&T's US patent 4,555,775 or "backing store patent" that is part of the X graphic system protocol and one of the first software patents. [1]
Over the years Pike has written many text editors; sam and acme are the most well known and are still in active use and development.
Pike, with Brian Kernighan, is the co-author of The Practice of Programming and The Unix Programming Environment. With Ken Thompson he is the co-creator of UTF-8. Pike also developed lesser systems such as the vismon program for displaying images of faces of email authors."
Yeah, some amateur engineering right there. My point still stands; heuristically I have every reason to believe an extremely competent arquitect and designer who is involved in good faith on this project over a random commententer who can't be bothered to assess the evidence.
You don't need to believe anyone, that is the whole point. You are trying to turn it into "some guy's opinion vs the glorious and all-knowing rob's opinion". It is not a question of opinion, it is one of fact. Again, this problem was solved in 1976. ML is very old. Go read the papers on parametric polymorphism.
No one is denying that C and C++ have many problems. At the same time though, many of those problems have been solved in other languages (both older and newer than C++).
That's the party line. And I, for one, don't believe that.
Go has been going for what, 3 years? And a couple more internally IIRC. And not only they came up with nothing with regard to generics as of now, there's also no research or initiative has been started that anybody knows of.
So how exactly are they supposed to "find an implementation that fits within the language design goals"? By some kind of satori?
The reasons that Go doesn't have generics are well documented and discussed (continually) on golang-nuts. Basically, the designers feel none of the existing generics implementations are adequate. They claim that if and when a better solution is devised, they're open to using it.
I don't know why you're accusing them of shielding users from generics, unless you think they're being disingenuous.
Yes. The whole "we'll do it when we find the perfect way" is bollocks. Generics are a solved problem and engineering is about compromise.
It's just that the compromise in favour of generics is not the one they wanted to take. But the official excuse is more of a way to shut people up about it, than truthful commitment to finding the best way to add them in Go.
Thought it might be if not proof, maybe indicative: he specifically asked for comments on that blog post. And according to the parent, those comments were well reasoned and by a high expert on the field -- they would at least deserve a reply.
I think the advocates of Go who say "it is supposed to be boring" are giving a mistaken impression. Java was "talking down" to replaceable cog programmers, by having "one way to do it" that fronts the then-popular inheritance based OO, and syntax that spells everything out. Go is "talking up" to a programmer who is expected to want to see the algorithm in stark brush strokes against an uncluttered page, by having "one way to do it" that fronts the imperative algorithm and very light very regular syntax that doesn't obtrude. Go is not for people who want to program the language (try Haskell or a lisp). Go is for people who want to program the program.
I would like to know exactly what the established programming language research is. My strong impression is that if there was ever anything that was not established it was 'how to build the best programming language'. Not trolling, just asking for clarification on that point.
What I find amusing lately is the exodus from Ruby over to Javascript. What's the thought there - maybe there weren't enough braces? Maybe THIS time, this scripting language will work! What valiant hope.
I'm not one of these developers, but I believe the appeal is largely the ability to work with one language in the "full stack": Node.js on the server, JS in the browser obviously, and maybe MongoDB or Postgres.
The web has become our operating system, and Javascript is its language.
Nodejs? Solving stuff that erlang have solved.
The only approach I like is use a backend language to create a RESTful server to server data. And let clientside javascript mvc handle the layout and looks.
Don't let me get started on those javascript people that think MongoDB and noSQL is going to replace SQL.
JavaScript made sense because web devs already knew it. Also, and more importantly, there was no blocking io library.
So the developer is forced to write code in a way that makes Node perform well.
[1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
IIRC Rob Pike was hacking away in C++ and the some guys from C++1x comite came to google to show C++'s new features. And he thought to himself: "Really you really think the problem with C++ is not enough features?"
Remember "Node.js is cancer"? Remember how the Node.js fanboys would bully programmers on social media who critiqued it? At no point have I seen Go programmers hype up the language and attack others.
I sincerely hope the "brogrammers" and "hackers" who beat their chest about Rails and Node.js and whatever framework was/is flavor of the day, do not start using Go.
They will be a negative force in the community and it will be sickening to see them pump up the hype and declare themselves as champions of Go.
Perhaps not "attack", but Go advocates tend to be very defensive about any criticism.
Funny you should say that, because IIRC they also have stated that one of the reasons they are so skeptical of adding features to the language is that Java started out as nice and simple language that was a great alternative to what was available at the time, and that they don't want to repeat the mistakes of what happened after that.
I don't think anybody (that is, more than a few outliers) said anything about Java being "boring" back then. It's in the last 5-7 years, after J2EE came out of favour, that is in vogue to say these kind of things. And I know that, because I was around back then. Java was supposed to be safer, yes, but nobody said it was supposed to be boring or targeted to enterprise drones. On the contrary, it was deemed "revolutionary" and the language of the rich web (because of applets).
>1) created for people less smart than the designers
Well, most programmers are indeed less smart than Ken Thompson or Rob Pike, so that would be a good call IF it was true.
But from what I have read, it was created to be the perfect language FOR it's designers, scratching THEIR pain points -- not targeted to some inferior programmers. And it's designers were and are are very fond of the language and heavy users of it.
So, I don't see where you got your (1) point.
>2) designed to be easy to use in a corporate environment with large teams of varying abilities (the 'simplicity', which is really more familiarity: most people can write boilerplate filled imperative C-family language style code already).
Who said Go is about 'boilerplate'? One of the design goals was to reduce boilerplate, and in practice it's very succint, eg. to get the same thing going, compared to Python code.
>3) attempts to make certain types of errors harder than the languages it replaces (in Java thats memory errors, in Go it's concurrency errors), but by ignoring established PL research still gives you a big gun that is loaded and aimed at your foot (doing concurrency in Java with threads and locks, NULL and deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL ideas, but perhaps bringing one old idea to the mainstream, and being prepared to make a lot of sacrifices (to ensure an 'easy' language) to get people on board with that one idea.
So, in essence, it's not a hodgepodge of newfangled PL research like Haskell. Sounds good to me.
>The amusing thing is that the creators of Go are some of the fiercest critics of Java, but they have created something that seems to follow a very similar philosophy to the original Java.
Well, they are not critics of the original Java. Matter of fact, some of them have also programmed lots of in Java in the past.
>I don't mean this as a slight against Go (or Java!). I just find the comparison illuminating.
Well, you sure sound like you do.
What is the relevance of Dunning-Kruger? I've always taken the practical meaning of Dunning-Kruger to be that there's always room for self-doubt, though certainty may be increased the more external validation you get. The GP's comment does not seem any more certain than the average comment here.
In that it's not wise to put people using other languages (such as Java etc) as "lesser programmers", just because you think you're so much better for using something else.
People tend to overestimate their smarts -- and those kind of inane comments about whole language ecosystems are not exactly signs of brightness.
While a valiant effort of you to meta-snark (couldn't help it, could you?), there's nothing much to "understand" about it. It's a well known experimental study. And it wasn't quoted here as a scientific citation -- just as a well known metaphor for "don't overestimate your smarts, kid".
>The fact that it was used in earnest without presenting any justification just makes it all the more hilarious, unintentionally so.
"Without presenting any justification"? What exactly do you thing this is? Some academic forum on psychology where we study cognitive issues?
He have, here, an exchange on programming languages, where the parent put down whole classes of programmers as inferior (to some unmentioned higher standard) with rigorous hand waving and a few invalid arguments -- several of which I refuted.
The reference to a cognitive superiority bias was given in this context, as a token "and who do you think you are" gesture. Nobody said that this was a clinically verified case of the Dunning-Kruger effect in action -- or that it was the core of the conversation anyway (it's a single link at the very bottom of a 450 word reply).
I know some people on HN tend to be pedantic, but you should not let pedantry ruin your ability to hold a conversation (AKA, the "well, actually" effect: http://tirania.org/blog/archive/2011/Feb-17.html ).
Either way, I didn't get that the OP wanted to put down other developers, rather that the language designers did, by "simplifying" their languages by sticking to tradition and leaving crucial features out, and needless features in.
> So, in essence, it's not a hodgepodge of newfangled PL research like Haskell.
Pretty sure repeating Hoare's 1965 mistake should not be glossed over this way.
I believe I heard that Gosling did want to have first-class functions initially in Java, but they just ran out of time.
Go, of course, does have closures like almost all modern languages. The lack of generics does stymy what you can express statically with higher-order functions, but it does have them.
Golang also differs from Java in some obvious low level ways.
But let's step back and explore "boring" here. When I talk about Go being boring, I mean the specs of the language are boring. In contrast, Java has a pretty exciting spec while the code itself is boring.These two are worlds apart. Go promotes a "boring" spec to write smarter code[1]. Like Python, the focus is on expressiveness rather than on features(standard library features).It reduces the cognitive overhead so that you can "program" more. 3) Neither Go's concurrency patterns nor the avoidance of concurrency errors(or non-determinism of code execution)is anything new. It's based on more than 30 years of research including Unix pipes, Hoare's CSP. The patterns Go follows is not conservative at all! It still follows the same PL ideas you are talking about(or not talking about). If you are looking for the gun it's still there[2]. The wrapper around concurrency is not a protection but an enhancement so that the code can focus more on project logic. And still the wrapper is sometimes not enough to avoid mutilating your foot. I don't think Go inventors had that in mind while designing the patterns. Also Go too handles memory management(yes, just like Java).
Your comparison is based on incorrect hypothesis. I can hardly see the illumination. Let's just say Go is a fresh new programming paradigm and it would be hasty to jump to conclusions without exploring it a bit more.
[1]http://commandcenter.blogspot.in/2012/06/less-is-exponential... [2]http://golang.org/pkg/sync/
P.S: I don't program in Java by choice. Android Developer. Edit: language
We created Go first and foremost for ourselves. Go is the language we want to be (and are) writing programs in. I haven't had this much fun writing programs in a long time.
It is emphatically NOT true that Go is "created for people less smart than the designers". At no point during any design discussion did we say "well, that will be too difficult for the average programmer".
The part about "large teams of varying abilities" is not true either. What is true is that Go was designed for large-scale programming, though, and the things that work in a 100-line Haskell pearl don't necessarily scale to million-line programs. Rob Pike gave a talk about this at SPLASH titled "Go at Google: Language Design in the Service of Software Engineering" [1]. I highly recommend it if you want to see where we're coming from with some of the design.
Your third point is certainly true, but I can't think of a decent language that doesn't attempt to make certain types of errors harder than the languages it replaces.
I don't see how Go is more "systems-ey" than say, Java; other than allowing you to pack struct members together by separating pointer and value types in a certain way. C# already allows you to do something similar.
Furthermore, the main arguments I've seen for "programming at scale", are that unused vars get treated as errors, interfaces, and the way dependencies are managed (mainly to speed up compile times).
The latter has been solved by probably any modern language post-C++. Warnings as errors is a preference. Interface types aren't that special when looking at languages like Scala and Rust, which provide very nice and powerful type and trait systems that go really well together; while maintaining the ability to extend types by other traits, not that much unlike Go to begin with.
I am not a language designer, but I can't help but feel that the language was somehow designed into a corner, with the way interfaces and composition work together. All this is making adding generics much harder.
However, this talk does not mention some questionable decisions, such as keeping null references in the language. Why would you do that, instead of using option types?
Can you comment on generics in ML-derived languages?
This one doesn't hold up to inspection. The indications are that Google intended to use it in house. If nothing else can be said about Google, they do believe they are smart.
When I was working with C++ earlier, that was not really the case. After spending many years with it, I couldn't write a simple web server in under 5 minutes. Making something into a library had too much overhead. In Go, once I've done something [1], the next time it's one line to import it.
Also, working with the language programmatically is a pleasure. There's a full parser in the standard library.
[1] e.g. https://gist.github.com/shurcooL/5571468, https://gist.github.com/shurcooL/5504644
"for _, "
range in the for loop return 2 values (index, value). If you don't want the index, you can assign it to "_" to ignore it.
The presence of this anecdote in the article seems to fulfill some sort of journalistic requirement to balance any positive stories with criticism as well, to be in the center. It doesn't make a lot of sense when writing about programming languages.
The choice of language does have the potential to deep six a project; however, it's rarely something that can be blamed on the language itself.
I've seen projects fail because of the language the chose for at least two reasons, but I think these two are the most obviously harmful:
1. Choosing a language that isn't just unsuitable, its design goals and tradeoffs should make it an obviously poor choice in terms of your requirements.
2. Choosing a language for use by a team that has no experience with it, no time to learn it, and/or lacks the discipline to learn it in sufficient depth to use it efficiently for the project's purposes.
Again, these are not failures of any given language. They are, however, potential project-killers that are only possible based on the choice of programming language.
I think it will happen eventually. The language is new, but it's having a lot of success and spreading both within Google and outside.
First, I should point out that you CAN currently run Go programs on an Android device. You just can't take advantage of the SDK and make GUI-based applications, etc.[0]
Basically, the answer is that nothing's preventing anybody (including you and me) from doing so, except the fact that we would have to wrap the entire NDK and make it available/usable through Go.
That's not any more difficult to do in Go than it is to do in Java, but it's a massive amount of work which has already been solved for Java, so there's little incentive to recreate it in Go.
(I'm paraphrasing, so my answer may be slightly wrong, but hopefully you get the idea - perhaps @enneff can give a more complete answer).
[0] You can, however, bundle them as hybrid applications, because Android applications apparently allow bundling of arbitrary binaries, from what I've been told.
but, I'm giving you the benefit of the doubt that there's an intelligent comment here
"If Google were pushing Go and it were on Android, it may feel as though Go's goal was political, ie another way for Google to assert control over the development process and bring people under their umbrella.
"Given that Go isn't on Android, it feels more like Google is trying to contribute a useful tool than push an agenda."
You may disagree, but that's what was implied.
1. CLAs are a fact of life in open source to keep the lawyers happy (http://en.wikipedia.org/wiki/Contributor_License_Agreement). We've tried to make it as simple as possible: you fill out one web form, we do the rest. And it's just once, not every time. So if you're already listed as a contributor, you're done with this forever.
2. You're free of course to prepare the code any way you want. We insist on the hg extension to manage the review of the patch, mainly because it makes our lives easier: there are a LOT more contributors than there are core Go team members doing code reviews. (And we don't just review; sometimes we even like to write our own code.) I hope using the tool isn't really too burdensome. Many people work with other things, like git in the same dir or hg in another dir, and then they copy the changes into their "review" tree.
3. This is a real problem. We don't have a good system for tracking these: so far we've just been letting everyone watch the same stream and deal with what needs dealing with. But the volume has gotten high enough that we are dropping too many incoming changes or bug reports on the floor. We're working on a new system to track incoming changes and bug reports and assign them to a clear owner so that everyone knows who is responsible for what. I hope this will go live soon.
Go is the right language for the right time: easy enough for the Python people (like me) to pick up quickly, but with a concurrency model that makes taking advantage of multi-core very easy.
Anyone prefer Scala to Go?
Yes, very much so. I love being able to keep so much of the state in the type system, freeing my attention for more important things; it also (ironically?) lets me write much more dynamic-feeling code by using "typeclasses" to supply varying implementations for an operation. I don't realise how much I depend on it until I try to go back to other languages. Go has some useful standard types and a good story in place for some other generic type use cases, but if you need a (generic) type that the language designers didn't think of (and e.g. even Option is missing), you're stuffed.
[1] http://akka.io
The other thing that makes me a bit nervous about using it in production is the idea of linking to the latest/head version of a dependency. Maybe I just don't properly understand the paradigm though.
Those nits aside, I believe Go has bright future and within 2 years will be mainstream. Meanwhile, Scala is better suited for projects that need lots of libraries and mature tooling.
The Go standard library is large, there are many libraries on code.google and github. I feel like this statement would have been more accurate a year ago. My job is almost 100% Go based development and at this point, I have no issues finding libraries when I need them.
You can pry the super powerful type system, functional programming support, monad comprehensions, library ecosystem, IDE support from my cold dead hands :D
Yes, by a huge margin. I rank my preferences like so:
derp languages (go lives here) < scala < ocaml/F# < haskell
But that doesn't make it clear how huge the distance is between the derps and scala.
I'd choose Ada or Rust over Go.
For concurrency I'd choose Erlang or Rust over Go.
If it's Node.js or Go. I guess I'll choose Go.
This forces all Go code to be formatted and styled in a consisten manner. This not only solves readability issues, but makes all code consistent for machine reading and replacing.
gofmt also supplies a pattern replace method, which is a bit more sophisticated than a regex search and replace.
For interactive refactoring experience, then, it's basically up to the IDE how to integrate that.
If you want a language which requires an IDE, I doubt very much you'd like Go - it is intentionally pared down to a minimum of what the creators consider essential features.
Having an IDE is almost required in a language where you have things like header files, namespacing, verbose function names, type hierarchies, a vast and complex standard library, etc. I've used a few IDEs, and prefer to go without where I can, though with some languages they're almost necessary - that's a personal judgement though, not a criticism of those who like IDEs or languages which require them. In Go, I can't imagine what I'd even use one for, save to organise the files in a project and do global searches, and perhaps trigger compiles/runs (I use a text editor for that), it's far closer to a scripting language in that sense. As to refactoring, it's really very simple and tools like gofix are there if you want to do something complex - to be honest that's really unnecessary for 99% of the refactoring I do, a search, check and replace does it very quickly.
So you might not like the language for the same reasons it doesn't require an IDE, but not having a decent IDE is not a valid criticism on its own.
I didn't ask for a language which "requires" an IDE. I simply want to find a decent IDE for use when coding Go.
Depends what you mean by "IDE". There's LiteIDE[1], which fits the more "traditional" idea of an IDE.
I use Sublime Text 2 + GoSublime[2] myself; auto-completes from packages—inc. third party ones installed via `go get`—as well as error detection and integrated `go fmt`.
[1]: https://code.google.com/p/liteide/ [2]: https://github.com/DisposaBoy/GoSublime
Some examples are AppEngine, Angular.js, Go, GWT, and Chrome Developer tools.
I don't get where he'sshe's going with his/her post though...
Just my humble opinion..
I think this is more accurate: http://www.indeed.com/jobtrends?q=scala%2C++golang
Golang: 8 Jobs
Scala: 1,434 Jobs
So, like:
var SomeFunc = RequireAuth(func(...) {
...
});
OK, I guess they think abbreviations are useful...but then they went with "database" instead of "db", "encoding" instead of "enc" and "image" instead of "img".
At least be consistent.