Several weeks ago Steven Degutis posted the slides (1, 2) from his excellent presentation, The quest for the perfect programming language. In reading his slides I was reminded of a blog post made back in 2007 by Steve Yegge called The Next Big Language.
2007 was a different time for languages. While Java held the popular crown, the mainstream programming community were still coming to terms with Java 6. Released 3 months earlier, it was very much an evolution of the Java 5 watershed. Its arrival heralded the end of life for Java 1.4 and represented an opportunity to draw a line in the sand for a Java that assumed Generics and Annotation Processing. In turn this created an opening for alternate JVM languages like Groovy, JRuby and Scala, raising the discussion to a din and giving developers pause to consider a wider field of alternatives.
At the time, Yegge left me with the impression that D was his pick for the Next Big Language, although he suggested that the Next Big Language was not amongst the set on the market at that time. This fit my world view as I had just discovered D and felt chuffed to be on the inside track of this up and coming language. D had everything that opened and shut; template metaprogramming, fast compilation, function literals, C like syntax and a memory model that someone coming from Java could grok. Two years later however, D was still stuck in 2007. This was in part due to the infighting between the standard library camps who had failed to learn from the mistakes of the Java class library and were busily adding bloat and verbosity to Phobos and Tango. Similarly those who wanted to hack on the language were bifurcated by the closed source DMD compiler and the slow moving gdc frontend. D may have been an excellent choice for those who wanted a better C++, but it wasn’t clear if actually was a market for a better C++.
At this same point in 2007, Rob Pike and Robert Griesemer were sitting, probably not far away from my office at the time, thinking the same thing. It took two years, and the addition of stalwarts like Ken Thompson, Russ Cox and Ian Lance Taylor for their creation to reach fruition; and several more years for their new language to gain mainstream awareness.
Therefore, with the benefit of hindsight that history provides, I would like to revisit the major points of Yegge’s Next Big Language, and address them in the context of Go.
Update: Go is licenced under a BSD like licence, not the MIT licence. Thanks to the astute readers on HN for noticing my mistake.
Update 2: The names of the D standard libraries are Phobos and Tango. I have also updated the list in rule 5 to be a table at the request by request.
The NBL does not replace C++, the NBL is garbage collected.
As Yegge said at the time, there will always be a bunch of engineers who think that’s evil, and they’ll continue to use C++. I think the experiences of D have borne that out, but more importantly there is a lesson to be learnt that there is no one single language that is appropriate for all tasks. Go, as a general purpose language, is a mixture of decisions and tradeoffs that place it in the best position to reach and be relevant to mainstream developers. The choice of a garbage collected runtime was obvious for a language that held concurrency as one of its core tenets.
The NBL will have corporate backing
Looking at the origins of Java, Python, C++, Scala, with the notable exception of Ruby, Go follows the trend of having a strong corporate or academic benefactor. Google are generous and passionate supporters of Go, and while the Authors work for Google, there are many external contributors who have made substantial ongoing contributions to the language. Just as importantly, the entire project is BSD licensed (something which D was not able to do, and suffered for it) and driven by passionate, opinionated leaders. To my mind, this is the best of both worlds.
Rule #1: C-like syntax
I think of this as a courtesy to people who already have an investment in an existing mainstream language. The syntax of Go is spartan, and takes little opportunity to further this area of language design, instead leaving that to Scala or Haskell. Go’s most powerful claims in this area would be the adoption of the go fmt source code formatting tool and the elision of semicolons, both of which have a subtle, but profound impact.
Rule #2: Dynamic typing with optional static types
Go answers Yegge’s call by providing a static language with dynamic typing features through the pervasive use of interfaces and automatic type deduction.
Rule #3: Performance. The NBL will perform about as well as Java
For workloads which have at least some IO component, Go is as fast as Java or C++. It produces efficient, statically compiled programs that can be deployed trivially without the overhead of a large runtime framework. Go programs perform as fast on their first cycle as their last, without the need for witchcraft often associated with languages targeting a JITed interpretor. While it may not be possible, because of Go’s more conservative approach to pointer arithmetic and memory safety, to best the raw computational speed of C, performance is a core design goal of the language and will continue to improve over time. Even now, I have no hesitation in recommending Go to displace any programming task which would previously have been targeted towards Java.
Rule #4: Tools
By comparison with Eclipse or Visual Studio, the automated tools available to Go programmers are limited. Taking the age of the language into account, this is to be expected. Interestingly for authors of Go programs, the experience is more akin to their dynamic cousins like Python and Ruby, who bucked the trend years before by adopting simple programming environments that offered little more than syntax highlighting.
Rule #5: Kitchen Sink
I’ll move quickly through Yegges list of must have features as their discussion would span several posts alone.
| Object-literal syntax for arrays and hashes | Yes | |
| Array slicing and other intelligent collection operators | Yes | |
| Perl 5 compatible regular expression literals | No | |
| Destructuring bind (e.g. x, y = returnTwoValues()) | Yes | |
| Function literals and first-class, non-broken closures | Yes | |
| Standard OOP with classes, instances, interfaces, polymorphism, etc. | No | |
| Visibility quantifiers (public/private/protected) | Yes | |
| Iterators and generators | No | |
| List comprehensions | No | |
| Namespaces and packages | Yes | |
| Cross-platform GUI | No | |
| Operator overloading | No | |
| Keyword and rest parameters | Yes | |
| First-class parser and AST support | Yes | |
| Static typing and duck typing | Yes | |
| Type expressions and statically checkable semantics | Yes | |
| Solid string and collection libraries | Yes | |
| Strings and streams act like collections | No |
The final tally is 11 affirmative, 7 negative, but with the addition of items from the next paragraph, specifically threading and continuations, I believe Go answers many of the import must haves for a mainstream language entrant. While languages like Julia or Rust approach 100% coverage of Yegge’s laundry list, it is still to be seen if they will achieve mainstream adoption.
Rule #6: Multi-Platform
Go provides outstanding cross operating system and cross architectural support. Rather than adopt Java’s lowest common denominator approach, Go allows both an escape hatch to access features specific to one platform, and a simple file name based conditional compilation system to provide platform specific implementations without having to resort to interfaces.
Rereading Yegge’s essay five years after it was published, it is clear to me that even, as Yegge claimed, he had no knowledge of the ruminations of his colleagues, the stage was set for the Next Big Language.
I believe that Go is a strong contender for the Next Big Language and I urge you to give it serious consideration.
What about Dart? You didn’t even mention it.
Dart seems to match almost all the features of Yegge’s NBL.
He seems to have a thing for dynamically typed languages so it’s much more likely to be Dart.
Yup, I didn’t mention Dart because I don’t believe it will become the Next Big Language.
That’s very interesting. What makes you think so?
– Dart may become very performant (ex V8 team is working on it)
– has nice ide from day 0
– C like syntax
– less verbose than Java and C#
– optional typying
– corporate backing (Goog)
– cross-platform
– can work on server and client (compiles to javascript)
and last but not least vm *has snapshots for increased startup performance*
That, and dart doesn’t have a static type system. ;-)
Dart has a much better chance at the best language than Go…
Dart has more backing and more resources behind it, Includes better IDE support (even JetBrains is developing a Dart Plugin), is optimized for iteration times, will be the only other language that runs in a browser (native in Chrome / transpiles to JS in other browsers), is dynamic runtime with optional static typing (extremely productive). Includes snapshotting for instant start times and has the original V8 team behind it ensuring it carries semantics for a faster runtime.
Dart is pretty much better than Go in almost every point Yegge mentions. JavaScript is now the most used language in GitHub https://github.com/languages – the next big language is going to look like and appeal to JS developers which stands a much better chance of that being Dart (which transpiles to JS), than Go’s C-like roots.
Go’s lack of exceptions, generics or even a proper type system makes it woefully inadequate. It has too much sympathy for the compiler (at the expense of developer productivity) to even be in contention.
There’s no way Go stands any remote chance of being the Next Big Language: it’s stuck being the worst of two worlds, i.e. Not as fast as C, not as productive as a dynamic language.
I understand all of those words, but arranged in this way they make no sense.
Dart is Java+JavaScript, the worst of all worlds.
Pretty much the anti-Go.
That Google has learned nothing from Go and is instead repeating the same mistakes of the mainstream languages of the last 20 years is really sad.
>> Dart is Java+JavaScript, the worst of all worlds.
That’s a nice try at an old tag line, back it up?
Dart is dynamic, Java is static.
They both have C-Like syntax which is what probably has you confused.
Your comment doesn’t make any sense. It seems that you don’t know much about Go and Dart. Both languages have totally different domains. Dart is a JavaScript replacement for dynamic web pages and runs in your browsers virtual machine. On the other hand Go started as a system programming language which compiles to native machine code. Go isn’t a JavaScript replacement. It was mainly designed for servers and backends but it’s also nice for writing tools and native desktop applications.
Yet you have provided no evidence of having any clue yourself. Just a mindless dribble, countering points I didn’t make.
Who cares if a language compiles down to machine code or if it’s JIT’ed or interpreted, the NBL is going to be optimized for productivity + fast iteration times (and IMO has to be able to run in the browser as well). Only 2/10 languages are static langs that compile to native exe’s: https://github.com/languages
>> Go isn’t a JavaScript replacement. It was mainly designed for servers and backends but it’s also nice for writing tools and native desktop
Lol, A Native Desktop with Go? Where are these wonders of beauty?
Chrome packaged apps looks like the area where Google seems to be focusing for the native-like Desktop apps:
https://developer.chrome.com/apps/about_apps.html
I say MAINLY for servers, backends and also for tools and it _could_ be an interseting language for native desktop apps. Mid- and low-level stuff isn’t a typical Dart domain. Today’s languages compete in different areas: Go is somewhere in the middle of C++, Objective-C, Java, D and Rust. Go has also some slight dynamic language influences and gained some attraction from Python, Ruby programmers. Dart was maily designed as an JavaScript replacement. So there won’t be any NBL or ‘one programming language for everything’ because we have to many different domains/requirements/areas of application for a programming language. Get it ignorant dickhead!
BTW: According to your definition of the next big language, Dart also fails: It is not as fast as C and not as productive as a typical dynamic language like Python or Ruby. So with Dart we have obviously the worst of two worlds….
Wow, the lack of awareness from people astound me. Just because you have access to a keyboard doesn’t mean you have to subject others inability to comprehend the written word.
Let me spell it out for you:
Next – i.e. the one after the big languages before it
Big – i.e. Big as in popular (as in used by a lot of people), not code-size
Language – i.e. Any Programming Language, not systems
No one is saying you should build an OS or high-perf network servers with a dynamic language – native languages will always have their place. The NBL refers to the next general purpose language that will be used by most devs, judging from GitHub it’s JavaScript now, for the future Dart stands a much better chance than Go.
>> So with Dart we have obviously the worst of two worlds….
Spoken like a professional commenter, feeling free to pass judgement on tech they’ve never tried before (I’ve at least used Go, Python + Dart).
Dart’s optional typing, good IDE support with “batteries included” libs (optimized for iteration times), syntactic sugar actually make it more productive Python – for me anyway. Also it’s a lot more productive to develop client-side web apps with it, where every other language apart from JavaScript is a non-starter. There are two languages that can develop “full-stack” client/server apps (that can run natively, in a browser / Chrome at least), one is currently a “Big Language” now, Dart could be easily be the “Next” one – either way, it stands a much better chance than Go.
>As Yegge said at the time, there will always be a bunch of engineers who think [garbage collection is] evil, and they’ll continue to use C++. I think the experiences of D have borne that out…
How so? D gives the programmer full control to delete objects whenever you want to, just like C++. The garbage collector is only there in case you don’t.
As a lifelong C++ programmer, I find that D is what I was really looking for this whole time. (And I only just found it recently.) It takes me a long time to make a major switch, but when I do, I can’t see it being anywhere but D.
That doesn’t sound very memory safe. I thought D was generally memory safe.
You thought correct. D is generally memory safe. Most D code won’t have manual memory management because the garbage collector is there and easier to use.
However, in performance critical sections of code, D allows you to do what you can in most other lower level languages (like C++ or C) … how else could it replace them as systems programming languages?
AFAIK, Yegge was referring to an updated version of Javascript when he wrote that Essay. But from everything I’ve been reading lately, it’s sounding like Go is progressing at a very nice rate.
I think shortly after this post Yegge spent 3 months of his 20% time porting Rails to Javascript so you may have been right there.
Lack of exception-handling/try-catch-finally makes this a no-Go.
I wrote about my thoughts on exceptions here.
Maybe NBL isn’t a single language, but a platform in the sense of JVM and .NET?
I imagine this mythical platform having a few (3 or 4) levels of language:
* assembly, if you really must
* a low level language, like C/C++/D for where performance is necessary
* a moderately high language like Java/C# (others?)
* a high level language like Python, and others
The platform would, of course be cross platform, and would have a very extensive runtime library.
This is obviously an incomplete list, but should be sufficient to get the idea across. We have enough languages, what we need (IMO) is a robust, capable and performant Runtime for what we already have.
ISTR that Yegge actually said “It’s Javascript” at a talk shortly afterwards. Javascript is still a very likely possibility due to its ubiquitousnous.
Unfortunately I have little hope for Go or any other standalone language as the NBL at this point, for reasons I haven’t seen enunciated elsewhere…
=== Warning: High levels of snark ===
Basically Java succeeded *because* it was C++-like, as C++ succeed because it was C-like.; it said “Hey middling C++ programmers, if you move to us you won’t be too out of your depth”. For that reason, whatever comes next will need to follow this same pattern; it must be somewhat Java-like, while introducing new constructs. Javascript has this, and has JVM compatibility, but is probably a bit *too* like the past to make a difference.
Scala, however, has all the hip buzz-words and newness to make it attractive to programmers who secretly think they’re mathematicians while allowing them to drop back to the comfortable Java model while the training wheels are on. For example, it calls itself a functional language, but it has mutable data-structures FFS.
Personally I had hopes for Clojure, but I realise that the same people who think that knowing what a Monad is makes them mathematicians also think they’re being hip and edgy by pointing out that Lisp has a lot of parentheses.
What does that even mean?
Regarding tool support, I can’t help but cite the plugin for JetBrains’ IDEs. It used to be broken a few months ago, but now it is -in my opinion- one of the best development environments for Go. (I may be biased as a long-time PyCharm user)
Regarding generators and iterators, it is true that Go doesn’t have them but you can easily replace them with unbuffered channels and goroutines:
func generate(max int, out chan int) {
for i:= 0; i < max; i++ {
out <- i
}
}
func user() {
stream := make(chan int)
go generate(100, stream)
for _, it := range stream {
fmt.Println(it)
}
}
As pointed out many many times by the go team, using this technique to create generators is a slow and inappropriate (non-idiomatic) way to go. As Rob Pike stated just a couple weeks ago, “there’s no parallelism in [that usage], so you’re adding overhead to a sequential computation.”
nice article! it of course presumes that yegge is correct. i generally agree with yegge, and your own conclusions
yegge’s crytal ball wasn’t perfect. the pervasiveness of javascript has put it into contention as a general purpose language with the advent of node and its associated tools.
yegge also skipped the invasive nature of platform-mandated tools. without apple’s support and mandate, you wouldn’t be able to fill a bus with objective-c programmers. but look at where it stands today. by the numbers, objective-c *already is* the next big language. android provides a similar assurance for java’s future (as if it needed it).
go has managed to become a success because people like it. no one is being forced to use it…it doesn’t even appear to be given primacy within google itself. i expect go to follow a trajectory of moderate organic growth unless it is somehow mandated by a platform or application that catches fire (i.e. rails)
> yegge also skipped the invasive nature of platform-mandated tools. without apple’s support and mandate, you wouldn’t be able to fill a bus with objective-c programmers.
Which is a shame, because Objective-C is actually a very nice language, independent of Apple pushing (and improving it) heavily. Especially with the latest additions to the language (blocks, ARC, literals for things other than strings) it checks most of the boxes to be the NBL.
Which goes to show that popularity of a language really doesn’t say anything about how ‘good’ it is. If an atrocity like JavaScript is now one of the most popular development languages, taking over from probably the most unpleasant mainstream language to develop in (Java), all while a great language like Objective-C had to whither until the resurrection Apple, I think you can safely say that most developers simply follow the herd and pick what all the other cool guys are using.
“Wither”, and you make (mutatis mutandis) an excellent argument for Oberon.
The nbl doesn’t exist yet. It has to make the mediocre corporate developer much more productive as java did over c++. Nothing can do that as of now. There are several technically superior languages compared to java but that isn’t what is needed to be the nbl.
You’re spot on with this comment.
More precisely, I think Yegge said NBL was Javascript 2 (or ECMAScript something.x), as the optional static type was part of his shopping list.
Except that javascript evolved much more as an ecosystem (much faster browser and vm, server-side with node, improvement on libraries, amd, etc…) than as a language – which might come from the fact that it is is mostly a LISP in disguise.
Rule #5 should be formatted in a list table, or a table with checks/crosses. Very hard to read.
I do hope you’ve not given up on D. It’s been three years, and I think you’ll find it a somewhat different situation now. The community is growing quite fast and D2 handily dismantles all of the arguing about Phobos/Tango (by allowing them to coexist). Once we manage to get rid of optlink it’ll be even better. But don’t take my word for it. Grab a copy of Andrei’s TDPL and give it a read.
Interesting Article.
I like FreePascal – Runs as Fast or Faster than C++, compiles way faster than C++, just as capable as C++, strictly typed, open source, platform independent, Object Oriented, syntax is less cryptic than many popular languages no garbage collection – most programmers aren’t afraid to both create and destroy their objects; anything else breeds potentially bad habits. Often Pascal is looked at like a kid’s toy but its grown up along everyone else – just less mainstream.
C++ is fine – just not as easily portable and compile times are awful.
Javascript in the browser – Perfect.
PHP – For writing web apps – great if you don’t need binary speed (though compiled is faster than not – still doesn’t perform like writing binary apps.
I think people popping up new languages all the time without really improving anything over the years equates to one thing: Lots of time wasted learning new languages. Am I against learning? No – Just learning useless stuff. I say learn many languages to get by – but pick only a bare minimum (1 to 3?) to really dig in and master: You’ll be glad you did regardless of the language, it/they will become your power weapon of choice!
Oh, and use the right tool for the job – this is why you learn many languages – so you at least know what to use for a given situation…steps off soap box
One important problem with Go is how the hell do you search for a job using it without getting roles that require being a “go getter” or, if you search “Google Go”, a “go getter” that helps optimise Google searches.
At least C#, Java even C etc are all words that you won’t see in the context of a role description. They may as well have called it “porn”, then tried to recruit people who knew it, it would have been more fun. Am I missing some trick in searching?
The common workaround is searching for golang.
Thank you for that. I will give it a try.
I don’t care what language will be the biggest. It is likely to be yet another mediocre one. I want to know which will become the best (for any given task).
I like Go but it suffers terribly from a lack of generics. If the Go team implemented generics I think it would just about hit the sweet spot.
Daniel, you can utilize Go’s implementation of interfaces for generics. A method, or collection can be specified to hold a type of interface.
In go there is no explicit declaration of implementing an interface, it’s implicit, as long as your object has the methods of the interface, it’s said to implement it.
with that being said if you need to support say an array of generic types you can make an array of the empty interface, which because it has no methods, so all objects implement it.
[]interface{}
Then inside your method etc, you can use a type assertion foo.(Type) to ensure the object is of the type you need.
Pingback: Basin of Attraction #3 « gradientdescent
I love how people hate on languages and things they don’t fully understand. Go is not designed to be the end all be all do everything language, neither is Javascript, or D, or Dart etc.
Each language has it’s place, they are designed to serve specific purposes, Go for anyone who has to write highly concurrent, multi-threaded native apps is a god send. It makes building multi-threaded applications, and communicating data and syncing between threads, ridiculously easy.
Let javascript be javascript, and let Go be Go, let them continue to pioneer and get better for the purposes they were designed for, if you’re everything to everyone than you suck at all of them.
These arguments get ridiculous, it’s like arguing over wether a Motorcycle/Car/Truck/Van/Bus/Train/Helicopter/Airplane/Bicycle/Segway is the best mode of transportion.
And just as this pointless argument about programming languages, the answer is the same, it depends on what the circumstance is, and none of them is the best choice 100% of the time.
So if you work in the web field, look for languages that are targeted and the best for that, argue for what you believe is best for that field, if you write native binaries, or embedded programs, argue for the features of languages targeted for that space.
The best language is the language that suits your specific project, and what language you and the team you work on are the most productive and knowledgeable about, and that may change on a project per project basis, and that’s ok.
Pingback: Issue 18 – Raspberry Pi and JavaScript with Ernest Hemingway — TLN