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.
If it hadn't being ruinously expensive, what were your reasons for preferring a gas cooker over induction?
I have a gas cooker, but have used a induction stove a few times and liked it. The induction model I used was not as controllable as a gas flame, but I understand this can vary by brand or model.
I see induction gaining popularity - it is supposedly more energy-efficient than gas, can cook some dishes more quickly (boiling water is fast), and is much easier to clean than a gas stovetop.
We were ignorant of the post-build costs. If we had known the 10x exposure in costs to re-wire, we'd have paid up front for induction.
We wanted Gas because of belief it was "better" for our style of cooking but gas cooking albiet responsive, is highly dependent on the heat energy the stovetop puts out, and the heat energy in the gas supply (pressure) And we kind of missed out on both: a brand name stovetop is disappointingly "slow" even on the wok burner, and our supply pressure is on the low side of normal.
If you have Aluminium or mixed origin cookware Induction usually demands new pans because they must be responsive to induction current. We didn't want to replace a bunch of (to us expensive) cookware. We're now much more aware and buy induction capable replacements, although quite why I don't know: we're not moving, and as this thread says, the retrofit cost for induction is not good.
Induction comes with it's own problems: It's surprisingly noisy, you need to cool those magnetic coils, its bulky under the workbench, and you don't want to put people with pacemakers on your cooktop, no matter now much you might want to experiment.
The cleaning is a huge thing. I do the stovetop, I've used more barkeepers friend in the last year than the proceeding 20 from fat spatter baking on. You can wipe down an induction very quickly after cooking ends.
Ideally? I'd have argued for two gas rings, and a square of induction. Wok gotta wok.
I am in love. So easy to clean, safer, faster than gas. It's annoying having to buy stainless steel pans vs aluminum, but just bring a magnet when you go shopping for them.
YMMV. Every home has a different cost and risk burden for this kind of work. Mine just didn't work out for Induction. I was really disappointed.
If we afford a major re-fitout eg to get a walk-in pantry I'll reconsider.
Really? Induction suitable circuit to kitchen should be pre-fitted in the apt design. Same as car-parking charging points: they're becoming mandatory, and I think so should the rollover in cooking power. Building has a 50+ year life, Gas is being deprecated for home use rapidly, its an AGW nightmare even being responsive for cooking and "analogue" right temp when you can get it to work.