Perhaps if you're driving, the things around you need to give you time to react to other things around you. Fewer things are more frustrating than getting honked at because you pressed a button, then got distracted by a car pulling up which you needed to look at to be aware of, then missed the printer asking if you want a receipt, and then having to press another button to talk to someone to ask for a reprint which, of course, holds up the line of cars growing behind you while someone gets paged to come to the kiosk.
So you wrote this new scenario where the parking ticket machine does NOT print a ticket unless you confirm it (after you already pressed the button)? And you get... mildly inconvenienced by some honking. Yeah you shouldn't drive.
Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).
Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.
Kotlin’s syntax is also weird/quirky in some ways.
Doing charity work does not mean you don't expect to be paid for your regular work. Also, a lot of companies do pay devs to work on open source projects.
Open source isn't charity - just like playing non-professional sports isn't charity: the vast majority of participants see it as a hobby or social activity. A minority get paid, and a minority of the minority "break even", but vast majority are playing in self-organized leagues and pick up games, which are in no shape or form charities (even if the public can watch for free as a side-effect).
I think the next release is gonna give you a lot of flexibility to write your own helpers that can generate the raw fragments you need. Not as good as having the features built in of course, but it'll do in a pinch.
jOOQ and jOOQ-like API's in other languages are the Right Thing in most cases, IMO. I've worked with very abstract ORM's, I've worked with raw SQL, and I've worked with a lot of things somewhere in between and that's my conclusion.
