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.
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."
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."
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.
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.
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.
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...
> 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.
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 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.
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.
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 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.
> 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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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)
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.
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.
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.
[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).
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.
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.)
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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
> 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.
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.
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 ...
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.
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:
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).
reply