ECS is a pretty old idea, built on concepts that are even older. I was playing around with an ECS-like engine of my own in C over 10 years ago, based on blog posts and talks that are now 20-25 years old. Even the Wikipedia article for ECS can trace the origins back to the 1960s. (Though obviously it hasn't been applied to video games for quite that long.)

Nowadays I'd probably reach for Godot and Kotlin if I just wanted to build a game in an ergonomic language on a solid foundation. You could still apply ECS concepts there, as well.

> Note that while the data insight provides some commentary on what factors drive these price drops, we did not explicitly model these factors. Reduced profit margins may explain some of the drops in price, but we didn’t find clear evidence for this.

EDIT: Looks like my comment was detached from its thread (https://news.ycombinator.com/item?id=46857847) without a comment explaining why. It's not breaking any of the stated rules at the top, and it seems like it would be common sense to let someone know they should expect a message (especially considering how temperamental email filtering can be these days). If this _is_ against the rules, I'd appreciate it if future hiring threads stated as such so that people like myself that have been trying to find a job for 7+ months can stop wasting our time here. I understand how it can be challenging to moderate a forum like HN, but the moderation priorities seem pretty disappointing, unfortunately.

This is the case for the vast majority of companies posting jobs here and elsewhere (e.g., LinkedIn) right now. I've been looking for the past 7 months after a lay-off and that exact reply is the most common response I've seen (because it's an automated response). Well, most common after not hearing back at all, of course.

This probably isn't a line of argument you want to go down. I've been unemployed for 7 months, in part due to how difficult it is to get so much as an intro call because so many people have totally automated the process of spamming every open job posting with as many resumes (many of which were likely LLM-generated as well) as possible.

(Suffice to say I passed on Claude/Claude Code for the time being.)

JetBrains also keeps a list of other data analysis libraries for Kotlin (and Java) as well: https://kotlinlang.org/docs/data-analysis-libraries.html

Why? If the only requirements you specified are that you're looking for something that is compatible with Git but with better ergonomics, wouldn't something that wraps Git (whether that's via aliases or something more comprehensive) fit the bill?

Since it's Kotlin, it has backends for the JVM, LLVM, and JS/Wasm, though curiously Jake recently removed the JS target because it wasn't seeing much usage.

By opting for Kotlin and Compose UI, in addition to being a first-class citizen on Android, I gain the ability to share code with many other platforms to any degree I need. That is, just the app logic can be done in Kotlin while keeping the actual UI in whatever each platform prefers (UIKit on Apple platforms, Swing on JVM, etc.), or it can be entirely done with Compose UI (which usually means being rendered via something like Skia). And even if you adopt Compose UI, there are different degrees to which that can be applied; Compose UI can output either DOM elements or render to a canvas for the Web target, for example. (It's actually curious you mentioned Qt. As a day-to-day KDE user, I'm interested in playing around with the possibility of wrapping Qt components with Kotlin/Compose as well.)

No matter what degree of that I choose, it's still going to be more "native" than something like RN. Depending on the target platform, Kotlin will compile down to JVM/Dalvik bytecode, LLVM bitcode/machine code, JavaScript, WASM, etc. RN (last I checked, at least) still relies on running in a JavaScript engine at the end of the day. Flutter will get you closer than RN, but it's still not quite native to any one platform in particular and you're still introducing Dart as another language you need to know. A .NET-based solution suffers a similar problem, and IMO it feels even more out of place on Linux than the rest.

(To be clear, Compose UI has been able to learn a lot from Flutter, as they both originated at Google and both take a declarative UI approach; I largely consider Compose UI to be Flutter's successor.)

Ultimately, it can boil down to this: if you want to support multiple platforms, you need expertise in each. Adding most traditional cross-platform frameworks such as Flutter or RN also means you need expertise in that framework as well. In the worst case, my expertise with Compose UI will remain good for the work I need to do on Android. The worst case for most of these other frameworks is that it becomes irrelevant and you need to learn something else anyway.