In case you don't know what this does, it's an abstraction layer for working with databases like MySQL, PostgresQL, etc.
Everyone warns against using them, but in the very early days of my learning Go, there was a tutorial that included this, so I just went with it.
ORMs give you some advantages: Switching database drivers (aka, switching databases) is pretty easy. If it's supported by your ORM, you can then just switch to a different DB entirely. For the simplest of operations, like just writing stuff to your DB and then retrieving it again, they work a charm. Especially in Go, the ability to automatically marshal things into structs is a blessing.
BUT, then you try to start doing things with many2many relationships, or retrieving sorted data in a very specific, nested query and things go sideways quickly.
I ended up finding it much harder to try to figure out how to do some pretty obvious things. Endless hours on Stackoverflow fighting the ORM and its shockingly bad documentation...
Eventually I just bit the bullet and learned how to write Postgres queries, along with a small Go library called sqlx (https://jmoiron.github.io/sqlx/) which massively outperformed GORM (https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq...) and it's much more straight forward to reason about the relationship between my application layer and the DB.
I had foolishly assumed that the tools had gotten better in the past 20 years. The last major programming I did was in Delphi under Windows XP, etc.
I was dead wrong. I burned through two different GUI Builders each ending up with 20minute to 1 hour cycle times every time I changed a major GUI element. The base problem is that these tools don't allow two-way changes, they only create a python file to then use. I ended up creating a set of files that allowed me to decouple the generated python from my code, and it mostly worked.
It was when I needed to change the type of control from a list to a combobox that everything broke. I had taken far too much of my free time learning and getting this to work. I tried out Lazarus (because Delphi is out of my price range), and it was good enough.
I wasted the code. (In the same sense you waste a via of medicine once you've drawn the dose for the patient)
In less than a week, I was back up and running, and changes were quick and easy to make. Python is good for some things, but a GUI isn't one of them. Charts that took 5 minutes in Excel now take a few seconds in Lazarus.
On the "higher" code stuff, Android is chock full of anti-patterns. Adopting the full repository flow of Android, from web to local database cache will lock you in a lot of patterns. You have to design your data into a way that's easily stored in SQLite, i.e. be pretty damn clear whether your data is an int, string, or pointer, which is hard to tell with new features. And then there's the mess of testing this. Some of these features are still in alpha, e.g. an official library might support pages in the form of integers, but not Strings. So for the most part, you rarely ever want to code Android in the manner that Google teaches you to, unless you're in a company with 10 devs on a team or something.
But I was lucky enough to work in a different project which had React, and it somehow felt more natural to my brain (more JavaScripty I suppose). I have played around even with Svelte and other frameworks as well, but to me personally Angular always stood out as the worst. By no means my personal view on the framework dimnishes its usefulness and I know a lot of people who prefer Angular. But for me personally it wasn't the best choice.
* Silverlight (!)
* Adobe Air (about 2 weeks before it was end dated)
* Rhomobile (native multi-platform mobile build, seemed like a good idea at the time...)
* Microsoft Service Fabric
Imperative-dominant programming language. I think I'd be solving different problems if I had learned to think in functional mode.