Is Java the Cobol of tomorrow and Go the Java of the future?
influxdb.com
influxdb.com
> 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."
I think its just a matter of Go arriving at a good proposal for generics.
[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".
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.
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.
I mainly think without IBM failing to launch OS/2 and lending their support to Java, it would be in a very different market position nowadays.
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.
So politics was certainly not the only factor.
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.
Did they? Why?
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.
Microsoft failed to see what was coming when IBM/Sun/Oracle pushed java, true. But go back to a bank department today and take a look.
C# everywhere.
.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.
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.
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.
You can write code in typical imperative fashion but all blocking IO statements will cause a co-operative green thread switch.
Rust was also experimenting with green threads and similar async IO but they recently changed to use all-native threads.
I'm pretty sure that I/O is only task-blocking in Rust, and tasks can be 1:1 or M:N with native threads.
tasks can be either 1:1[0] or m:n[1]. The default is 1:1, but m:n should be equally supported by force-booting with libgreen[2].
[0] http://doc.rust-lang.org/native/index.html [1] http://doc.rust-lang.org/green/ [2] http://doc.rust-lang.org/guide-runtime.html#force-booting-wi...
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.
Pretty sure they know a thing or two about "real threading".
And data structures in Go, that's just plain painful.
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.
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.
That quote succinctly captures the essence of the problem with Go: it's warmed-over hash.
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)
So yeah, there are better solutions today.
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.
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".
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.
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.
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...
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.
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.
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
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.
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.
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.
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.
If this is the case, maybe you should check the doc: http://golang.org/ref/spec#Arithmetic_operators
try this: http://play.golang.org/p/WA0vX7zmNb
I'll leave a copy of the code so you can try it locally as well (and in case the link to play.golang.org breaks)
package main
import "fmt"
func main() { a := 47 b := 6 c := a % b fmt.Println("input: ", a, b) fmt.Println("output: ", c) }
[edit]: someone beat me to it :/
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!
If so, does that make Go the COBOL of the day after tomorrow?