Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of thinking.
Those people won't get Go.
Designing a language is not about cramming every feature you can think of. It's about making good trade offs.
A trade off is: you get something but you also loose something.
I use Go because it made the biggest number of good trade offs.
Or to put it differently: I program in Go because when writing code, it irritates me less than other languages.
If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flattering, however locally practical it may be.
If people disagree with you, your default assumption should be that they are looking at different evidence than you, not that they are incompetent or stupid.
Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?
We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples.
Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre programmers, not for high productivity from a small team. Go is a perfectly good Java 1.4.
(There's Docker using Go, but I think their whole approach is a bad idea).
We could also look at the open source world. For every riak there are 10 java sucesses of a similar kind.
We'd need to do some real statistics but my bet is that we see no benefit from those languages in terms of success of the business.
But that's not the question, is it? There are a lot of companies succeeding with ruby or node, but also a lot of companies failing with them. I'll bet the strike rate is better for Erlang companies.
(In my limited experience I've seen a 100% success rate for companies that use Haskell and a 0% success rate for companies that use Go, though as you can imagine I don't have a statistically valid sample size)
Go gives you kind of safe concurrency, Haskell gives you actual safe concurrency.
Like these?
https://www.haskell.org/haskellwiki/Haskell_in_industry
https://www.erlang-solutions.com/industries
“I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala.
I don't think anyone would accuse Odersky of being a "blub programmer."
"Beating the averages" is not a very good essay, I don't think you need to drag it in here.
But to call someone a "blub programmer" does come off as quite rude.
Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful.
EDIT: To respond directly to the Blub article.
Features pg calls out for LISP:
Garbage collection, introduced by Lisp in about 1960, is now widely
considered to be a good thing. Runtime typing, ditto, is growing in
popularity. Lexical closures, introduced by Lisp in the early 1970s, are
now, just barely, on the radar screen. Macros, introduced by Lisp in the mid
1960s, are still terra incognita.
Garbage Collection [x]
Runtime Typing [p]*
Lexical Clusures [x]
Macros [ ]
* Go has some dynamic typing capabilities but nothing like Python or LISP.
Many would consider that a "good thing". It partially depends on what you
are doing.
I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP.
EDIT 2: To add some more fuel to this fire...
pg concludes the article with:
During the years we worked on Viaweb I read a lot of job descriptions. A new
competitor seemed to emerge out of the woodwork every month or so. The first
thing I would do, after checking to see if they had a live online demo, was
look at their job listings. After a couple years of this I could tell which
companies to worry about and which not to. The more of an IT flavor the job
descriptions had, the less dangerous the company was. The safest kind were
the ones that wanted Oracle experience. You never had to worry about those.
You were also safe if they said they wanted C++ or Java developers. If they
wanted Perl or Python programmers, that would be a bit frightening-- that's
starting to sound like a company where the technical side, at least, is run
by real hackers. If I had ever seen a job posting looking for Lisp hackers,
I would have been really worried.
Python Score Card
Garbage Collection [x]
Runtime Typing [x]
Lexical Clusures [x]
Macros [ ]*
* It is somewhat possible through black magic hackery to create an AST level
macro in Python. It is messy. It is cool. It's kinda crunky. And I am not
sure anyone has ever seriously used this ability. It certainly isn't main
stream. Checkout https://github.com/lihaoyi/macropy for inspiration.
Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.
Rust doesn't do that. Rust expands the macros at compile-time. Integrating the whole compiler into the runtime wouldn't make much sense considering what area Rust is targeting.
It's also recommended to not link a crate that is used during runtime with the compiler or parser because they're fairly big and would bloat your final build by a large amount.
I recently needed to dive into a legacy Scala code base which had not been worked on in a year. The engineer who had written it had moved on from the company and no one knew how it worked. The code was extremely difficult to read and reason about. Some of this was do to the programmer who wrote it but some of it was also do to language features. Is it possible write clear and concise Scala? Absolutely! But, the language does not necessarily encourage that style at this time.
Other functional languages I have used include: Scheme and SML. I want to check out OCaml next. I have also played around a bit with F* (not F#).
The strong typing and lazy evaluation of Haskell makes it easy for functions to take only one argument at a time. Although a function could take a tuple parameter, it is usually rewritten to take each component of the tuple as a separate parameter, which makes the strong typing and built-in currying simple, higher structures like monads possible, and a syntax to suit this style. Lisp functions and macros, on the other hand, must be variadic to enable the homoiconicity of the language. It's therefore much more difficult for parameters to be typed, or to curry them. The syntax requires explicit visual nesting.
The poster child of each style, monads and macros, are thus two peaks in language abstraction simply because of these different required foundations of each, and if you, lmm, have achieved Haskell-style enlightenment, then dynamic variadic homoiconic languages are your blub.
No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.
You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.
However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do. And humans have brains. And brains are limited in their ability to do some thing while keeping other things in mind. And if among other things types happen to be present and mistake was made, than one could say types added to that mistake. And if types were not something programmer needed to think than type system certainly didn't add to that mistake. Things are not as simple as most programmers tend to think. Features don't matter how they think they matter. And research in language design was broken since the beginning of times and, sadly, still is.
(if you read "no silver bullet", "out of the tar pit" papers and couple of recent ones on bugs you should get the idea of how bad things are with mistake-making research)
Rust on the other hand has been a far more ambitious project, with very lofty goals. This has meant that the Rust team has needed to do a huge amount of experimentation and iteration, culminating in the tight set of core semantics that you see in the language today. It's not been an easy journey for the them, but a great deal has been learned in the process, and even if Rust never 'makes it' into widespread usage, its contributions to the field of programming language design will be felt for years to come.
This is not to diminish the efforts of the Go team - they have produced a really tight, polished language, with an excellent set of bundled libraries. All I'm saying is that they weren't starting from scratch, and had different goals to the Rust team. That has meant they could get to a stable language much faster.
https://web.archive.org/web/20091113154825/http://golang.org...
That looks a lot like today's Go. All of the major design decisions were made, distinctive Go concepts (slices, maps, interfaces, goroutines, switching on concrete type, etc.) are all present. Most of the code examples would compile today with only a few tweaks (if any).
Suffice it to say that Rust was not in that state in 2010. It was barely in that state by 2014. Go was released as a beta; Rust was released as a pre-alpha. That isn't a judgment of either language or community.
Indeed. And the hallmark of the really good design is to examine the interactions of those features and see how well they mesh together. And what they imply about how actual programs are designed and maintained.
And remember not to equate popularity with quality. We're all using JavaScript because that's what you need to do in the browser, not because it's a particularly good language. (Not that Go doesn't deserve the adoption it's gotten. It's great to see people ditching clunky Python/Ruby/C++/JavaScript stuff for Go.)
This is how I feel too. There are countless styles of prose, but some styles are restricted deliberately for aesthetics or practical reasons. I prefer to write prose in plain terms, and Go enables me to write code the same way. Some languages more than others have parts that stick out in odd ways, and add unwelcome personality to my code.
Yet sometimes I wish to put higher concepts into abstract terms, and Go is less expressive here. You can't always shape things the way you want, and you can't build reusable parts with the same flexibility as in other languages. But, when it comes to tinkering and giving form to ideas, I am more productive working with a basic set of LEGO than a box of all the specialized pieces someone may have thought I might ever find a use for.
Because Google.
In longer form, because Google is big and Go is well-enough-adapted for problems Google has (there may or may not be better solutions, and there may be some NIH factor going on in Google favoring it, but its at least good enough), and because the fact that Google is big and behind Go, that gets it lots of attention and interest and use even in places where it may not be as well suited as alternatives or what it is replacing.
Programmers liking confortable algol like syntax, and Google pushing it?
* Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time.
* Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine.
* A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads)
Lots of languages have green threads, but not all these properties.
I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.
I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access.
I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)
For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?
Java is a blue collar language. It's not PhD thesis
material but a language for a job. Java feels very
familiar to many different programmers because we
preferred tried-and-tested things. do_stuff() ->
GetAnswer = fun() -> 42 end,
spawn(fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end).
I've, been programming for 20+ years and I look at that code and say what the f*k?
Ooh, it's the functional stuff. Ok, move on.
Let me take you through it:
do_stuff() ->
function do_stuff() { ... }
do_stuff() -> a, b, c.
function do_stuff() { a; b; return c; }
GetAnswer = fun() -> 42 end,
var GetAnswer = function() { return 42; };
spawn(...)
fun() -> io:format("The answer is ~p\n", [GetAnswer()]) end
function() { return io.format(
"The answer is ~p\n", [GetAnswer()]); }
Complete version:
function do_stuff() {
var GetAnswer = function() { return 42; };
spawn(function() {
io.format("The answer is ~p\n", [GetAnswer()]); });
}
The thing is, the syntax we found nice is usually nice because it's familiar. Many languages could seem like an incomprehensible mess if you're used to C-style brace syntax. But that's purely a question of familiarity. If you don't know what all the bits and pieces mean, you're going to be alienated by it. A developer who has grown up on COBOL and Forth will not find JavaScript syntax familiar any more than you find Erlang syntax familiar.
I suggest stepping out of your comfortable protective shell and trying it out. It's not rocket science. After 30-60 minutes reading this book you'll no longer find it alien, I bet:
But in the end it doesn't really matter that much. Go and Haskell are completely different languages for different purposes (getting stuff done in regular companies vs. doing interesting PL research or more advanced development in companies with little turnover.)
We actually have transactional and non-transactional channels as well, which is pretty cool.
Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.
1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful.
2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right place, which is undoubtedly a mark against Haskell, though perhaps not a huge one.
3. Things like STM, MVars, and (now) LVish let this happen in all kinds of ways. The only problem might be picking the right option due to the wealth of choices. Fortunately, the right answer is almost always STM.
I'd be more than happy to translate a task to demonstrate these things.
Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint.
I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.
7.4, last time I checked.
goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.
Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?
Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.
Simplicity - the main feature is all the interesting things they left out.
If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.