To quickly recap, in case you missed the news, Google officially declared Kotlin the go-to language for Android development last week at its Google I/O developer conference, and the company is backing that up with a couple of initiatives around making it easier (and free) to learn the language now used by a majority of Android developers. To that end, Google teamed up with Udacity to offer Developing Android Apps with Kotlin, a free, self-paced online course on how to build Android apps with Jetpack and Kotlin, meant for people who have programming experience and are comfortable with Kotlin basics. Google also announced “Kotlin/Everywhere, a series of community-driven events focussing on the potential of Kotlin on all platforms,” which it is putting on in conjunction with JetBrains.
Of course, this leaves the question that has been asked many times before — why Kotlin? — and IT consultant Kristen Carter offers a take on how Android app development became Kotlin-first.
Carter offers some business angles, such as the 2010 lawsuit against Google by Oracle, which predates Kotlin by just a year, and she speculates may have been the impetus behind the language’s development as “Google has always wanted to get away from the [Java] ecosystem.” At the same time, Carter offers some language-specific reasoning too, such as the comparably succinct nature of Kotlin, the absence of Java’s NullPointerExceptions, and the ease with which Java developers could transition to Kotlin. Carter ends her piece by posing the possibility that Oracle “knows the significance of Java in android app development” and could “ship Java with a few upgrades in its next version to take on Kotlin.”
Meanwhile, Android developer Lemuel Ogbunude writes about “the funny Java vs. Kotlin debate,” commenting that “there is this constant battle of Java and Kotlin which, in my opinion, is very unnecessary.”
— Rory Preddy (@rorypreddy) May 16, 2019
Keeping Carter’s final musing in mind, Ogbunude offers that many Java and Kotlin comparisons are examining the wrong Java versions and that “It is possible to see Java 12 code and mistakenly think it is Kotlin, that’s how much Java has improved.”
While we’re all busy jumping aboard that Kotlin train, we can also be reminded that a critic is never far off and take a gander at this article on why Kotlin sucks, which is apparently based on a wiki of why all of your preferred languages suck. And to that end, Ogbunude’s lasting line that should be the mantra of many a developer: “being a fan of one language shouldn’t make you an enemy of another.”
So jump on, jump off, maybe take along some Java bagged on your Kotlin ride — do whatever works to get you there; that’s what really matters, right? And in the meantime, if you’re confused about any of this new-ish fangled Kubernetes stuff, let Kelsey Hightower break it down for you.
This Week in Programming
- GitLab’s Pithy Retort to GitHub’s Package Registry: It’s funny, because you can often talk about GitLab’s pithy retort to GitHub following many of the company’s recent announcements. GitLab, it seems, is often saying “Oh yeah, well, we’ve done that for years… what about this?” And that’s pretty much what the company said to GitHub’s announcement last week of the GitHub Package Registry, “a package management service that makes it easy to publish public or private packages next to your source code.” GitHub’s Package Registry, in case you haven’t heard, works with npm, Maven, RubyGems, NuGet and Docker images, with more pairings to come, and is currently available in beta. “GitLab has been building a single application for the entire DevOps lifecycle since combining CI with SCM in 2012,” wrote GitLab in a blog post, “and released integrated packaging back in 2016 — starting with a Docker registry — and adding Maven and NPM in 2018.” Not to be outdone, the company also noted that it was “also embarking on making package management more secure and auditable for the users of packages with a Dependency Proxy.” Beyond the back and forth between the two companies, one developer-blogger offered their take on the move, writing that they think that the development is about more than ease-of-use or “buy-in.” “As we’ve seen with NPM, trusting a package (and who actually published it) has bitten users of NPM as of late,” they write. “By tying the source code to the exposing of the package, this might help us (as a community) be able to find bad package owners more easily (since we can see the ownership in the code diffs). I could be wrong though.”
- GitLab, GitHub, BitBucket Team Up Against Ransomware: Surely you’ve heard by now, but earlier this month, news came of hackers wiping out Git repositories and holding them for ransom. Well, GitHub, GitLab and BitBucket have issued a joint blog post on the entire ordeal in an attempt to “help educate and inform users of the three platforms on secure best practices,” noting that “there is no evidence Atlassian Bitbucket, GitHub, or GitLab products were compromised in any way.” In the end, it seems, it all came down to insecure practices on the user end of things, which allowed their login credentials to be compromised, so all three companies are suggesting a simple fix — use two-factor authentication for things that really matter… such as all of your code in your Git repository. Read on if you want the full details for how this all went down.
The name of the language is Go, not Golang.
— Eno Compton (@enocom_) May 11, 2019
- Rust Turns 4! The Rust programming language is celebrating four years of Rust this week and five years “of open development (and a couple of years of sketching before that),” having first been released on May 15, 2015. While the team credits its commitment to backward compatibility for the language now not looking very different from the past, it also says it’s moving and growing faster than ever, pointing out that it has been StackOverflow’s “Most loved programming language” four consecutive years in a row, with “a whole new area of development for stable Rust: embedded development,” not to mention the recent release of Rust 2018. For you Rust users, also be aware that releases 1.34.0 and 1.34.1 affected from a vulnerability that can cause memory unsafety, which is solved by the latest release, Rust 1.34.2, so go get it now!
Dear junior engineers,
Please do not always defer to senior engineers.
You are in a good position to see that something doesn't make common sense.
In fact you may be the keepers of the common sense, having not yet forgotten it.
— Eric (@fournachotruths) May 11, 2019
- Google Intros Speech-To-Speech “Translatotron”: The Google AI Blog has an interesting post up this week, introducing Translatotron: an end-to-end speech-to-speech translation model and while it doesn’t appear to be available yet for public use, it looks exciting for future implementation. “Dubbed Translatotron, this system avoids dividing the task into separate stages, providing a few advantages over cascaded systems, including faster inference speed, naturally avoiding compounding errors between recognition and translation, making it straightforward to retain the voice of the original speaker after translation, and better handling of words that do not need to be translated (e.g., names and proper nouns),” they write, noting that it is “the first end-to-end model that can directly translate speech from one language into speech in another language.” Make sure to click through to the blog post to hear the different style of translations.
Welcome to Kubernetes where everything runs as root and the security doesn't matter!
— CZnative @ home (@pczarkowski) May 8, 2019
Feature image meme via Abby Fuller.