Hacker News Reader

Comment by c3534l | Hacker News Reader

Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't. It's not enough to have a cool idea for a language, even if your cool idea is not to put any new cool ideas in the language. You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real and will be supported for many years to come, and will have a healthy ecosystem. If I had made Go, no one would be using it right now. Network effects matter in languages. People want all the upsides of the network effects (i.e. the ecosystem and adoption), but none of the downsides (it's propped up by a big company with massive network effects).

View on HN

History doesn't really support that. PHP, Python, Ruby, Tcl, OCaml, Lua. Successful programming languages seem to come in equal measures from both large corporate backers and not.

There is certainly the need for network effects which large corporations often can provide more consistently, but we have seen plenty of examples within the space where individuals or smaller companies have been successful in providing these same network effects.

in the early 90s the languages had to provide fewer features to be considered adoptable. Once people adopted that language they had to expand it.

Nowadays if you want to create a new language there is a minimum set of features everybody expects that raises the complexity quite high. You could just create a bare language but who would adopt that?

Isn't that kind of what Elixir and Clojure did? Neither language is festooned with bells and whistles and both leveraged the Erlang VM and JVM respectively to assist in bootstrapping their ecosystems.

Actually, Elixir did add the bells and whistles to Erlang, sort of. That is pretty much the whole point of Elixir.

I assume OP meant that Elixir is a purposefully small language. It taps into a lot of functionality in Erlang without necessarily re-implementing it. There isn't even a wrapper around the Erlang :sleep function.

Well to be honest there's a lot of functionality in erlang you should probably forget about (like the :http and :tftp modules).

Not to hate too much on erlang, but I would say that beyond being small, as a pushback to characterizing it as "bells and whistles", Elixir brings to the table "21st century" understanding/opinions on what makes for readable and maintainable code (build packaging, first-class documentation, module organization, file types, strings, map-focused vs struct-focused, sane function parameter ordering). As a result, I can confidently onboard a junior into Elixir (especially if they were in a RoR bootcamp) and have them be productive. I probably wouldn't for erlang.

Python came out of CWI in the Netherlands, where Guido van Rossum worked and had previously developed the language ABC. OCaml came out of INRIA in Paris. So both had institutional backing and financing.

While it's certainly a form of institutional backing it's very dissimilar to Google as CWI and INRIA are both research institutes. They would have their own network effects within research and academia, but that doesn't necessarily translate to wider scale adoption.

That's sort of why I threw in OCaml; largely it is still only successful within academia. Python on the other hand had similar beginnings, but has been wildly successful both in academia and in common use.

Different times, different stakes.

Lua was the consequence of trade embargoes in Brazil. It was created with substantial institutional support.

As well as targeting a use case that didn't have much competition (at that time).

> PHP, Python, Ruby, Tcl, OCaml, Lua

Many of those languages came out in the 1990's when the big corporates were busy pushing visual 4GL's to replace programming languages. But programmers prefered to write a Perl ten-liner rather than fire up a visual environment, click on some toolbars to place some widgets on a form, link in the data files using the right-click form, wait while the OS thrashes the hard drive as it paints the screen for the first test, and on and on. When those corps realized they'd dropped the ball, they soon built their own.

My memory of that time is pretty different.

I worked as a programmer in the 1990s, when I got paid to write things in C, C++, Perl, Khoros (I guess that's a "visual 4GL"?), IDL (the array language), VB, SQL, INFORMIX's horrible forms thing (which was not especially "visual"), sh, csh (not my fault), and occasionally Tcl. It's true that PHP, Ruby, Tcl, OCaml, and Lua came out in the 1990s (Python is from 1990, so arguably the 1980s), but they became widely used in the 2000s. In fact, even Perl was considered kind of déclassé until these "lightweight languages" took over the world, and then Perl became déclassé again after being eclipsed by Python, Ruby, and most surprisingly, JS.

(OCaml is not a "lightweight language" and is not like the others, and consequently never became popular.)

I don't recognize your description as corresponding to any events I remember. Sun was pushing Java. Microsoft was pushing C++, then Java, and then when Sun sued them, C#. Apple wasn't pushing much of anything until they bought NeXT, and then they started pushing Objective-C. As far as I know Oracle was pushing PL/SQL and cisco was pushing bletcherous IOS commands. Microsoft was pushing VB, which sort of resembles what you're saying, but VB wasn't a 4GL (the language was just 1960s Basic minus line numbers and plus subroutine arguments) and was actually spectacularly successful at what it did; it just wasn't good at making web sites. Borland was pushing Delphi. I guess in a way Microsoft was pushing Access? Are you thinking of Microsoft Access?

Maybe you were thinking of PowerBuilder? It was spectacularly successful at what it did, too (again, not building websites), and it was a visual 4GL, but it was being pushed by Powersoft, not a big corporate, until (Wikipedia tells me) Sybase bought it for 0.9 Instagrams in 1995. I never saw anybody use PowerBuilder but I didn't use Microsoft Windows a lot.

When you say, "they soon built their own", do you mean VBA and PowerShell, or what?

> Microsoft was pushing VB, which sort of resembles what you're saying, but VB wasn't a 4GL

Every marketing department was calling their company's new software development product/language/whatever a "Fourth Generation Language" back then. There's no actual definition for what it really means. Perl, Python, Ruby, and PHP represent a trend that peaked the 1990's, some came before and some after, so there's no need to read "1990's" literally.

My total memory (i.e. work, study, and hobby) of that extended decade (1985-ish to 2005-ish) was VB, VBA (Access, Excel), Java on Windows, Quattro Pro, dBASE 3+, Perl, Cobol on IBM (and ICL), and a myriad other obscure mainframe languages and mini-languages that probably still get used in banks and insurance companies.

> I don't recognize your description as corresponding to any events I remember

My previous description of that time was quite typical for many of us. For example, I remember in 2001 developing a five-line Word macro for an accounting department on a leftover 386 sitting in the corner running Windows 95 that read in a file couriered in daily from some other company's Unix system that stripped out some incompatible data from each line. After I deployed it into production, the user every morning started Word, opened a Word document that contained a button on a form, clicked on the button, selected the day's file from the floppy, then waited (at the water cooler) while the macro ran. They then renamed the output file so the date was in the name, and copied it from the LAN to the mainframe using some proprietary program, so it could be input (with the funny Unix bytes removed) to the overnight processing run. Perhaps you worked in the other company sending that Unix-based file to us every day, and didn't see the ongoing after-effects of your C++ program that produced the file.

> they soon built their own

C#, Go, Swift, etc.

I see! Thanks for explaining your experience in more detail. That does sound a lot more familiar.

> Everyone's upset that Go is Google's language

is that actually true or is that true of a vocal minority? I've been using Go since 2011 and I'm perfectly happy that it's Google's language; I'm happy to mooch off of their investments. In my seven-plus years of using Go I have never encountered a Go programmer in real life that is actually mad about this.

I think the "everyone" in that statement refers to those who are upset. It probably could have been more accurately phrased as "People are upset that Go is Google's language..."

As to your not encountering a Go programmer who's mad about this, I think that's because you're considering people who are already programming in Go. I suspect people who care never actually start using Go because of their thoughts on Google's involvement. (For the record, I too am fine with it, especially after reading Ian Lance Taylor's response.)

> I think that's because you're considering people who are already programming in Go

um I talk to a lot of programmers that don't use Go. Most that don't use it decide not to use it because of either the type system ("it's not safe/expressive enough") or the garbage collector. I've never talked to someone that said "Go is technically good and I think it would be a good tool but I won't use it because of Google".

That's fair. I only made that assumption because you specifically said "I have never encountered a Go programmer in real life that is actually mad about this"

ah yeah makes sense. Honestly "I have never encountered someone that doesn't use Go because of this, or a Go programmer that's mad about it" is probably a more complete sentiment.

If I had made Go, no one would be using it right now.

It would be really frustrating for you, because assuming people found out about your language in the first place, it would be shot down for not having generics (or something else), and there wouldn’t be any Google fanboys to come defend it. So much of what’s popular is determined by which company is backing it, whether people want to admit that or not. Pure bandwagoning.

I know of more than one organization that have decided against Angular in recent years primarily because of Google's backing of the project. Skepticism of the big three (four?) tech giants is growing, especially if you've had some of your market carved out by them.

Yehuda Katz said something a while ago that stuck with me. He likened Ember’s community model to Postgres. That is, relatively small levels of support from lots of different organizations. I think there’s a lot of wisdom is such an approach.

It’s open development vs open source.

Pleasing all pleases noone. Successful products and projects come from a vision that is executed with discipline. Design by committee never works if the committee reaches a certain size. Instead of whining and trying to sabotage Go, why don't you fork it and apply your misguided product management ideas to the soon-to-be-forgotten fork instead? Applause to the Go core team, inside Google or outside it, for creating a great language. Please keep it up!

Just like the inventor of the other language Go. They even filed am early bug asking G to change the name.

Folk were using that Go, but they would use the Google Go.

> If I had made Go, no one would be using it right now.

This made me think of this (thank you for reminding me about it, by the way):

https://vlang.io/

Really looking forward to see where Alex will take this project.

This is vaporware.

How is it "vaporware" when it's been available for the public for more than a month now? :)

Show me a link to the source, and a way to run it myself. I certainly can't find it.

> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.

Brand recognition is not that important for programming languages. It does skew decisions a bit, but people still have to make too many of them when moving to another programming language, so the effect is not that significant. Go just happened to hit all the right spots for many programmers at the time and a bit of marketing turned that into some adoption.

> You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real

Counter-examples: Clojure, Elm.

Sorry, but those languages don't really have adoption outside of small echo chambers.

I've heard about those before. What are they?

clojure is lisp on the jvm. not sure about elm.

I think they were being sarcastic.

oh, duh.

Elm is a JS framework for rendering views. It has a type system and guarantees no runtime errors while being fast. The language compiles into JS.

https://elm-lang.org/

> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.

I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".

What about Ruby?

Basecamp.

Basecamp supports Rails. Ruby is mostly developed by a community of Japanese developers.

That supports OP's theory: Ruby wasn't mainstream before Rails.

While this might have been true, it was that screencast and the rise of Rails that put Ruby on the map in the west.

Basecamp is minuscule next to Google.

Japan. With roots in Japan, Ruby was very popular throughout Asia in the earlier days of the language, before Rails.

Granted, this support was perhaps more cultural than corporate. There's something to be said for a community that grows in your own backyard, has significant documentation in your native language(s), etc.

As of 2011, Matsumoto is the Chief Architect of Ruby at Heroku, an online cloud platform-as-a-service in San Francisco. He is a fellow of Rakuten Institute of Technology, a research and development organisation in Rakuten Inc. He was appointed to the role of technical advisor for VASILY, Inc. starting in June 2014. - From https://en.wikipedia.org/wiki/Yukihiro_Matsumoto

Heroku was acquired by Salesforce.com in 2010.

I don't think so. The better the core team in programming languages, the better the future of the language.

Is that really true though? What abiut python and javascript for example? Did they have a giant corp behind them?

... Python was led by a Google employee for seven years.

One of the first languages supported on App Engine was Python, IIRC.

Does it matter where the person worked? Python definitely was not Google’s or any other corp’s.

Google employed the primary maintainer of Python and paid him to work on it. You asked "did they have a giant corp behind them", the subtext there being that you could complete the sentence "as Go does". I'm merely pointing out that your example of Python is strikingly similar to Guido Van Rossum working at Google while he was BDFL of Python

Of course it matters. That's the whole reason the Go Is Google's Language post exists. And the whole reason the response exists, and this very comment thread, too.

Absolutely not. It is one thing to create a language and maontain it and another to hire someone who created a language some years ago.

from the post:

> There was no mandate or suggestion from Google management or executives that Google should develop a programming language. For many years, including well after the open source release, I doubt any Google executives had more than a vague awareness of the existence of Go

That is a ver very strong assumption. Just because Google did not explicitly have a ‘GO’ team does not mean they did not support it. I assume Google became aware of it the moment their employees started using it for something useful. People have bosses who have bosses. At whoch point they decided to let their employees continue working on it.

Go exists because Rob Pike, Ken Thompson and others are allowed the latitude to make it.

You can be sure that whatever they do gets a high profile without it in any way being "supported" or "official"

It would be more correct to say Google hired the leader of Python and he worked there for 7 years

Is there really much practical difference between that and Go? From the Ian Lance Taylor response:

Wasn't it Google that heavily used Python that popularized it a lot?

And JS was born and evolved with the browser.

Python was picked up by companies like Red Hat at the end of the nineties (e.g. in the Anaconda installer). So in Linux circles Python had already gained quite a bit of popularity.

Javascript was Netscape, and adopted by various other megacorps (such ad Microsoft and ... Google) over the years in various guises.

It certainly is in the last decade or so. Python is a language from the early nineties and took decades to achieve it's current level of popularity.

Javascript was backed by Netscape, and later by Microsoft/IE. It would never have succeeded without corporate backing and being on of the 2.5 usable languages on the web (Java was the other one, I'm counting ActiveX/VBScript as half)

JavaScript is an interesting case, in that it was the only way to write code that would run in Netscape Navigator at the time. In a sense it had Netscape behind it, and then it had Microsoft behind it once they reverse-engineered an implementation for IE3.

I'm not very familiar with the history of Python, though it seems it was funded in its early years by various research institutes that employed Guido van Rossum, rather than a giant corporation.

> ...but no one would have adopted it if it weren't.

It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.

Go shot past similar languages because Google's backing got lots of instant attention from people who would never even hear of something like Nim or Clay.

Then why did D never take off?

For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.

I don't necessarily agree with the parent's point but D managed to fumble early on and never managed to catch up ever since. Around the time it got released (in the early 2000's) I was a C++ coder and I remember being very interested, only to immediately dismiss it as soon as I learned that it wasn't fully open source. I'm sure other devs didn't mind as much as I did but it definitely stunted growth early on. By the time they fixed this "issue" there was a lot of competition in that space and I never bothered looking back.

I don’t understand the comparison to Haskell or Ocaml; those languages are not C like and have a much different philosophy on the responsibilities of the language and type system.

Haskell is not C like? You can write Haskell with curly brackets and semicolons, just like Go! I rest my case.

No, but seriously, you didn't get what I was saying there. The whole reason Go might be of interest is that it is loosely C-like in a way that Haskell and Ocaml are not.

That true, and I still don’t get what you are saying here. In my mind, they are different languages which appeal to different developers and fit with different requirements. I don’t see it as an alternative to Haskell any more than any Turing-complete language is technically an alternative.

> In many ways it's Java done right

Not quite:

* no generics

* error prone error handling

* non tunable GC

* null pointers

* golang interfaces are messy and can't be used to tag structures

* golang time package is garbage

and lots more

Java today is superior to golang in almost every front.

Memory usage, compile time, simplicity, readability and deployment story are notable fronts in which go is several miles ahead.

Java will use however much memory is assigned to it, since it defaults to throughput performance (though now with G1 and Shenandoah that can also be tuned)[1].

Compilation times are not that different, especially when using incremental compilation. I worked on large projects in both languages, and for any non-trivial code base, the difference isn't that far off.

I'd argue that readability is better in Java due to things like non-clutter due to error handling, and the existence of generics.

Deployment has been solved for a while now with building shadow jars[1].

[1] Not to mention offerings like: https://quarkus.io/

You mention a lot of workarounds and knobs though. And the excessive use of layers of abstractions in the Java world is scary.

Large projects are complex. The JVM is designed to be a platform for developing general purpose software, which is why it provides options for tuning and whatnot. golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

> golang only comes with a low latency GC, which basically means you cannot use golang if you're looking for high throughput.

I you're looking for high throughput you just need to allocate less. Or use unsafe. And it's totally doable.

So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.

And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.

Object pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.

Managing allocations is way more than just object pooling. The following code in golang allocates "n" on the heap:

    func main() {
        n := 1
        fmt.Println(n)
    }

Object pooling won't help here.

The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.

You can pool n if it's on your hot path, can't you?

Escape analysis was just rewritten, and the objective is to handle this case more gracefully.

Reply on news.ycombinator.com