I doubt it will ever make a dent on the enterprise over the JVM/.NET/C++ stacks, unless a compelling library requiring its use shows up.
I honestly think it will. Especially for high-performance applications it's going to start making serious inroads. Financial and scientific applications will start the trend and once some infrastructure and best practices get established, it will start seeping into the mainstream. Having a big name like Google behind it is a lot more assuring to businesses than hacker-driven projects like nodejs or academic-driven ones like Scala. Go is built for industry.
I spend about 30% of my time system side in Go, and the rest in Node.js. I'm working to migrate almost all of my time to Go. The language is fun to work in and, personally, the overall experience is much improved over Node.js. It's exciting to see the momentum behind the language and the great people who are attracted to it.
Are Node.js and Go used in separate systems or do they have their own special places?
At a startup I worked for we used node.js prototype/sometimes v1.0 and Go for everything after. We shifted to writing everything in Go as we reach a point were we were more efficient from an effort standpoint in Go.
I doubt it will ever make a dent on the enterprise over the JVM/.NET/C++ stacks, unless a compelling library requiring its use shows up.
I honestly think it will. Especially for high-performance applications it's going to start making serious inroads. Financial and scientific applications will start the trend and once some infrastructure and best practices get established, it will start seeping into the mainstream. Having a big name like Google behind it is a lot more assuring to businesses than hacker-driven projects like nodejs or academic-driven on…
> ... academic-driven ones like Scala ...
The UK financial sector seem to like academic stuff then.
It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. This was reason enough for C to get popular.
> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. Only if commercial UNIX and Windows also get rewritten in Go. > This was reason enough for C to get popular. C got popular because UNIX was adopted by the enterprise and C was the system language. I doubt C would ever been popular without UNIX.
This is correct. C was dying off in the mid-1980s until UNIX-based workstations were invented, causing a resurgence in C's popularity.
> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. Only if commercial UNIX and Windows also get rewritten in Go. > This was reason enough for C to get popular. C got popular because UNIX was adopted by the enterprise and C was the system language. I doubt C would ever been popular without UNIX.
This is correct. C was dying off in the mid-1980s until UNIX-based workstations were invented, causing a resurgence in C's popularity.
> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. Only if commercial UNIX and Windows also get rewritten in Go. > This was reason enough for C to get popular. C got popular because UNIX was adopted by the enterprise and C was the system language. I doubt C would ever been popular without UNIX.
This is correct. C was dying off in the mid-1980s until UNIX-based workstations were invented, causing a resurgence in C's popularity.
(Don't know why I can't reply to the leaf nodes in the conversation...)
>What was taking its place at that time?
Pascal was fairly heavily used, but was dying out. LISP was hot because it was the middle of the Great AI Boom, Modula-2 was supposed to replace Pascal and be a systems programming language, and ADA was supposed to be the next great thing. Apple had created Object Pascal. Self was the big research language. Nothing really took hold until C++ in the latter part of the 1980s.
My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem…
> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages). There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's…
That's a very large blanket statement right there. I code in five main languages Objective-C, Java, Python, Ruby, and a bit of Javascript. I do back-end web system type of dev work (Python, Ruby, JavaScript, Java) and front end UI (iOS, Android, and JavaScript (Backbone, Angular, Ember). I use Intellij and sublime as my ide/code editor. The most productive, easiest to use, and for me most fun to develop in environments are Django, Rails, Node, and front-end JavaScript. That is almost completely because of the application aware REPL. Django's manage.py shell command, Rails rails console command, and Chrome's dev tools are three of the most important developer tools I've ever discovered. I'd LOVE to find an iOS tool with the same power.
You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.
And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.
Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.)
If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense. So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
> So we are pleased to see Go being used for the job it was designed for, This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation. Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all. Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further…
I like Go, but it's too bad they didn't simply enhance FreePascal, if their main concern was compilation speed. Was it just a "Bell Labs" ego concern?
Or, was adding garbage collection that big a need? GC of course makes Go quite different from C++, so they should not be surprised if some "speed demons" refuse to convert over. (note that I hate C++, but can see the point of this aspect)
> So we are pleased to see Go being used for the job it was designed for, This sounds a bit like revisionism. Rob Pike made it clear that the initial motivation for Go was the slowness of the C++ compilation. Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all. Personally, I think it will grab a decent amount of Ruby and Python programmers but it won't go much further…
I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain ad…
Go is more like a Modula (Algol???) variant with curly braces.
Mapping interfaces onto a funky function/routine call syntax (an optional parameter in a second set of parens for the "receiver"), and maintaining stack frames around a procedural type reference (closure) after the enclosing scope returns, are about the only new tricks.