I feel like this is a great practical example showcasing the value of static types and designing your data model up front. If you know the structure of the object, you can put in placeholders while the real thing loads in. Then you get to choose how it loads in. Ideally you can stream the patches via serialized actions.
This is basically Redux/Elm in a nutshell where the action objects can come from events sent via SSE/websockets/polling/etc.
Reducing a change log is about as stateless, functional, and elegant as it gets. I love these sorts of designs but reality seems to complicate them in unexpected ways unfortunately. Still worth striving for though!
I wrote an apple shortcut last year that notifies me with a random item from my todo list after five minutes of having an "addicting" app open. It sort of helps to jog me out of mindless scrolling, but I still ignore it a lot of the time. At the very least, it helps repeatedly remind me of things I aspire to do someday (I keep big picture ideas and projects in certain lists)
It kinda makes me sad. I hope we don't enter an era of stagnation because LLMs only understand our current tech. There are so many brilliant ideas that mainstream languages haven't adopted (and may never be able to adopt). There are language features outside of python and JavaScript that will change the way you think about systems and problem solving. Effects systems, structured concurrency, advanced type systems, distributed computing... There are brilliant people discovering safer and smarter ways to solve these problems but it seems nobody will care anymore.
Htmx + Kotlin with ktor and the html dsl was really fun to play with on a personal project. Static typing, autocomplete and a full-fledged programming language available to use in your html markup is a game changer. I was structuring my endpoints as pairs of "data" and "render", where the render endpoint just reused the function for the date endpoint.
To me the question "Why would I use X over Y?" in programming space is a bit redundant. Why would I use Kotlin over Closure? Why would I use Groovy over Scala?
Even only considering JVM languages you run in to way too many options for the question in itself to be worth your time as a serious discussion.
IMO - use whatever you and your team like best and that suits your needs. Java is great for hiring new devs and is arguably the most well established in an enterprise settings.
If you want an actual answer: Personal preference.
Android OS layer has zero Kotlin, and Google had to backtrack on their decision to let Java languish, as the Android ecosystem started to lose out on Java ecosystem, thus ART is now updatable via Play Store since Android 12, and Java 17 LTS is the latest supported version.
Kotlin is only used on Jetpack Compose and a couple of AndroidX libraries, that you have to ship alongside the application. And as alternative to Groovy on Gradle build scripts.
I expect this year's GDC to announce Java 21 LTS support.
Interesting, I don't develop for Android so I don't know the details in this space. Surprising to learn that the Android OS layer is 100% Java. In terms of a platform, I was more referring to the mass adoption of Kotlin for Android app development. 95% of the top 1,000 Android apps are written in Kotlin and adoption overall is > 50% according to their overview page https://kotlinlang.org/docs/android-overview.html
IMO those numbers create a lot of staying power for the language.
More like 70%, the remaining 30% are split between Linux kernel (C), Treble drivers written in C++ (Java is also supported), SQLlite (C), and naturally Skia, ART are written in C++. With a couple of newer drivers like the Bluetooth stack, adopting Rust.
However zero Kotlin.
Naturally Kotlin has such an adoption on userspace, Jetpack Compose the new UI framework is written in Kotlin, so already adopting that jumps up the adotption numbers.
It is like measuring Swift adoption by the use of SwiftUI, even if the business logic is still written in Objective-C.
I do agree that Google being Kotlin's godfather, pushing it for new projects, does create a lot of staying power.
However it is also the reason why on JVM, it is only yet another guest language, as there is no one telling Java developers they should not write Java to use framework XYZ.
All those that tried, Grails, Spark, Akka,... eventually lose adoption speed, and got replaced by Java alternatives.
Which Google had to accept, Kotlin's value without the breath of Java written libraries isn't that great any longer, and they aren't going to rewrite the whole Maven Central into Kotlin, as the Java community moves beyond Java 8.
The downvotes are unfortunate. To clarify I wasn't trying to start a flame war.
I was hoping someone would answer with concrete technical tradeoffs and comparisons e.g. compile times, null safety, common footguns, personal experiences, etc.
I was recently asked for a comparison between Kotlin and modern Java by a team that's considering a migration of their legacy Java service. I haven't kept up with Java's changes, so didn't have an offhand unbiased comparison to share.
I've worked on backend Kotlin and Java codebases for the last five years and have introduced Kotlin to dozens of teams across my company. Nobody I've introduced Kotlin to has ever ended up preferring Java or switching back to it. There's been initial skepticism at first (reasonable), but after working in Kotlin for a week or two, I've seen even the staunchest Java devs proclaim they're never going back.
To the point on personal preference, I think it's a factor but I don't think it's _the answer_. It's a blanket statement that ignores important details. Languages have different affordances, features, paradigms, and patterns that lead you to develop and think in different ways. Some differences like null safe types are obvious improvements for a large codebase with many contributors. The feature catches real bugs and makes the system easier to build and maintain.
I think there's a lot of warranted skepticism of JVM languages that aren't Java, but something about Kotlin feels very different. For comparison, I've worked with Scala (Spark) and played around with Clojure in my free time.
I'm not sure what feels so much better compared to other JVM languages, but if I had to guess I'd say it's an emergent quality from a few things JetBrains has done really well. In particular:
- The 100% Java interop claim is real. I've only had minor hiccups with Lombok
- The ability to incrementally adopt Kotlin in an existing Java codebase
- The IDE support in IntelliJ IDEA is unbelievable. The suggested refactorings subtly teach you the language
- Null safety lets you focus on domain modeling and business logic instead of error handling and validation
- Kotlin's backwards compatibility. New versions never seem to break anything. And they even provide refactoring actions in IntelliJ to automatically update deprecated usages
- Very few significant paradigm shifts. Kotlin doesn't force you to totally change your Java code to fit a functional style or anything like that. It just tries to make safer code easier to write
- The political stability and longevity gained from Android's blessing as a first-class language makes Kotlin feel like more than just another JVM language. There's Kotlin running on billions of devices. That's a pretty big ship to turn around, sink, or replace
To summarize, Kotlin just feels like the elephant in the room. Aside from low-level changes like new FFI possibilities and GC improvements, it's not clear to me what value Java upgrades add in comparison to Kotlin—especially in regards to new language features and syntax.
Anyways, hopefully this followup post starts a more fruitful discussion. I asked this question in earnest based on my personal experiences and observations. If you haven't tried Kotlin yet, I'd suggest cracking open an IntelliJ scratch file and test driving it yourself.
I spent a night going down a rabbit hole with observable framework and it was terrific! It more or less just got out of the way and I was able to visualize and explore my google maps history in detail. Some of the data loader environment stuff wasn't especially clear but running in a poetry env did the trick for python.
I love kotlin and tried creating a data loader for a kotlin script but that had some rough edges. Kotlin expects script files to be named foo.main.kts but observable expects executable shebang loaders to have a foo.exe extension. So I created a proxy exe script to call the kotlin script, but it then doesn't trigger auto reloads of the data.
A bit of friction compared to marimo or jupyter is using variables between data loaders and the notebook. For example, I want to use the date picker view component to change the range of data fetched by my loader. It's not clear how to do that, so exploratory analysis is slowed down a little. I'm aware this goes against the paradigm but just wanted to point it out. It ends up with you potentially moving a lot of the data munging to the notebook as you explore, which isn't ideal from a performance perspective.
One last thing is I wish you could define dataloaders inline. I'm a big fan of single files, so being able to just add a python code block and let Framework extract that as a file would be a nice little QoL improvement.
Still the early days, but Framework seems promising! I'd love to have my all my markdown notes running through it to get a sort of org-mode type situation without going full emacs.
Thanks for the feedback. We have a PR open to make it easier to register new interpreters (without needing to fallback to .sh or .exe); it’ll let you specify the interpreter associated with a given file extension (e.g., .kts for Kotlin). https://github.com/observablehq/framework/pull/935
As for inputs-driving-data-loaders, that does go against the grain a bit since Framework favors static data snapshots so that the built site is self-contained and performant. But a technique that works well is to generate Parquet files in data loaders representing the superset of data that you want to interact with, and then using DuckDB/SQL in the client to extract the subset you want to visualize. This tends to perform well, though obviously it’s dependent on the size of the superset you want to interact with.
It all seems too good to be true but your comment helped me develop a mental model for how this could work.
The most inspiring aspect to me here is just realizing how much potential low-hanging fruit there is in this space! What other seemingly naïve optimizations are there to try out?
I work on matching at Indeed. Not sure when the last time you used Indeed was, but over the past year or so we've made huge strides in our match quality. And we've recently began experimenting with alternative revenue models in order to better align with candidate and employer interests. We honestly do want to provide high quality matches and help people get jobs. Spamming employers with irrelevant candidates is not a very sustainable business model and helps nobody.
That's great to hear, especially around the pricing model. If Indeed only benefits when employers do, everything else automatically falls into place. I've been away from the platform for about 2 years, but administered it for about 8 prior to that.
I think this technique would be revolutionary for CAD or 3D modeling software. It always feels clunky trying to click, drag, orbit, fly, etc your way around a viewport, when all you really want to do is quickly peek around a corner to get some perspective
I was recently playing around with a similar approach using Alpine.js and it was really fun just hacking on an html file. Didn't know about importmap, but I'm excited to try it out. There's a time and a place for bundlers. But if you're just spending a lazy weekend on a toy project for fun, this is a really satisfying environment for prototyping
Reducing a change log is about as stateless, functional, and elegant as it gets. I love these sorts of designs but reality seems to complicate them in unexpected ways unfortunately. Still worth striving for though!