Do I believe Java will be the next COBOL. Absolutely. Do I believe Go will be the next Java. Absolutely not.
1) It ignores where Java is being used. It is dominant within the enterprise. Features like a single binary, lack of a reverse proxy or taking advantage of multiple cores aren't at all compelling. We have dedicated ops teams happy to automate deployments, hardware load balancers and are rarely doing anything CPU intensive.
2) It ignores language trends. Functional programming is what is hot right with Scala and Clojure being what most enterprises are choosing to adopt for the next big project. Why ? Because they can leverage all their existing Java libraries/practices but without the boilerplate and language overhead of Java.
3) It ignores architectural trends. Go's concurrency approaches are nice but aren't that special and again aren't that useful in most cases. Unless you are someone like Cloudflare it is far easier to just horizontally scale your app servers across seperate instances. It's more expensive but hardly worth deciding your platform over.
We've been using Scala for a while now. It's a major step-up from Java in terms of sheer programming enjoyment (contrary to what the criticism parrots who don't actually use it would have you believe). Java is still very widely used, but most don't use it by choice anymore but rather because it's the default or what the existing code is written in. Go is a non-starter for us due to a lack of support for existing Java libs, and isn't all that interesting compared to the alternatives.
Maybe it makes sense to understand why Java is where it is today. It is not because programmers thought it was the best technology, but because of politics. At the time of introduction, Microsoft held a clear platform monopoly and the key skills in demand were C++/MFC and the like. Sun was the underdog and Java was positioned to become a counterweight to this monopoly and many companies supported it heavily just to provide a balance.
From a developer standpoint Go is superior, but would the same political support happen for a Google-invented language?
This is a myth, perpetuated probably by people that weren't around in those days. It is true that Sun pumped money into marketing, but given that other companies did the same without the same success, most notably Microsoft, it's proof enough that pumping money in marketing isn't everything.
Java succeeded because (1) targeting Unix and multi-platform development was awful, the closest thing to an alternative to C/C++ was Perl, (2) people loved in-browser applets and this was the killer feature and (3) all decent alternatives were expensive. I remember in college when I decided to build a simple desktop app for Windows and I chose Java because I didn't have money for Borland's Delphi or for Visual Basic and I hated the thought of pirating like everybody else did it.
> From a developer standpoint Go is superior, but would the same political support happen for a Google-invented language?
Personally I don't think that Go is in any way superior, quite the contrary, I think it represents a regression and it wouldn't be on anybody's radar if Google wasn't involved.
It depends on where you're looking. In my country banking is dominated by Java and I've seen mixtures too and migrations from C# to Java.
.NET has several problems. Microsoft targeted Windows while Java's rise is correlated with the rise of Linux on the server-side. Linux on the server-side is cheap and reliable and people want more and more Linux and Microsoft's cooperation with Xamarin is kind of too late and is meant for mobile phones and not Linux, but who knows. Microsoft also failed to create an open-source community around .NET, while Java's open-source ecosystem is huge and even the commercial tools available are cheaper. Microsoft advertised .NET as being multi-language but dropped the ball later and failed to attract new languages, whereas other languages are flourishing on top of the JVM, keeping Java the platform hip. Microsoft also failed to convince startups to use .NET and today's startups are tomorrow's corporations.
You paint Java as the child of corporate scheming (maybe unintentionally), but it was more nuanced than that. Java's success was due to several trends coming to together at the same time.
The bulk of serious programming in the early 1990s was in C or C++. Cross-platform C libraries in those days were either abysses of mind-blowing complexity or just pure snake-oil.
Since everything MS did was Windows, anything that came along to provide a good development experience (which Java did in comparison in those days) AND be cross-platform (one of its founding principles) couldn't help but be successful.
Compiling at the time was a problem. Adding a new library could mean hours of digging up to find out why you can't even link the damn thing in your project - if that's even possible. That's before even talking about cross-platform.
Java was also a modern OO language, safer to use than C++ and with everything you needed right there in the JDK, all of that backed with solid documentation ( internet was not what it is now, if you were the lucky few with access at all )
In particular, java had a great easy approach to threading out of the box, working everywhere.
As someone who was programming at this time, and before, I agree with all these and the child comments. Java being OO but a "simpler C++" plus having garbage collection generated a lot of interest, even in places that were all Windows shops.
Late 90's I worked at a place that sold software to customers that had to run on Windows, Linux, AIX, Solaris and HP-UX. Java went a long way of saving us from the #ifdef nightmares.
I'm sorry, I think I just downvoted you while scrolling (tablet) and there's no way to reverse it. If anything, I'd like to upvote since you make a good point. Java succeeded not because of technical superiority but because of Sun spending millions on pushing the language (and because it was the only way to write browser applets!)
However, while Google doesn't seem to be pushing nearly as hard for Go's adoption externally, lots of the industry has run with Go on their own, on Go's merits. So, that's different than Java, but also a good place to be.
Pushing AND developing. Languages live or die by how much is invested in their tools, libraries, execution environment, community, etc. The only languages with a comparable investment to Java are C(++) and JavaScript. Everything else falls short and will get passed by for most projects. It's quite possible that Google will make a similar investment into Go, but they do have a tendency of dropping out of projects prematurely.
Not only that, but for hardware companies like Sun, IBM, SGI and HP, Java was a way to sell hardware that wasn't Windows-compatible and to counter the existential threat C++/MFC/Windows/x86 represented. The idea was that you could develop your application on a puny PC and run it unmodified, much faster, on a serious machine with a serious OS. With a serious price tag, but that's another issue.
Java was also designed to be fashion-compatible: it had OO, its syntax resembles C/C++-ish languages, it is statically typed, and it could be used to run programs inside web pages (as well as on mostly anything with a decent CPU). All things were compelling in the late-90's. The fact Sun spent a whole company promoting and developing it also helped a lot. It didn't help Sun that much, in the end. It's a shame. SPARC boxes were amazing. It's really sad all those beautiful architectures could not compete with the evolving x86.
Hear hear. Where are the companies who are developing the Springs and the JSP's and the Velocities of all those languages supposedly supplanting Java in a few years? Nobody uses or ever used Java because it's such a nice language. It was heavily pushed by a major player in the market at the time it was introduced, and as time passed it became the only language with a big enough ecosystem in enterprise development to do enterprise development in (well apart from .Net, I guess, but that's not really the point).
> Go’s performance isn’t a big win for Java developers since they’re already doing pretty well. But for us dynamic language refugees, Go’s performance is liberating. No dealing with reverse proxies to send things to multiple processes. Real threading and the ability to take advantage of every core. Async IO, but without all the callbacks.
Jesus, are people really this excited about features that existed for at least 15 years in other languages?
This one language for everything mentality is ushering in a huge NIH cycle.
I thoroughly agree with that. Go's channels are great for multiplexing (but not as great as real continuations), but for computation, promises beat the crap out of Go's channels.
And data structures in Go, that's just plain painful.
People are excited that the features which already existed are now tied together in a pleasant to use way, free from most of the drawbacks that are typically associated with low-level languages
I don't understand why you would need one language for everything. Thanks to messaging queues (or just HTTP) interop between languages/technologies has never been easier. Even if Go ties these features together, it won't be best in every domain.
No people are exited about the plain and simple standard library, which is 2 years old, and thus currently relatively free of compromises (though more and more are coming to light like you'd expect, like recently on the mailing list the complaint that logging can't be stubbed out, and this can't be changed due to backwards compatibility ... that's the arguments that will break the language).
People were exited about the fresh compromise-less nature of the C++ standard library in the 80s, even in the 90s. About the fresh no-compromise approach of the java ones at the end of the 90s, and again right after java introduced generics.
Go is no different. It's standard library is not that far from the cruft-level of the python standard library, and the next language change (which they absolutely need : generics) will bring it to the level of the java standard library, due to the need for backward compatibility with pre-generics go programs.
Come on people, I realize at 16 I too thought that language X is forever (C++ in my case, on the plus side: it fared better than most. Some people, mostly the academics later switching to java, actually picked modula-2/oberon, which is/are a lot like Go. A lot went for visual basic, object pascal, and some for objective-C). But we're not 16 anymore ...
When it comes to 15+ year old languages, I'd actually say C++ is the most cruft-free easily usable language. Depends, a lot, on what libraries you use though.
Near-C performance, static/strong types, async io without callbacks, well integrated multithreading... maybe I'm missing something obvious, but which (not obscure) 15-yo language provides this set of features?
Static types - of the worst kind that get in the way of creating any significant abstractions (no parametric polymorphism or generics) and don't provide much safety (no nil safety). For a new modern language, this is just weird.
Well integrated multithreading - yes. 40-year-old error handling strategy: also yes.
Haskell, Scala, F#, C# are all much better choices that I think fulfill all your criteria (Well, one might argue that functional languages are obscure, but that's increasingly not the case these days)
I find the popularity of Go rather depressing. If Go becomes the next Java, the inventors of C would set the programming world decades back in the past for the second time.
in reply to cookiemonster11, the wrong part is that it doesn't work well.
When you asked for exceptions you actually wanted an Either type, which means the function either return a result or an error (not both).
You also want something that propagates errors automatically (the monadic bind) in case you don't want to check every result.
An Either type lets you get the best of both worlds. It lets you model exactly whether an error can or cannot happen (unlike exceptions that are not optional). It lets you check every return value directly via pattern matching (similarly to Go) but also, the compiler will warn you if you "forget" to handle the error case. Finally, the bind operator lets you chain operations in a way that only executes in case of no errors, plus attach a single error handler at the end to handle any of the errors (in a manner similar to exceptions)
How I wish nullable types worked in C-like languages:
You cannot dereference a nullable value normally. However, inside a (x != null) block, or rather anywhere the compiler can infer that the value cannot be null, it automagicially turns into a non-nullable type. And there's the null-safe dereference operator (.? or similar) that returns null in case the first value is null.
Similarly with casting - if you have an if block with an instanceof check, within that block the variable has the type given by the check.
You still have to have a runtime-checked NPE in some cases (in case of hotswapping, casting to non-nullable types (which should be allowed but throws a checked excption), etc), but mostly this avoids the issues with NPEs, I think.
I agree that pattern matching can be powerful, and underutilized in most language designs.
Alternatively, I've been growing more in favor of the idea of not having null at all in the base language - if you actually need it it's relatively easy to implement if you have boolean algebra on types (Nullable<x> being equivalent to Either<x, Null>, where Null is an enumerated type with one value, null. Like what you said). And that way it's explicit, and people are more likely to use a better (read: more informative) exception type). Null ends up being an exception with no additional information, which can work in some cases, but often you want additional information. Even just "NotInitialized" or something like that is often better.
I wasn't saying Go has them, these were just the properties listed in the parent comment. Scala adds better types to Java, otherwise they have pretty much the same properties.
I was just going to disagree about C# being old. Then I checked the year... Now I'm sad, because 2000 came quite a long time ago.
Well integrated multithreading? It only just started getting integrated in the latest standard. The typing is also not that strong... you can get silly implicit stuff happening in many places.
That's correct, but there's not much reason to use green threads in Rust--they don't have the advantages that green threads in Go do, besides the lack of context switching (they aren't "lightweight" because they are just as resource-intensive as threads).
I think the author is mostly right, but he fails to recognize that the difference between COBOL and Java is much, much bigger than the difference between Java and Go. Right now, I think that the full Java ecosystem is "better" (to the extend that can be meaningfully measured) than the equivalent in Go, to an extend COBOL probably never was to Java. Obviously that gap will close, and fast, but it's an example of just how relatively close those two languages are.
And then this:
> Any developer that cares about their demand in the market (and salary potential) and any employer wishing to hire should factor language life-cycle into their language choice. I’m sure there are still COBOL programmers out there, but I wouldn’t want to be one of them if I was looking for a job and I wouldn’t want to be an employer trying to find a competent COBOL programmer or anyone that wanted to learn.
Few things scream "name your salary" in this business like being a competent and willing COBOL programmer. I'm not sure that learning COBOL from scratch is a viable career path these days (there's a chicken-and-egg problem, you're not going to become great a any language without actually working in it, and nobody is going to let you work in it before you're pretty great), but I WOULD "want to be one of them if I was looking for a job".
> Few things scream "name your salary" in this business like being a competent and willing COBOL programmer.
Uhh.... if you can find someone looking for a COBOL programmer in your area, perhaps. But the number of COBOL jobs out there is pretty tiny. Anyone with a COBOL system is looking frantically for a way to decommission it. That's not the kind of project I want to base my family's income on.
"But the number of COBOL jobs out there is pretty tiny."
No it's not. They're not advertised on monster.com, true. It's used in niche markets (well, if you call e.g. banking a niche market) and those systems aren't going to be 'decommisioned' anytime soon. There are literally dozens of just vendors of Cobol compilers / environments / toolkits in business today. Like the GP said, I'm not claiming going into Cobol as a 21 year old is a wise career move. But Cobol consultants certainly bill a multiple of what Ruby, Go or even Java consultants bill here in Western Europe.
Dream on. You cannot predict the future from the presents past. Go is hyped a lot but at the end it's not that much needed as Google wants it to. Java is easy to learn, very fast and hast tons of frameworks and documentation.
For other stuff there is still c++ and python with QT and if for some folks ofc there are ruby, perl, Haskell and so on.
Also, and this is an important point go was invented by Google and Google is not the cool hip company it used to be it is. Ow the complete opposite and part of orwells vision...
> You cannot predict the future from the presents past.
Every time you open your lungs in the expectation that they will fill with 20% oxygen and nothing toxic, you are 'predicting the future from the presents past'. The past is the only basis for forming expectations about the future, even if you're dealing with smaller probabilities, such as the rise and fall of programming languages.
> Also, and this is an important point go was invented by Google and Google is not the cool hip company it used to be it is. Ow the complete opposite and part of orwells vision...
Really? Go is obviously very trendy right now, and Angular - in my anecdotal experience - is on top in the front-end wars. Google is coming up with plenty trendy technology at the moment. Unless the Go compiler's phoning home, the Orwell stuff is just laughably irrelevant, and will be treated as such by the bulk of developers.
I have no idea if Go is destined for really big things. But the fact that it's a small ecosystem now doesn't matter - Java was pretty small back in '95. It depends on whether it allows developers to solve the next decade of engineering problems in a satisfying way, relative to its competitors. We shall see.
> Every time you open your lungs in the expectation that they will fill with 20% oxygen and nothing toxic, you are 'predicting the future from the presents past'.
The fact that one is breathing right now doesnt mean one will still be breathing 5 minutes from now. You can predict the future.You can maximize chances something happen,you just cant be sure 100%.
Yet chances are that :
- Business arent going to drop the JVM "en masse" for Go,just because Go is cool. And frankly , from a syntax perspective , Go is not that great. It has almost no functional features, and a very weak OO model.
> I have no idea if Go is destined for really big things. But the fact that it's a small ecosystem now doesn't matter - Java was pretty small back in '95.
Nothing like what the Java ecosystem is today existed before Java, that's a huge difference. And the fact that the JVM runs multiple languages makes it unlikely it will be obsolete,ever.
Concurrency backed in a language is cool,but not necessary. concurrency can easily be a lib or a framework.
I've been in enterprise long enough to know that enterprise likes boring enterprise languages for most part(java) and glue languages (scripting languages) because deadlines ... while Go might have been great at replacing C,which it doesnt, I still think there is some room for a safer C for system programming. I dont think Go features are interesting enough for entreprise solutions. There is nothing Go can do that the JVM cant.
I don't see why the future wouldn't be polyglot, in the sense that there isn't one language as dominant as Java has been.
There is now much better language interop than in the past, e. g looking at C interop in Julia and Java interop in Clojure and other JVM languages.
Using HTTP on distributed queues on less unreliable, faster networks than in the past makes building distributed systems using many different languages easier (SOA, Microservices).
On the clientside there are strong proprietary ecosystems which dictate the use of a specific language (more or less), Android, Windows (C#), Apple (Obj. C, Swift).
Therefore I think it is plausible to assume that no single language will (have to) become as dominant as Java has been
Unlike any of those projects, Go is fully developed under a liberal FOSS license, so if Google looses interest (and Go is actually good), development can be picked up by the community.
I had a chance to do a bit of Go work while at Google. Coming from the complexities of C++/STL, the simplicity was a blessed relief.
Unfortunately, I don't think that simplicity will last. Other popular languages like the C family and Java were pretty simple when they started out. But C became C++ became C++ with STL, with all the attendant complexities. Similarly, early Java was a pretty clean language, but they added generics and various libraries, to say nothing of the swamp of a tooling ecosystem built around the language. "Your experience is in Hyperstruts? Sorry pal, we only work in JToolkitMVC."
If Go becomes a big success, I predict it will walk the same path, gaining complexity either in the language itself or in the surrounding libraries or frameworks. Simplicity is a sign of immaturity, and it will not last.
Completely agree on the second part. It feels utterly silly that they refuse to use exceptions on the basis that errors should be explicit, but then allow for errors to be silently ignored just by not assigning them to variables.
In practice this is not a problem that is encountered pretty much ever. If you are afraid of it, run errcheck[1] on your code, and it'll tell you if you've missed anything.
If you don't mind me asking, what is it that keeps it from coming up? I understand that the multiple return values help, since then you don't need to go with the clunky C-style of passing in pointers that will be used as output.
Error codes always feel like they rely too much on everybody deliberately following good coding practice, since the default is to ignore the error code. I prefer using exceptions, because then the error can't be ignored by default, and must be explicitly silenced if it is not desired. Then again, that is a large python influence on me.
I also think the arguments against using exceptions are flawed. For example it's a common pattern to use a supervisor that catches exceptions and depending on context and severity, to log the errors, to restart the guilty component, to send an error report, to fallback to something else, to crash the whole process and so on.
The idea being that unexpected errors happen and you need to react to them in some way, preferably without relying on the developer to do something for everything potentially error prone that he does, because we can't anticipate everything bad that can happen, yet in spite of this, we can make the system resilient to errors.
If you really need to have generics, maybe you have no need to use go in the first place. I certainly have very limited use and experience of generics, and therefore I have no strong feeling about them. Despite our respective opinions I have no doubt you will find other developers implementing them in the future.
I am a rare (for Hacker News) C# dev and I've just been toying around with Go. There is stuff to like but my feeling is that the biggest weakness of the language is that it is designed to solve the problems that Google has (surprise), which is only a fraction of the problems that the world has.
It is a scalpel verses a swiss-army knife. The question is which do you need.
If you are doing Internet-related things (server-side plumbing and apps, not search), it looks like a pretty darn good fit. It naturally leads you build up a set of small start tools that you combine to build a larger service. The channels metaphor is a really nice way to deal with concurrency.
If you are building anything else (desktop, LOB apps, DB front-ends, mathy stuff, etc.), it looks a bit limited. For example, it doesn't have a modulus operator. Not a big deal but it shows that the language designers are more concerned about supporting their target domain than supplanting Java, much less C#.
Really, the thing that I fine the most troublesome is this feeling that the designers of the language have such a focused vision that it will hinder the growth in the future but, for now, it needs that to keep from becoming overgrown like C# is.
I've spend some time with Go, but never felt overly productive with it. As someone else in this discussion mentioned a simple language doesn't mean that solutions in this language are simple! Look at what real problems you have to solve in you applications, and then tell me that generics in a statically typed language are not important! Go applications are full of useless code to circumvent this restriction. Want to make something immutable? Not very convenient in Go, very easy in most other (statically typed) languages.
While Scala has a complex type system it is a simple language at it's heart. For example try-catch is not a special language feature but another application of the powerful pattern matching. It will take a little longer to learn Scala compared to Java, but you get a much better tool to solve the most problems. And you get all the libraries and the tools (any Go IDE on the level of IntelliJ or NetBeans?) of the big Java ecosystem.
But even if you don't want to use Scala, you could be more productive with Java than with Go. From a Java perspective Go has not much to offer, not even fancy concurrency.
>>Deploying Go code to production is as simple as copying a single binary file up to a server and running it. No reverse proxies, no dependencies to install on the target server, no class paths. Just copy the binary and run.
This fairly depends size of system we are discussing.
>>Some developers have noted Go’s lack of features or a few other things: no exceptions, nils instead of options, inability to specify dependency versions, mark and sweep GC, no macros, no generics.
languages such as Java too grew out from such weaknesses and are still growing
>>If I were a developer getting started today, I’d make a career bet on Go.
Fairly good but it depends on what market attracts you.For e.g. if you were to target financial markets with big responsive systems , i doubt if they have loads of Go lang hires vs the same on say Java hires.But if we were to target a different market,it would change too!
I think a very big difference between Cobol and Java/.NET is that it is being used in far more places (mobile,desktop,enterprise) and that the runtime is open for other languages (F#,Scala,Python, Ruby etc) because of this the main languages are constantly evolving as well and lots of libs and platforms are written in the main languages, maybe something like Scala will replace Java or Java will become more like Scala but I guess it would not be so easy to replace the the JVM or .NET as it is to replace a (almost) single domain language
Im thinking what will happen is there will be a version of java (along with the frameworks and technologies ) that will become Cobol and new version of Java will move on and improve. I dont think it will be the next Cobol. When cobol was around, not so many were using it and technology is limited.Today, Java is just everywhere.
The argument on looking at Go's trend in isolation is a really weak one. Let's also look at Clojure in isolation: https://www.google.com/trends/explore#q=clojure - and oh look, Clojure runs on the JVM.
> If I were a developer getting started today, I’d make a career bet on Go
Advice on picking languages as career bets are especially weak. In my experience, careers are being built on being able to get stuff done and in the long list of things that a developer has to learn to get stuff done, the language itself is very uninteresting considering everything else combined. Personally it takes me 2-3 weeks to become functional in any new programming language, I've worked with half a dozen thus far in production and I played with another dozen in my free time. The language itself is like a drop in an ocean, compared to more fundamental knowledge that makes one productive, like math, algorithms, concurrency and parallelism, hardware, usability, domain specific knowledge, libraries, frameworks, being able to interact with a community, etc...
> Go is a simple language by design. You can read the spec and other materials on the Golang website and start being productive in a single day
Simplicity in the language doesn't translate to simplicity in the solutions that you're building. This is a fundamental divide, since often people are mistaking simplicity for easy, for being familiar. It's not in the original sense of the word - simplicity is the opposite of complexity, which means interwoven or entangled and in the context of software it means building reusable / modular components, that do one thing well and that can be stacked / connected together to build bigger solutions and to keep complexity manageable.
Go is in fact anti-simplicity. Its lack of generics, given its static typing, is a really good example of a design fuck-up, since for building reusable higher-level abstractions, one really, really needs generics and this is an objective fact - note that we aren't talking about dynamic languages here, which don't care about static typing or for being close to the metal. There's no point in denying that and Go will end up like both Java and C++, both of which didn't have generics in the beginning - and so it will end up with a half-baked solution with lots of corner cases and that people will hate, until the next language comes along also lacking generics, because "simplicity", repeating the cycle ad-nauseam.
In fact a programming language is supposed to be extensible, because both in natural speech and in our systems, we are extending our language all the time to manage complexity. If this gives birth to features that are harder to learn, that's a freaking drop in the ocean compared to all the shit that we must do when implementing complex business logic. I recommend watching Guy Steele's "Growing a Language" presentation, it's very enlightening: https://www.youtube.com/watch?v=_ahvzDzKdB0
But then again, extensible languages and higher-level abstractions are raising the bar to entry, which often goes against the other generally accepted solution for managing complexity, which is to hire more average Joes that can sit in a chair and type.
> Simple languages are easier to learn.
Familiar languages are easier to learn. There, fixed the typo. And if you're only learning familiar stuff, then you're not learning anything new ;-)
I keep going back to Alan Kay's quote which will be relevant for a long, long time: "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves."
> There's no point in denying that and Go will end up like both Java and C++, both of which didn't have generics in the beginning - and so it will end up with a half-baked solution ...
[I take no position on whether Go should have generics]
Go has one thing that neither of the other languages had: Rob Pike. This is not meant with any disrespect to Gosling or Stroustrup, and I don't know Pike personally, but he has a reputation for sticking to his convictions even (especially?) when they are contrary to "market pressure".
I don't disagree with that. If Go suits your needs, then good for you. My rant is related to my general dissatisfaction with the status quo and personally I expect more from new languages.
I agree that generics is bound to become a limitation as Go get more used in APIs and similar use cases. For now, if anyone interested, here is a way you can get generics like functionality with Go: http://blog.jonathanoliver.com/golang-has-generics/
1) It ignores where Java is being used. It is dominant within the enterprise. Features like a single binary, lack of a reverse proxy or taking advantage of multiple cores aren't at all compelling. We have dedicated ops teams happy to automate deployments, hardware load balancers and are rarely doing anything CPU intensive.
2) It ignores language trends. Functional programming is what is hot right with Scala and Clojure being what most enterprises are choosing to adopt for the next big project. Why ? Because they can leverage all their existing Java libraries/practices but without the boilerplate and language overhead of Java.
3) It ignores architectural trends. Go's concurrency approaches are nice but aren't that special and again aren't that useful in most cases. Unless you are someone like Cloudflare it is far easier to just horizontally scale your app servers across seperate instances. It's more expensive but hardly worth deciding your platform over.