Strange that Go and Dart are completely missing from I/O this year.
I believe Go at Google does not have same relationship as Java at Oracle or Swift at Apple.
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.
Could you tell me more about it, please?
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."
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.
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.
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'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.
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.
It was Vitesse:
Compare golang.org with dartlang.org: the former does not mention Google in the front page at all, where the latter does.
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? ;)
I would say that Kotlin is filling the heretofore unfilled niche in the Java ecosystem, that was in the gap between Java and Scala.
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.
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:
https://trends.google.com/trends/explore?q=%2Fm%2F09gbxjr,Ko...
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.
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.
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.
> 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.
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.
Ask this again in 8-10 years' time.
And I don't mean that as flippant, enterprise projects simply have insanely long lifecycles.
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.
https://blogs.oracle.com/darcy/unsigned-integer-arithmetic-a...
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.
Maybe R&D would be busy making cool demos of futuristic technology which could beat Microsoft's cool demos.
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 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.
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.
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.
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
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.
"Prototyping to Production: Bridging the Gap with a Common Tool"
"Single Codebase, Two Apps with Flutter and Firebase"
There are also codelabs for Flutter.
I mean Kotlin is the baby of JetBrains, the creator of the IDEA IDE that is used for Android Studio.