Hacker News new | past | comments | ask | show | jobs | submit login
The State of Go – Where we are in May 2017 (golang.org)
231 points by astdb on May 19, 2017 | hide | past | web | favorite | 154 comments

> vendor directories are ignored by the go tool #19090:


No more Makefile spaghetti like this (well a bit less anyway!)

    GO_FILES := $(shell go list ./... | grep -v /vendor/ )
    go test $(GO_FILES)
    go tool vet . 2>&1 | grep -E -v vendor/ ; test $$? -eq 1
    errcheck $(GO_FILES)
    find . -name \*.go | grep -v /vendor/ | xargs goimports -d | grep . ; test $$? -eq 1
    go list ./... | grep -v /vendor/ | xargs -i golint {} | grep . ; test $$? -eq 1
should become

    go test ./...
    go tool vet ./...
    errcheck ./...
    goimports -d .
    golint ./...
I assume the `./...` changes will just work in `errcheck` and `golint` but I suspect `goimports` might need a bit of work.

Only if `go test -cover ./...` would work. Currently in needs a lot of magic [1] (ignore sharness test coverage magic, it uses even more magic [2]).

[1]: https://github.com/ipfs/go-ipfs/blob/master/coverage/Rules.m...

[2]: same file as [1], we compile unit test using `go test -c -cover` that runs our main function and saves the return value to file ([3] and [4]), but it works. If someone considers doing that, run everything in ramfs (tmpfs).

[3]: https://github.com/ipfs/go-ipfs/blob/master/coverage/main/ma... [4]: https://github.com/ipfs/go-ipfs/blob/master/cmd/ipfs/runmain...

Video of the presentation on youtube https://www.youtube.com/watch?v=giUatBmmb_Y

The slides don't work very well on an iPad mini :( Going to the next slide skips 2 at a time

For me, on an iPad, dragging moves 1.5 slide, but clicking at the left or right edges moves one slide (correction: that's a bit state-dependent. I _can_ make it reliably work that way, but it may require some 'random' zooming to get there)

Same here on my iPhone.

Strange that Go and Dart are completely missing from I/O this year.

No. At Least Go is not there on Google I/O for last few years. To me it is encouraging that Go has its own conference Gophercon and not riding on Google I/O.

I believe Go at Google does not have same relationship as Java at Oracle or Swift at Apple.

> To me it is encouraging that Go has its own conference Gophercon and not riding on Google I/O

That's correct - GopherCon is a community effort. It originated when a community member expressed surprised that there wasn't already a Go conference, and then, upon encouragement from others, decided to organize one themselves. They remain the organizers of the event, and they do not work for Google.

Google has been a diamond-level sponsor for the last three "main" GopherCon conferences[0], but no different from any other sponsor of the conference in that regard. And that's by design - the Go project aims to be a community effort, not solely the work of Google employees, although Google does hire a small number of people who work on it full-time.

This isn't inherently better or worse than the model that (for example) Oracle uses with Java. It's just a different philosophy - and in the case of Go specifically, one that everyone involved seems to be happy with. The Go project contributors (including those employed by Google) want it to be a community-driven project, and the Go community members are by and large happy carrying the mantle themselves as well.

[0] GopherCon happens every year in Denver, but there are tons of other conferences around the world that carry the GopherCon name - for example, GopherCon Singapore is happening a week from today[1]

[1] And, similarly, traces its origins to a single tweet from a community member expressing interest in a conference.

Agree with everything you said. Go is very active community driven project without mile long community laws/bylaws like Apache/OpenJDK stuff.

Specially when we see which languages get the preview SDKs for all Google platforms and services.

>I believe Go at Google does not have same relationship as Java at Oracle or Swift at Apple.

Could you tell me more about it, please?

Simply it is not a part of corporate strategy. Larry/Sundar or any SVP do not introduce new version on stage or gush over its market reach or new Http2 API. See the website of Swift/OpenJDK/Go and you will notice there is no mention of corporate ownership for Go.

Swift: "Swift and the Swift logo are trademarks of Apple Inc."

OpenJDK: "© 2017 Oracle Corporation and/or its affiliates "

Go: "Except as noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code is licensed under a BSD license."

>Could you tell me more about it, please?

Google never cared for Go.

It wasn't created as a strategic project or investment. It's a language created by a small team on Google doing their thing.

It does keep paying them to work on Go though (and probably devoted some more people to it), so there's that, but Google neither hired them specifically for Go, nor requested that they work on such a project from the onset.

It was also never made THE official language for Google development by some decree, nor was getting it to Android any priority (they favored Kotlin for that in the end). Neither was it ever strongly marketed by Google to outside developers.

Dart/Angular got more of an official "sponsoring" from Google (including devoting a top notch compiler guy like Lars Bak to work for the former) than Golang. From what I've heard, it has seen adoption inside Google, but nothing game changing.

There's no single official language at Google; it's a multi-language place. Google's build system (bazel) is multi-language. Internally, Go is as official as it gets.

While Java is most common, there's no single language for Android, either. C++ was always used for games, Kotlin is now officially supported, and Dart is in alpha via Flutter: https://flutter.io/

(Not to mention all the different languages supported on Cloud.)

Anything you say about "Google" caring for a language is probably true of some teams and not true of others.

>There's no single official language at Google; it's a multi-language place. Google's build system (bazel) is multi-language. Internally, Go is as official as it gets.

Not a Googler (or even close), so can't verify, but from what I've heard it's like this:

Google backend is C++, Java and Python. To this, they also allow Go now (and for some years).

But Go was never meant as a "create us an new official Google language to rule them all" directive, or even "create a language that solves Google scale programming issues". (I mean, the Go team had the latter issues in mind -- but, Google itself didn't, and didn't ask for such thing officially (in the way they officially jumpstarted projects like V8, or Dart, or GWT etc). The Go team created Google on their own, not as some official "new Google language" decree from above).

>While Java is most common, there's no single language for Android, either. C++ was always used for games, Kotlin is now officially supported, and Dart is in alpha via Flutter: https://flutter.io/*

Well, it might sound like there are 3 languages now (and 4 soonish), but officially apps were meant to be coded in Java/Davlik, and high perf games in C++ for almost a decade. So, as far as Android official languages go, it has been Java all the way for app development for ages...

I thought Go was created to be the primary language for new Googlers. Did that never turn out to be the case? Are there many Google projects written in Go? Kubernetes is the only one that immediately springs to mind.

Downloads are powered by Go, which was a huge port from C++.


That's a single project, and one of the 2 adoption stories circulating in 2012/3, 4+ years ago (the other was a MySQL load balancer for YouTube or such).

I'm pretty sure there is quite more stuff now, but those known are not much to write home about. Even downloads is not some "huge port" -- the presentation mentions "14,032" lines.

> That's a single project, and one of the 2 adoption stories circulating in 2012/3, 4+ years ago (the other was a MySQL load balancer for YouTube or such).

The parent comment was asking about projects so I presented one that sprung to mind.

> Even downloads is not some "huge port" -- the presentation mentions "14,032" lines.

Yes, it mentions "39 files (14,032 lines) deleted" which is not small in my mind. Not to mention they heavily leveraged the standard library and some other projects like groupcache.

>the other was a MySQL load balancer for YouTube or such

It was Vitesse:



Go has always felt more like "a language created by Google engineers" rather than "Google's language" which Dart seems to be.

Compare golang.org with dartlang.org: the former does not mention Google in the front page at all, where the latter does.

Isn't kotlin the new dart now?

Genuine question as they have more in common than just curly braces it seems.

I know they are _different_ but the question is: is it possible (not completely stupid...) that the future of those languages is going to be a merge (kord, darlin? ;)

Kotlin is the new Groovy. Runs on the JVM, uses Java classes. Dart may replace the JVM.

Kotlin is the new Scala, in that it's competing for mindshare in the statically-typed JVM language space. Apache Groovy is a dynamic language, originally intended to complement Java. (Although there's been a static mode since Groovy 2.0, virtually noone uses it.)

I don't think Kotlin is quite a new Scala. It doesn't try to fit the same niche. Scala is the bleeding edge kitchen sink, that happens to also be on JVM because, hey, existing libraries! But it doesn't try to be a better Java as a language. Whereas for Kotlin, it's the whole deal.

I would say that Kotlin is filling the heretofore unfilled niche in the Java ecosystem, that was in the gap between Java and Scala.

They have kotlin-native so they can do something a'la... crystal? It's an early stage, yes, but kotlin goes beyond jvm.

Dart is available on Android and iOS via Flutter (in alpha):


Dart is losing with TypeScript. It seems that outside of Google almost nobody uses Dart.

It'll be interesting to see how Go will cope with Kotlin/Native (in technology preview stage right now)

Kotlin has no unsigned types (JVM language). In embedded / IoT applications that's a downside. It seems that unsigned types are the only major advantage Go has over Kotlin/Native.

> It'll be interesting to see how Go will cope with Kotlin/Native (in technology preview stage right now)

What is there to cope? Go is winning in market pretty aggressively. Kotlin native has nothing to offer over languages which were designed free of JVM / Java baggage like Go/Rust/Swift.

Also Java 9+ itself is going to offer AOT compilation for those who have to use Java and want native too.

Kotlin may be fine language and Google added a low effort support to Android. It may get more popular on Android but it is about as old as Go but here is trend for the two in general:


Kotlin also lacks value types necessary for efficient memory layout and high perf/low latency GC. Build system as gradle/maven might cut for Java but Go user are used to fast/inbuilt tools like go build/run/install etc.

>What is there to cope? Go is winning in market pretty aggressively.

On HN maybe, but in the wider world, and the enterprise, not so much (if at all).

>Kotlin native has nothing to offer over languages which were designed free of JVM / Java baggage like Go/Rust/Swift.

How about less complex than Rust, less associated with Apple than Swift, and better designed than Go? And with serious compatibility with Kotlin for the JVM -- which boosted by Android adoption will get quite big soon.

> and better designed than Go?

Not for my money. A few things Go does better than Kotlin:

1. No classes, inheritance, etc (let's dispense with the "you don't have to use it!" arguments; they don't prevent us from interacting with an ecosystem and std lib full of classes and inheritance) 2. Concurrency; Go has one model, goroutines. Goroutines != coroutines, and no worrying about whether some function blocks the thread with a sync call. 3. Real, first class value types. Easy reasoning about allocations and escape analysis, etc. 4. Tooling: most everything is simple and does the right thing by default. There is one build system to understand, and there are no build scripts to write or cargo cult. Oh, and it's fast.

Kotlin has generics which are nice, but in practice I spend zero time on runtime type errors; on the other hand, reasoning about performance and tooling consume quite a lot of my time. I'm happy that it's getting generics, but it has a long way to go before it's competitive with Go for my time.

Last sentence should read, "I'm happy that is getting native compilation". I missed the edit window.

Is Kotlin winning in enterprise? For e.g Scala enthusiast claiming it is taking over the world. But as I downloaded Apache Kafka last week only to notice they deprecated large amount of Scala API and replaced it with Java. Good for me though as Java developer.

> How about less complex than Rust, less associated with Apple than Swift, and better designed than Go? And with serious compatibility with Kotlin for the JVM -- which boosted by Android adoption will get quite big soon.

How about a language that has every feature I want and slowly every feature that everyone else wants. If it has been tried and done successfully before, I have not seen results in commercial software realm.

Going by the hype of Kotlin on Android I am wondering it may end up becoming part of Daydream but without any VR.

>How about a language that has every feature I want and slowly every feature that everyone else wants. If it has been tried and done successfully before, I have not seen results in commercial software realm.

Well, C++ and C# would be those kind of languages.

>Well, C++ and C# would be those kind of languages.

C++ does not even have a decent ADT and pattern matching support, you have to do some really kinky stuff to implement something that would at least resemble option type.

I always wanted C# to run on linux :-). It was not possible for long time when I cared.

Mono exists since 2004, you must have cared for a long time.

And there were never legal concerns with Mono?

There was always a lot of FUD about it, but I have never seen anyone qualified lay out a specific legal argument to that effect.

Not really.

> Is Kotlin winning in enterprise?

Ask this again in 8-10 years' time.

And I don't mean that as flippant, enterprise projects simply have insanely long lifecycles.

> Also Java 9+ itself is going to offer AOT compilation for those who have to use Java and want native too.

This form of AOT doesn't free you from the JVM though. It's cached machine code but it still needs the VM to run.

Java 8 got unsigned arithmetic via helper classes.


The reason why Java didn't got unsigned types was because Gosling went around Sun R&D offices asking about unsigned arithmetic and almost everyone got it wrong.

I miss them when in Java though.

> Gosling went around Sun R&D offices asking about unsigned arithmetic and almost everyone got it wrong.

Maybe R&D would be busy making cool demos of futuristic technology which could beat Microsoft's cool demos.

I know you are trolling, but although Sun was good at engineering in general, desktop programming and language design weren't certainly their stronger skills.

They killed the only innovative desktop they had, NeWS. And although Swing is quite powerful, the default configuration certainly isn't.

They also removed resources from JOGL, Java3D and JDI.

Also given the existance of so many Wirth influenced languages with AOT compilation to native code, at the time Java was released, I never understood why they were so religiously against AOT toolchains.

There is even a paper from Sun Research about writing Solaris drivers in Java, but instead of compiling AOT to native code, they ported the JVM into kernel space.

I wonder what would have they done if the partnership with NeXT regarding OpenSTEP had actually gone forward, instead of being the inspiration to Java.

Java was originally designed to run on set top boxes that had a wide variety of chips in them, and which loaded code on the fly from disks or over the air transmissions I think. Such boxes may not have even had much in the way of persistent storage, so I can see how they ended up with that design. Then they started down the speculative opts-with-deopt route and I guess the rest is history.

Java 9 does have an AOT compiler, at least for Linux (they're using the platform native DLL formats unfortunately so the AOT compiler tool has to be manually ported to each platform). Unfortunately it isn't just saving the compiled hotspots. They compile everything without speculative opts and then you can make it re-JIT on the fly from native->native.

Eiffel, Oberon and LISP are three examples of programming languages whose toolchains offered JIT and AOT compilation models depending on the use case being targeted, all of them before Java was even a thought.

I am fully aware of Java 9 AOT compiler, including the facts that not only it is just for x64 Linux, it just supports compiling the java.base module and the result isn't distributable.

However all commercial third party JDKs that didn't suffer from Sun's dogmatic war against AOT compilation, do support fully compiling Java into native code ahead of time.

Sure Java 10 is supposed to make everything better, including supporting value types, which the above mentioned languages also supported by the time Java was designed, yet that is something that is still like 5 years away or even more.

>There is even a paper from Sun Research about writing Solaris drivers in Java, but instead of compiling AOT to native code, they ported the JVM into kernel space.

Interesting. Intuitively, does not seem like such a good idea. On the other hand, there was (and I think still is) this company called Esmertec that was doing embedded Java stuff (from around 2001). And IIRC there was Jikes, which I think was a compiler for Java from IBM. Also saw your comment below about third-party JDKS with AOT compilation.

The most well known companies selling JDKs with support for AOT compilation, are PTC (former Aonix), Aicas, ExcelsiorJET, IBM.

There are probably others in the embedded space, as Java is actually gaining some traction to more classical approaches.

And of course, there is also Android with ART.

This was the paper I was referring to, http://dl.acm.org/citation.cfm?id=1698145

Cool, thanks.

> Dart is losing with TypeScript.

I switched my current project from Dart to TypeScript. I think Dart is the better language, with a decent standard library, but getting interop working for various JavaScript languages was just sucking up too much time.

I'd love to have used Scala.js, especially since the rest of the project is written in Scala, but again, interop issues.

I'd imagine Dart will make an appearance at the talk 'Single Codebase, Two Apps with Flutter and Firebase'.

Go has its own conference: https://www.gophercon.com/

There are two sessions indirectly about Dart (because they are about Flutter, which uses Dart).

"Prototyping to Production: Bridging the Gap with a Common Tool"

"Single Codebase, Two Apps with Flutter and Firebase"

There are also codelabs for Flutter.

Why was Kotlin mentioned at Google IO? But not Go nor Dart?

I mean Kotlin is the baby of JetBrains, the creator of the IDEA IDE that is used for Android Studio.

Even stranger is that it's a non Google language (Kotlin) that's receiving all the exposure at Google I/O.

A bit strange, completely understandable. I've seen people mention kotlin everytime I read something about Java and/or Android. It's also a good swift alter ego at least on surface level.

But they announced Android GO! /joke

A bit OT - does anyone know what tool was used to create those slides? They look very light and clean and something I might experiment with for technical presentations.

As mentioned it's the go present tool. It's ok, but kind of annoying. It runs it's own webserver (very easy in go), then does a decent job of slides. But it's kind of annoying to run, you can't run it as a user since it wants to bind to :80. You can't shared slides with people easily, nor host it statically by easily copying files.

Pandoc is pretty similar, just as powerful, and supports multiple output formats. That way you can statically host random files without depending on a go binary running 24/7.

Also be careful with present, it by default runs a sandbox to allow execution of code/examples that I wouldn't trust open to the internet... at least without good justification.

I use Go and love it. That's the only thing in my app achive sub ms latency.

That is being sad, Go is still not as mature as other language such as Ruby, Java, Python,...etc in term of eco system around web application.

Take database for example. Any web app needs to interact with MySQL, MongoDB etc. But the performance of those drivers are somehow lack behind when I compare them with other driver. MongoDB/MySQL drivers are both seems come from individual works of excellent/talented developer than official support from those database.

Go shines in system/devops stuff though.

That surprises me, go does use prepared statements by default. Could that be it?

wondering why you say that drivers don't work well, most of them are on top of "database/sql" pkg

sync.Map is kind of a big deal.

Also a shining example of their poor type system.

how so? how would a type system have helped here

Since everything in sync.Map appears to be laundered through interface{}, you lose compile-time type safety where you use it.

The type system issues can also be seen in:

* you get a note that a map must not be copied, but you won't actually be prevented from doing so?

* iteration can't use the native construct (no generic interface -> no generic iteration)

Another concern (big or little depending on your circumstances) many common things stored in maps, strings, primitives, incur an allocation on conversion to interface{}.

Coupled with a fairly inefficient GC it means I would need to think twice before using this.

What's inefficient about Go's GC ?

I think pcwalton expressed it clearly here


Thanks. I also found this other discussion useful: https://news.ycombinator.com/item?id=12042302

Use it, then profile later?

Well, you might not want to put it in a public API anyway since it shouldn't be copied.

Better if you wrap it somehow. Then it's similar to an unsafe section; you need to be careful but it's self-contained.

I"m not sure that it is, given that the empty interface is more annoying (IMO) than just wrapping a native map in a sync.RWMutex.

Especially considering that sync.Map just uses a mutex under the hood: https://github.com/golang/go/blob/master/src/sync/map.go#L19

edit: although reading the comments, apparently there are conditions where the mutex does not always need to be held. This would be an improvement over sync.RWMutex wrapping.

It doesn't seem to support composition in any way though, there's no "transactional" view of the map.

I don't think it's a general data structure so much as an alternative way to manage concurrency without a mess of channels. "Synchronized maps" and "communicating shared processes" being two important ways of structuring concurrent programs.

The bit about better "errors" for Allman style braces really drives home to me just how proudly opinionated Go is. "We know about this other indent style and acknowledge it, but it's WRONG."

I really gave Go a good shot, built a project of decent size with it and used it as my go-to first choice for a few others, but every time these little nitpicks come back and make it feel like Go is smacking my hands away from the keyboard. "Bad programmer! You didn't do it the way I wanted you to!"

I would love to use a hypothetical "Go++" that's built from the same roots of Go but forgoes its opinionated nature, even if it's at the cost of messier code. Someone somewhere has to be working on that... maybe I should give it a try.

> forgoes its opinionated nature, even if it's at the cost of messier code

Absolutely not. Have you never worked with anyone who just can't adhere to any standards? Go forces that guy at my office to at least get spacing and braces right, even if the rest of his code is lacking.

I was doing that with indent and CVS plugins back in 2000.

Yes, but it's pretty central to go. If code is posted somewhere for review/comment "Why doesn't this work?", often the first comments is run gofmt on it first.

It's generally expected that all commits to code are in the gofmt standard, and there's not even the option to change the format.

I suspect if you analyzed all the code on github that go would have much higher compliance with the gofmt standard that you'd find to any other single standard for java or c++.

Gofmt is pretty nice, I wouldn't make the same decisions myself, but it's pretty valuable to have all code I see with exactly the same formatting. Additional gofmt uses the same parse as the language and can even parse, modify, and invert to produce a new source file. Similarly it's much easier to write a golang aware editor than most other languages.

man for me that's such an advantage of Go. i dont think brace style & other style quirks matter that much, but having them be consistent really helps a lot. so just pick one style and be done with it.

also, having all code use the same style means you can safely search for semantics just using a syntactic pattern.

I completely agree. The dogmatic opinionated approach Go takes grated with me initially but with gofmt automatically "fixing faux pas" and the ease at which I've found reading back old code or other people projects, I've come to realise I've saved more time in the long run due to their opinionated approach.

And frankly, there are more important issues with writing code than which line an opening brace should land on.

I think consistency is very overrated by the go community. I read and work on a lot of C code, and styles vary considerably. It's just not hard to read code in different styles. And my main problem is not that `go fmt` enforces a specific style, but that it enforces a specific style that actively harms readability. Defaults are good as long as they are sane, but `go fmt` made some really stupid decisions.

The thing with readability is that consistency matters more than the specific style chosen as any serious time spent with a specific style will teach you to read the code regardless of the chosen style. This is why Perl developers often defend the readability complaints of the language and why C++ style syntax gained popularity despite Pascal's syntax being arguably more readable.

My point is everyone will have their own personal preferences about style guidelines and argue that theirs is the most readable but frankly the most readable is just whatever you spend the most time reading. So you quickly get good at reading other language style guides when you spend time coding in their respective languages

Go read OpenSSL's code before they decided to have a consistent style[^1] and come back here

[^1]: https://github.com/openssl/openssl/blob/7a71af86ce75751f3cb2...

The style in that file seems completely self consistent. I don't know what your point is.

Browse different files in the repository at that time, not just one file. Different files will have different styles, and awful ones at that.

switching between styles isn't the end of the world, but it's not zero cost either (at least for me). knowing i can confidently grep for something w/o having to try to include style variants is nice.

my personal style would be more condensed than gofmt, but it doesn't make any choices i think are really stupid.

what bugs you out of curiosity?

The requirement that braces be on the same line is a consequence of the semicolon insertion that the compiler performs. This is also why the error messages confusing when the brace is on the next line.

Because a semicolon is inserted whenever the parser encounters an identifer or a token that's not in a special restricted set that includes ( and {, you end up with a semicolon inserted between a control flow statement and the bracket.

I suppose the grammar could have been modified to require that control statements include parens, or that the bracket become part of the control statement, but that's also kind of ugly ...

If I remember correctly, it's actually a consequence of how the parser handles certain circumstances. It's not just arbitrary and enforced.

> http.DoGetPleaseAndThanks

I genuinely can't tell if they're joking or not.

I think it's just an example of a different name to explain a feature. Not something anyone would actually implement.

Yeah, that obviously looks like a bad practice.

It should be:

> http.Get

> http.Please

> http.Thanks

quaternions?! This is exactly something I need but never would have expected in the base language.

Look at the date the issue was opened and closed...

Ok, that makes more sense than a quaternion library :(

I'm actually surprised Go even has a complex type in it, honestly. The places where you'd use it and the types of programs you'd use Go for don't strike me as overlapping much.

There's been some interesting discussion about the possibility of removing them in go 2 https://github.com/golang/go/issues/19921

C supports complex arithmetic. That was a real surprise for me.

This was added in C99 as part of a set of features that were all motivated by trying to make C a more viable competitor to Fortran for scientific and numeric code.

Did it work, or did nobody migrate from Fortran to C?

My understanding is that 1) the implementations didn't really deliver in the optimization department, and 2) the most crucial features (like VLAs) remained poorly supported and or/buggy for a long time.

The code actually exists and you can patch it into your own Go-compiled-from-source version

Usually with languages that are feature rich they can be plain library types.

With Go, they will keep adding special case after special case.

> Usually with languages that are feature rich they can be plain library types.

Eh, in most languages you'd still need language support if you want quaternion literals.

Literals are usually not a big issue. You don't get that much in going from "1 + 2i" to "complex(1, 2)" or something like that. It's value type semantics, operator overloading, and implicit conversions that are usually challenging.

Go doesn't have any form of customized operator overloading. If something needs to look like a number, it has to be in the base language. Stuff that isn't, is second-class even if it's in the standard library.

Ironically, this is the case for big integer / floating-point numbers - you have to write things like x.Add(y, z): https://golang.org/pkg/math/big/

You may have point. Though in this case it was 1st april joke.

Ah I see.

Why can't these talks have scroll bars, or some other indicator of where you are in the document?

I agree, I want to know how far through I am, and how much further I have to go. I would be happy with a simple 'n of m' or 'n/m' indication.

According Stackoverflow Typescript is winning:


wow! that graph is not what I would have expected (not sure what I would have expected, but... typescript and scala are dwarfing other languages... wow)

But it's dwarfed by c, c++, and javascript. Graph when you add a bunch of other languages:


IMO the most interesting from all these popularity trends is the rise of Python:


the very first slides talk about the deprecation and removal of old APIs. if there are any HN readers who influence go, consider Rich Hickey's argument [1] regarding deprecation and code removal.

Bottom line: he proposes that one should never take away a function/API (particularly when you are a library or programming language).


edit: superficial word choice

Kotlin is becoming more and more popular. Are we better off learning Kotlin instead of Go?

Like someone mentioned, it's hard to answer this in the general case. Factors to consider would be: a) are you dependent on the JVM and Java ecosystem? b) Are you already familiar/comfortable with Java/Scala? "Yes" answers to both of these might lean you towards Kotlin.

c) is speed essential? d) are you doing systems programming as opposed to CRUD webapps?[1] These might lead you to Go.

[1] I know you can do the latter in Go, but it's unclear that it's as easy/productive as in other langs currently (nor have I directly compared, say, Revel to other frameworks, so someone else is probably better qualified to answer this question.)

If speed is essential you'd use C++. But you could use Java too. There are useful benchmarks of server frameworks here:


As you can see the top frameworks are all C++ or Java. A Java servlet based framework clocks in 3rd with 178k/sec. Go's first entry is at 10th place with 141k/sec.

The next time go appears it's the "kami" framework with just 58k/sec - slower than nodejs!

Go is being used quite a bit for crud. I've spent the last year at a big co where that's what it's used for. I think the old problem of the ambiguous word "systems" comes in here - op-systems vs ent-systems. Go is for ent-systems not op-systems. A lot of ent-systems are crud, including microservice hell where 95% of the program is boilerplate config, http, metrics, logging, crud, wrapping a couple of tiny functions that were mildly interesting to program.

You might want to uppercase your acronyms. "Crud" means "something dirty and disgusting" or "nonsense". CRUD has a very different meaning.

I've found low-level web servers (i.e. basic i/o) are really easy to implement in Go. CRUD webapps with an auth layer, database management layer, JSON serialization/deserialization layer etc. are certainly harder to write as you pointed out, but it's possible.

> JSON serialization/deserialization layer

Why do you need a whole "layer" for this? I recently wrote a microservice in Go with a JSON-emitting RESTy API, and my JSON serialization layer is two functions for a total of 20 limes: https://github.com/sapcc/limes/blob/0735bd6de4e49f900ab8d97a... (ignore the unrelated function inbetween; I cannot select non-contiguous areas in GitHub source code listings)

I think what OP means is a layer in a sense of mapping JSON to your own data types. You just invoke json.Marshal/Unmarshal here, which deserializes into maps and arrays of interface{} - i.e. effectively an untyped data structure.

No, it doesn't. json.Un/Marshal understand all data types; you just need to annotate fields in structs with their JSON field names.

If you want speed, use golang ?

Java (and kotlin) are faster than Go in almost all cases (except for startup time) (and even there difference is shrinking, plus you get a lot back for that startup time). C, if you must, is faster still, and C++ can be faster as well.

As a quick (and inaccurate) rule, any program that runs longer than 10-20 seconds will be faster in Java than in Go.

What about memory? I wouldn't run any kind of production Java web server with 256M RAM server. I've had impression that Golang is much less memory-dependant.

Not sure about the most recent versions, but Go can run on MIPS platforms with 32MB RAM.

Hmm, I guess I was going of benchmarks such as these, which suggest Go is, well, faster some of the time?


However, perhaps as you indicate these are including JVM startup time and thus tainting the results. For some reason I had gotten it into my head that Go was faster than Java, but it's been a couple of years since I've used either one, so I definitely may be off on that point.

Last time I checked, the maintainers of that game said the startup time is negligible.

But if you care more about latency and predictable performance, Go's very low-latency GC is attractive.

Not really. Golang provides "mostly" low latency, at the cost of everything else, most significantly throughput, and load.


TLDR: Go's GC will only be realtime as long as you use it only minimally. With tiny programs, that's fine of course. With larger programs, it will block for a looooong time. That's masked by the language making it very hard to write larger programs in the first place. For instance, by not having decent data structures (not even a tree, seriously ?)

I guarantee if you actually use the GC, there comes a point where java runs circles around Go. Hell, there comes a point where the lua GC runs circles around the Go one. That point is a lot closer than you might think, and as a bad rule of thumb you should probably think of it like this: if any of cpu, mem, i/o goes >80% of the machine's capacity, Go will disappoint very badly compared to Java (GC using more memory, using more cpu, longer pauses, ...). But if all those values are at 2% of capacity, Go's runtime will perform better.

Tradeoffs. Everything is tradeoffs. Go is not better than Java/JVM, it's worse. But a different set of tradeoffs means that there are circumstances where it'll beat the other set of tradeoffs. But "close to 0", Go will beat the JVM.

There's no reason you can't write a tree in Go. Take a look at go/ast.

Go is a language with at least two compilers. One of them is gcc (yes, gcc, since version 4.6). I doubt Go code compiled with gcc is much slower than C, and can't think of a reason why Java would be faster.

"faster than Go" could mean any compiler

Kotlin is not a replacement for Go - it's a fair bit higher on the "abstraction" scale, not the least of which is that it requires a VM.

That said, I'm not convinced that Go's place on that scale is useful in general. It feels like, if raw performance is desirable, then something like Rust - with stronger static typing (and so no overhead on boxing values as interfaces, for example) and no GC is going to be better. And if higher-level, more powerful abstractions are required, then something like Kotlin is going to be better. Go is in that awkward spot where it makes you give up enough of the latter to be painful, but doesn't really make up for it with more of the former.

Of course, this is a subjective opinion. YMMV.

Kotlin and vertx is a brilliant alternative to golang in general.

And if course, if you have even remote plans of doing anything on Android...It now makes much more sense than ever

That's an impossible to answer question because we don't know your situation or use-case.

I want to learn the most efficient language for creating high-performance APIs ( Micro-services).

> Kotlin is becoming more and more popular. Are we better off learning Kotlin instead of Go?

How does Kotlin handles concurrency? Now I've heard that Kotlin has a "Kotlin native" version. I didn't try it yet, but if that's the case and it has good concurrency support then Yes, in theory it could compete with Go, more than Scala native would, Scala is too complicated for the kind of audience attracted by Go.

On JVM and Native kotlin does support coroutines and supports all kinds of concurrency models (including go style goroutines). Check this more details - https://github.com/Kotlin/kotlinx.coroutines/blob/master/cor...

I don't think that has to routines. Goroutines are multiplexed across threads automatically by the scheduler, so all I have to care about is describing concurrent operations. Further, all I/o is async under the hood, so you never have to worry if a call will block the thread. Also, Go's concurrency is muuccchhh simpler.

of course it depends on your case , but my guess is that if you ask the question then you should probably invest time on kotlin ( because it aims for a larger scope of use cases)

People coding in go for real world projects usualy know that go fits the tradeoffs they're looking for.

either that or they started a company when the hypetrain was around

But where does one find the slides though?

quaternions? seems a little silly

It was an April Fools' joke.

Q: Where is Go in May 2017?

A: 1970


We detached this flagged subthread from https://news.ycombinator.com/item?id=14376729.

> Questions such as yours makes me realize that a lot of go developers don't even understand what is the purpose of generic programming.

While this sounds a bit condescending I know exactly what you mean.

There seems to be some sort of "language barrier" (where the language is programming language concepts) between developers from different backgrounds.

Go is currently used in a lot of successful projects, so it gets new developers from lots of places and they are failing to communicate adequately about the language itself. I see three main groups (there may be more!):

a) People who come from C and other lower-level languages: They are introduced to memory-safety, keep a type system that they already know and are comfortable with and in addition get a polished, well-integrated toolchain.

b) People who come from Python, Ruby and other "untyped" scripting languages. These are introduced to native code (wow! fast!), a type system that isn't expressive - but sufficient (and more than they had before), and the same toolchain experience.

c) People who come from higher-level, safer languages including (but not limited to) Java, Haskell, C# and so on. These developers for the most part already had well-functioning toolchains, but they are "stepping down" to a language that is less expressive (okay, for Java-people YMMV greatly) and often end up frustrated.

Now you get conflicts when the c-people have discussions like this with the a/b-people and nobody is happy.

There's an old joke about this in the Haskell community: http://www.lispcast.com/img/typing.png

I'm not really convinced that all (or even most) people from the b) category can be lumped together with a). I like both statically and dynamically typed languages, and it's precisely because I like the latter is why I demand the former to have sufficiently advanced type systems to let me avoid most of the verbosity normally associated with static typing.

When I'm writing in C#, for example, if I'm working with a collection type - and it doesn't matter if it's from the standard library or a third-party package - the only place where I need to mention the type of elements is when I instantiate it. Then I can add and elements to it, and access them later, and it's a lot like Python - I don't have to worry about the type, it's just magically there, thanks to generics (and "var"). But get rid of generics, and now suddenly explicit types are all over the place.

Hmm, still no generics...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact