Hacker News Reader

Comment by nimish | Hacker News Reader

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(

View on HN

True, but Go and Erlang don't occupy the same niche.

Go is imperative, while Erlang is mostly functional.

Go is AOT (ahead-of-time) compiled, while Erlang runs on a VM.

Go is statically typed, while Erlang is dynamically typed (I know about Dializer).

Go concurrency primitives are designed to coordinate goroutines living in the same process, while Erlang concurrency primitives are designed to coordinate Erlang "processes" living in the Erlang VM or even in multiple Erlang VMs forming a cluster.

Erlang is AOT, the vm reads compiled and optimized bytecode.

The point is that Erlang (like Java etc) needs a runtime, Go doesn't.

Every programming language has a runtime, even Assembly if the CPU is micro-coded.

How do you think that the GC, go-routine scheduler, cgo marshaling get managed?

I assume what people want to say is that Go requires nothing which other languages install via the system package manager. While "runtime" is not the correct term, the desire is real.

With Java you first install a JVM. With Python you install the interpreter and batteries. This always leads to version conflicts at some point.

In contrast, with Go your CI builds an executable, you transfer that to your server and it runs. You don't have to care about the version of some "runtime" already on your server.

And if you deploy with docker then your build server slaps your java Jar and JRE in a docker image and you deploy one thing. No functional difference.

well to be fair you can do the same in java, python whatever. it is just not as easy as go install/go build. heck in c# you actually only need to have dotnet runtime >= your higehst installed version. basically I think .net core 2.1+ does it better than any other tools, it can be published via `--self-contained --runtime linux-x64` or without. (the runtime is needed since you create a launcher executable)

it's just dotnet publish with the switch or without and you get a folder that you can copy where you need the runtime or where the runtime + start script is inside the folder.

(Java 9+ has something similar but it's way more complicated than just running java publish, etc..)

Using the wrong terms leads to urban myths and misunderstandings.

You don't need to install Java at all, because the JVM can be bundled with the application, and for anyone that actually cares to pay for them, the large majority of commercial Java third party vendors have AOT compilers on their JDKs.

Likewise with Python, there are several solutions how to bundle a set of scripts with an executable.

I thought it was pretty obvious that the OP was using "runtime" to refer to an external interpreter program. The significance being the simplicity of deployment.

That is an interpreter as you very well mention.

Sometimes things have multiple names :shrug: I really like your contributions; this one seemed unnecessarily pedantic.

Which any CS book clearly clarifies.

I didn't think it was all that obvious, and after I read the OP's answers I thought he was complaining about distributable size, instead of deployment procedures.

You're right. I oversimplified a bit too much.

I should have write: Go produces native binaries, while Erlang runs on a VM.

> full force of Google pushing it

This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcson. I don't know very much about Ericcson, but it wouldn't surprise me to find out they spent many times the amount on Erlang that Google spends on Go.

There are probably lots of reasons why Go is successful, but I'm positive that it has more to do with simplicity, learning curve, tooling, ecosystem, etc than it does with corporate sponsorship or marketing.

Ericsson abandoned Erlang, or Erlang abandoned Ericsson, depending on how you look: Ericsson banned it internally, and shortly afterwards when the Erlang team managed to get it open sourced, they resigned from Ericsson and founded their own Erlang company.

(source: http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_e...)

So does Ericsson still use Erlang in their recent network hardware etc?

I recall hearing no, somewhere. I am under the understanding, (don't know where from) that Cisco DOES use Erlang in their stack, and there is a group of people at VMware that does.

Thanks. This is something where simple internet search yields nothing much. Possibly because these network switches are proprietary platforms and they do not publish how internals are implemented.

I found the Cisco reference https://twitter.com/guieevc/status/1002494428748140544?s=09

Yes. After a few years of ban, Ericsson changed gears. The recent head of tech at Ericsson look at that past as a real miss. All Ericsson 3G switch/router are in Erlang.

Ericsson has a small team maintaining erlang and they are the steward of Erlang.

Armstrong was rehired by Ericsson in 2004 [1], and a team at Ericsson maintains the language today (see e.g. [2]).

1: http://erlang.org/pipermail/erlang-questions/2006-July/02136... 2: http://blog.erlang.org/

Very true. Go has proven big success outside Google.

So many people here argue here that Go is not good enough else why Google keep using other languages even now. But same people argue in Apple/Swift case "of course Apple need not rewrite all perfectly working applications in Swift". But somehow Google has to do to prove language is fine.

Who do you think pays for almost all of Go's development?

> There is a small team at Google that work on the language

How many languages are lucky enough to have paid developers working on them?

Many languages have been labours of love with 1 developer getting paid, at best, pennies or doing it on the side.

I think there's a reasonable middle ground where you can claim "Go made good choices, but it also wouldn't exist as it does nor be as popular without google throwing money at its developers and without the brand association"

For example, the D programming language was wonderfully made and had many great features, but it never got all that far, in part because "Built by Mars" isn't as good as "Built by Google".

Sure, Go didn't just win by default because google was there (Dart is a good proof that Google doesn't instantly make languages succeed), but I'm certain having their backing and name association sure didn't hurt.

If Pike, Thompson, Cox et al. had stayed at Bell Labs, they would have created Go there as salaried researchers? Or because no one would have forced them to do C++, they maybe would not have bothered... ;-)

Anecdotally, there are at least three people at work who say that "go is used at google so it will be around forever and I can be sure there will be support for it".

I'm sure somebody said the same thing about GWT too.

I actually really loved GWT and it was a shame it withered and died.

Tooling and ecosystem: Yes, but how much did Google spend on developing the tooling and ecosystem? Forget the marketing - libraries, tooling, and ecosystem are where corporate support pays off for a language.

I don't think most of this is true... the Go core team is at least 20ish people, and that's just engineers not PMs, Managers, or other support staff. Plus the tools and kubernetes/gcloud teams. It's also kind of disingenuous to call any team lead by Rob Pike and Ken Thompson "small"... yeah they might not have hundreds of people but they can certainly wield a hell of a lot of influence.

Google also spends quite a decent amount promoting Go and donating to OSS that promotes Go.

You're not wrong about the comparison to Ericcson/Erlang though, or most of the reasons for Go's success, but you can't discount the Google factor.

> This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!".

I chose Angular.js because of google actually. And then Google did me dirty with Angular 2.

Corporate sponsorship is actually a huge driving for my decision and many company too.

Having a big company is a good indicator of success and it says that that programming language will have a stable contributors. Google also are using Go so they also have a stable programmers within the ecosystem.

Getting developers to adopt a tech and be in it is hard. Google have bunch of their dev in it and which increase the chances of these dev will present and talk in meetup to evangelicalize others.

I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead.

The learning curve for imperative programming structure just seems easier for people to understand and work with.

I don't agree. It's just that the familiar is easier. If you first teach someone programming with haskell, they'll have the same hard time switching to C.

Yeah, but is it because people actually like the syntax? Some languages seem to be attractive to people right from the start, like Python. Some take a while to grow on you but then you realise their brilliance and don't want anything else, like Lisp. C isn't either of those.

FWIW, I've disliked the look of Python from the first time I saw it and loved Lisp-like syntax immediately. Can agree on C though.

I don't know about that. I grokked C's syntax immediately, just from reading K&R, without actually having a compiler to try anything on. It just made sense to me.

I suspect (but cannot prove) that certain languages and/or programming styles make more sense for certain people, and others do so for other people. (There also is almost certainly some bias toward familiarity.)

Really? Python's syntax looks clean at first OK then later I realized that it has no variable declaration (and old memories of time lost in BASIC due to spelling errors start coming back), no static typing, is slow and isn't particularly multicore friendly .. uhm how about using Go instead? (No I don't know Go but I'm quite sure I can learn it without too much difficulties)

The impact of syntax is really undervalued. Syntax matters because many people are exposed to new languages through familiarity with other languages, as opposed to cramming a guide in isolation. And since programming languages are for humans, the cognitive load of understanding through reading and expressing through writing depends on one's ability to map the concepts to the code and vice versa.

This is easier when similar languages look and -- through the power of abstraction, appear to -- work in similar ways. Go benefits from looking similar to the wider C family, while Erlang suffers from a syntactic heritage that never achieved as much prominence. The prevalence of languages in the syntactic style of C allows people unfamiliar with Go to be able to glean a lot of what's going on, and develop their understanding of Go-specific features gradually.

Anecdotally, it was really difficult for me to convince myself to learn SQL specifically due to the syntax and the fact that unlike the imperative languages I normally use it was declarative.

My simple smell test for language syntax readability is whether you can write a conditional statement with a multiline condition in it, without it looking ugly, and with the condition being clearly separate from the body. For example, in Lua or Ruby:

   if
      something()
      or other()
   then
      do_whatever()
   end

It's very easy to read; your eye doesn't "stumble" anywhere it doesn't have a reason to. In C (and Java, C# etc), on the other hand:

   if (something() 
         || other()) {
      do_whatever()
   }

This makes for some confusing indentation, and now it's hard to distinguish what's condition and what's body! Sometimes people indent the entire condition to make it clearer:

   if (  something() 
         || other()) {
      do_whatever()
   }

but now you have holes in the middle which draw attention to that spot for no good reason. Or you can put ){ on a separate line:

   if (
      something() 
      || other()
   ) {
      do_whatever()
   }

but so much punctuation hanging by itself is still an eyesore. And Python is hardly better:

   if (
      something()
      or other()
   ):
      do_whatever()

Go doesn't need the () in condition, so it's slightly more tolerable if you do that (but go fmt will object):

   if
      something() 
      || other()
   {
      do_whatever()
   }

But I'll take the Lua/Ruby syntax any day of the week.

That's just one example. In retrospect, I think that C-style syntax was a bad idea in general, and adopting it as the "default syntax" across a large part of the industry was a monumental mistake. It favored compactness and speed of writing over readability and clarity. I really wish something like Modula or Ada would become the syntactic basis of modern languages today. I'd rather spend a few more keystrokes typing out things like "var" and "end", but end up with code that reads smoothly in a code review, or when debugging some ancient codebase.

Syntax is a crucial component of any programming language.

I would disagree, though, that there's anything inherently easier about imperative languages. Could it not be that it's simply more familiar to people today? People don't (IME) learn to program in school. They learn by futzing around with whatever free thing is on their computer. In the 1980's we had BASIC, and today we have JavaScript, and Python/Ruby/Java/C# also seem to be popular. At this point, imperative programming is winning because of path dependence. Nobody ends up using Erlang by accident.

Once you get to concurrency, functional languages are clearly punching above their weight. I find it impressive that Go makes imperative programming work well here, but it still looks a bit old-fashioned to me.

Is Go leading the pack by having a great concurrency model, yet with an imperative language that runs on bare metal? Or is it trying to hold back the tide, when almost the entire rest of the industry is solving concurrency by moving to functional languages running on a portable VM? I don't know.

It's hard to disambiguate familiarity, but I'd suggest that imperative languages are more similar to spoken/written human language, particularly english.

I'd suspect if you gave someone who didn't know lisp or java a simple program and had them try and explain what it was doing they'd have more luck with understanding the java syntax.

It seems like you’re saying the primitives don’t matter at all?

I see three major programming styles: imperative, declarative, and functional.

Declarative seems extremely popular these days (see Rails, CSS, Webpack, etc). My guess is it’s because it’s fairly obvious how to design a declarative API. You just think about what you’d want as an application programmer, write that down in English, and then target that with your implementation.

These interfaces are totally unstable, and so they just degrade with time but they’re so easy to stand up they dominate the field.

Imperative interfaces are a bit harder because you need to explicitly pass all of your data through every call. This is laborious at first and you have to do lots of refactoring of the interface as you implement it. API developers generally don’t like this feeling, and would rather have a stable interface to target and only futz with the internals. And it takes longer and requires more pondering when you can’t just reach directly into arbitrary parts of your code base and do whatever TF you want. And since APIs are usually released before they stabilize, application developers also don’t like seeing their interfaces move.

Functional APIs are like the imperative ones but even moreso. Not only do you have to pass around data explicitly all the time, you have to model every intermediate state in your data explicitly too.

This is even more constrictive, which just makes all of the above even worse.

Personally, I think this pain pays off in the end, and I code in a purely imperative style deep in a haunted wood. The suffering over moving interfaces eventually leads to a stable interface that’s actually well thought out and composeable. Code can become “finished” whereas declarative code almost always just rots til it’s replaced.

But in terms of “Don’t make me think” which is most pro developers dominant mode of working, there is a clear declarative > imperative > functional hierarchy.

In theory a purely imperative or purely functional ecosystem could gain a kind of network effect of good code that would eventually outweigh the work slowdown.... your application code would be harder to write, but you’d be writing on top of a richer, more composeable library base.

However we don’t seem to observe this in practice.

My theory is that imperative and especially functional languages tend to attract masochists, who get yakshorn into radical experiments into purism, trying to bend every aspect of an ecosystem into a perfect Q-dimensional prism. This leads to just less effort in churning out pragmatic tools. And it also leads to a kind of dazzling conversation around the languages that turns away people who are just trying to get something done.

With sustained effort these effects could be overcome. Over time I am building a library of pure imperative JavaScript modules. They seem to be reaching “finished” one by one. We’ll see.

Every time I see people saying stuff like that I remember of this:

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

> His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

Anyway, it's not because C-like languages are any easier. It's just that nearly all programmers learn to code in a C-like language. Most of them won't ever learn a second language, the number that will do the work of learning something actually different is minuscule.

It's also not simple... at all.

Reply on news.ycombinator.com