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.
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.
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.
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.
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
I had a very similar experience except it was a 1st gen MS surface book packaged in a 2nd box. They look nearly identical.
Spent months getting gaslighted by Amazon support.
My coworker who'd previously worked at Amazon Fulfillment suggested I email [email protected] directly. The case was picked up by a higher-level CS rep and they reversed the charges. No apology or concessions for the horrible experience otherwise. I truly hate this company.
These suggestions hit the nail on the head. Additionally, the reviewer also becomes a better dev because they’re forced to really think about and articulate why they think the code smells.
Even if my coworker’s code doesn’t feel right to me, I’ll sometimes forgo commenting if I can’t articulate why. My goal is to avoid bugs and deliver features, not to force my code style and opinions on others.
Is it just me or do the top comments seem super suspicious? They aren’t nearly as critical and level-headed as I’ve come to expect from hn. Skeptical of their authenticity.
I just assume at this point that a new python script from a coworker won’t run without an hour of tinkering and yelling obscenities at my screen. Or resorting to running in docker, which seems asinine. Python’s everywhere and does everything though, so I don’t have a good alternative. Shell scripts definitely aren’t it, but they generally hold up better when sharing in my experience.
I just gave this workflow a shot and it was great. Thanks for the tip! Do you use anything for committing more granular chunks of code? I'm just committing groups of files but after reading about magit on other hn threads, I feel like I could do better.
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!