970 karma · joined November 12, 2016
I can't imagine a quicker "kthxbye".
It's a fully featured ORM... Including migrations, query API (which is HIGHLY opinionated, it looks nothing like SQL), supports async (via asgiref!), custom model definition... It's almost the definition of opinionated. Not that you can build a fully featured ORM without being opinionated. That's not a dig at Django btw.
> Also, worrying about being "locked into" something that you depend on is madness. Where does it end? Do you worry about being "locked into" Python? Of course not.
Ermm, my premise is that you DON'T have to depend on it. It's not that crazy to not want lock in when it comes to the software that handles my database. Other programming language communities seem to handle that just fine.
The rest is a bit too ad hominem for my liking, so I'll pass.
Fair. But you then proceed to detail a personal experience on the other side of the spectrum: Badly written code, without an ORM, and how it was fixed by introducing an ORM.
I think we can all agree that you can write bad code, with or without an ORM :). Not that this is entirely relevant to my post, I am simply advocating for writing more SQL, not how to write a good object mapper. That's a different beast, and I purposely kept that simple just to illustrate that it is possible to get started without too much pain.
With that out of the way, despite ORMs doing much more than "just writing SQL", it is exactly on that point that I flinch: Most devs should be exposed to SQL. And if your project allows you to build around simple enough abstractions so that you aren't reinventing the wheel, you should definitely be writing SQL. Especially if you don't know SQL yet - which is the growing case of new devs coming into the job market.
You can achieve a lot with SQlAlchemy Core, a tool that I absolutely recommend, but my post is just a simple alternative to get developers to think about their approach. If that results in some devs reconsidering using "full fat" SQLAlchemy and to try SQLAlchemy Core, that's a win for me!
Your gist tries to highlight the difficulty of doing certain things without an ORM. Migrations (as just 1 example) doesn't need to be hard, simple tools like flyway, or migrate (https://github.com/golang-migrate/migrate) achieve a similar result (while also keeping you on the path of writing SQL!). Deep and complex relationships between objects also don't need to be hard - typically people approach this subject with a requirement to be very flexible in the way they want to build queries and objects, but that to me in a sign that maybe they should reconsider their business logic AND reconsider that, just maybe, their project doesn't require all that flexibility, it is fairly straightforward to extend objects and introduce some more complex representations as and when it is needed - will all of this make me write code faster? Absolutely not. That is why you have spent so much time perfecting SQLAlchemy, but then again, I am not advocating for devs to go and replace their usage of ORMs, just presenting an alternative that may or may not fit their needs for a new project + give devs the chance to learn something that the ORM might have taken away.
I guess this is a good thing, as "reimplementing" Django's ORM is the opposite of what I wanted to do here :)
> ORM queries compose. That's why [Python] programmers prefers them. You can create a QuerySet in Django, and then later add a filter, and then later another filter, and then later take a slice (pagination). This is hugely important for maintainable and composable code.
I don't really disagree, but there are many ways to skin a cat. You can absolutely write maintainable code taking this approach. In fact, I can build highly testable, unit, functional, code following a abstraction very similar to this. The idea that "maintainable and composable code" can only be achieved by having a very opinionated approach to interacting with a database, is flimsy. I offer a contrary point of view: With the Django ORM, you are completely locked in to Django. You build around the framework, the framework never bends to your will. My approach is flexible enough to be used in a Django project, a flask project, a non web dev project, any scenario really. I want complete isolation in my business logic, which is what I try to convey just before my conclusion.
There are a multitude of extra things to consider, but none of those things are, in my opinion, imperative to having success with SQL in Python. Will it be hard to achieve the same level of convenience that modern ORMs provide? Absolutely. But there is always a cost.
I firmly believe that for most projects (especially in the age of "services"), an approach like this is very much good enough. Also, a great way to onboard new developers and present both SQL and simple abstractions that can be applied to many other areas of building software.
I don't know the specifics of your parents. A "wooden house" with a heat pump acting as the primary heating system in a country like Norway sounds fairly bad on the surface. But I don't know the insulation specifics, nor do I know what other heating element might come at play when the heating pump fails to keep up with the heat loss. Also, what heating pump are we talking about?
Of course, you could throw more money at it. But it won't be cheap, and you won't see a return on your investment any time soon.
You could spend 10s of thousands of pounds in a "properly sized" heat pump system. Or you could spend 10s of thousands of pounds in insulating your home + a more moderate heat pump.
No kidding. The site is all about switching from carbon, which I am all for, as would anyone that cares even slightly about the planet.
BUT. If you do live in a 1850s house with no insulation, getting a heat pump is a colossal waste of money that will not do the job. No matter how many fancy biased graphs and numbers someone comes up with.
Any responsible heat pump installer will firstly look at your home to determine if a heat pump is remotely feasible. Unfortunately, in the UK, only very recent new builds can comfortably accommodate a heat pump. That or older properties that have had CONSIDERABLE insulation work done to them (and I am talking the expensive kind like internal/external wall work, not just the easy jobs like loft insulation).
Be very careful with heat pump cowboys, if you are getting quotes that don't include a site inspection, run.
Years ago I visited my home country with my partner. She used to prefer going to dentist there, old habits I guess. On this particular trip I agreed to a check up as well - It had been a while since I had my teeth checked, why not?
Really fancy dentists. Big offices, flashy machines, everything looked pristine. X-rays are taken, teeth are checked. Result: You need root canal! You should have it done soon, it's going to get much worse and hurt a lot more! We can do book you in ASAP.
Hollllld on. I was on holiday, I'm not about to have a root canal procedure done and ruin my time off. I'll take the xrays and check back with a dentist back home.
I pay dearly for the check and xrays and proceed to not enjoy my time off as much as I could have - I was worried.
Fly back home, book a session with my usual dentist. "I can't see anything wrong with this tooth. But let me do an xray as well... Nope. Can't see anything wrong."
It has been around 5 years now. That dentist would have performed root canal on me for no apparent reason...
One really interesting conversation I had with my usual dentist:
Me: So really, nothing wrong? Why would they say otherwise?
Dentist: Nothing wrong. I'm not sure why they told you otherwise.
Me: That's just...
Dentist: Tell you what, they say it's this tooth points, right? Do any other of your teeth look different in the xray? Check the root as well, pay close attention.
Me: I don't see any difference, but I'm not a dentist...
Dentist: Well, I am a dentist, but I also see no difference.
This is a really nice piece of tech that has helped me to work outside the house with peace of mind. Can keep my phone charged (which I use for tethering) for over a week, no problem. Drains way quicker when charging my M1, but that one has far less battery issues when compared to my phone.
The discount is real, as well. I know because I bought it recently, but you can also check it against camelcamelcamel or keepa.
That's why every single implementation of DDD is different. Every company that "implements" DDD does it differently. I've seen this a few times now.
Honestly, at this point, it's a bit like Agile.
I even recommend people not to install too many flask extensions, just use Django if that is how you like your development. Flask is much better when you just build for it - It takes longer to deliver, but you'll be enjoying that project for years.
Flask is for longevity.
The FastAPI docs read like a full project, a very dense project. Sometimes you just want to learn about a specific feature, but you walk into a page that assumes you have the context of the previous chapters, that puts me off a lot.
I also dislike how some of the documentation is absolutely enormous (the SQL chapters is one example), but I suspect this might have to do with the not-so-simple approach FastAPI takes, as opposed to Flask, which is indeed very simple.
I really can't join the crowd here. I don't think FastAPI is a replacement for Flask, even when async is taken out of the equation. Flask has some weird quirks to it (like "g"), but it really is a beautiful and simple API for the web.
Granted, I live a 20 min walk away. The walk in is through a beautiful county park, surrounded by nature.
Most of my colleagues who live further away have stopped coming in. Understandable, I wouldn't want to get in a car to get here, traffic in the UK is horrible.
It's all about personal circumstances, really. Living close to my workplace, having access to a nice office that is (now) mostly quiet, I quiet enjoy the new work culture :).
Unless you are financially crippling yourself over the "hobby", it's OK. I have a few keyboards lying around (I've returned a couple as well in the past), I like to change it up every once in a while. It often gives me that little extra push to work on something I might find boring.
I kid, I kid, it's all down to preference... That said, you can get yourself a single mechanical keyboard and call it a day, until one day you try a different board/layout with different switches. Maybe at your friends house, or at a shop, or more than likely: at work. You'll be forever wondering "I liked that...".
Keyboards really are a special tool for us. I've spent considerable amount of time and money on them, and I consider myself fairly frugal (well, in non keyboard related matters). All to say, it's very easy to fall into this rabbit hole, especially when you spend so much time working with these things...
You're in HN, talking about MS and acquisitions, telling them to learn to compete?
Am I on the right website or has my browser been hijacked?
I see your point, I really do, this stinks in all sorts of ways, but there could be a benefit here for a lot of players.
This has been my woe, and the same can be said about many of my friends and uni acquaintances. I suspect other fields might not have it this badly.
I have found a completely different culture here in the UK, there is so much demand for tech workers, combined with a much better approach towards companies investing in tech - it feels like the worker has that much power, if I'm not happy I can just go get a job somewhere else, probably within a week of quitting. It's a very different dynamic when compared to Portugal: Jobs are scarce and the pay isn't great. Tech is non-innovation driven, you're not there to think about the future, just to fix present issues that are very specific to some random company.
I don't miss Portugal at all when it comes to work.
This really nails it. I'm originally from Portugal (now living and working in the UK). Staying late and maintaining presence was a really big thing in Portugal. You really are looked down on when you leave early, it's a really terrible work culture, it genuinely felt like people would either overwork themselves or just generally do nothing with that extra time.
I tell my friends this story all the time: When I first arrived to the UK and started working, I asked my company about having my work email on my phone, my manager just had a completely blank face - "why do you need your work email on your phone?". I have been happily employed with this company for nearly 8 years now, never once feeling the need to stay late or go beyond the contracted hours. If I put in overtime, it's because I want to (most of the time because I actually enjoy the work). Oh, and I am paid for overtime. Completely unheard of in Portugal.
I know a lot of these things might be company culture specific, but there is definitely a level within geography - The lesser opportunities available, the more is expected out of you. As if having the opportunity to work should be seen as some sort of blessing.
This would be fine if Google embraced their dependance on ads, but Google still labels itself as a “search engine”.