Foreign keys both define relationships between tables, and also enforce referential integrity. The discussion is about how we could potentially mine various additional value from foreign keys as an information resource, rather than just mostly being about referential integrity.
Would it? Unless the sound is produced from inside their body in the same manner as natural, no it will sound weird just like playing back your own voice.
Not necessarily - people close to me were complaining about what they saw as losing a part of their identity ( and grandchildren definitely were not happy about the change).
Even for those who learn to speak with an oesophagal voice, being able to real time map it to something more natural would be great.
To be more specific, they consider themselves to be 'voice mutilated', even when able to speak, so I guess that anything closer to their original voice would be a net benefit.
No, it’s not really fan art. It just happened one of the largest art patrons was the church. They wanted art to “educate” (i.e. evangelize) a largely illiterate population. And there was no internet back then, so every religious site would need art illustrating the same themes.
The person who leaked either: used their repo as a basis for their readme, just found some random character and decided to use it, or it's one of the discord people they were talking about.
>Even the digital property liberators/internet pirates don’t test their software. I feel like I’m on an island with a small population of test enthusiasts.
Ultimately, what's the point. The tool either works, or it doesn't. Then you patch what doesn't work so it does work.
Heck even the Linux kernel isn't tested.
Unit tests are so management can have a good metric to sell code quality. I don't know any time unit testing has actually benefited shipping faster (which really is the only bottom line those above you care about)
> I don't know any time unit testing has actually benefited shipping faster
There's a lot of empirical research about this. A. Lot. Starting in the 80's, even. It's as close as it gets to empirically proven that software testing greatly reduces bugs and regressions, and accelerates delivery over the long term. It's not as clear if the acceleration is entirely freed up resources that would otherwise be spent fixing bugs, or if it also makes people develop faster. Also, it's pretty clear that Automated testing doesn't accelerate short or short term projects.
> I don't know any time unit testing has actually benefited shipping faster
It's of huge benefits to me when I have to make a small tweak (fix a bug, or add a new specific corner case) into an existing codebase that I didn't write and don't know very well.
Being able to make a small change and being confident that it will not send everything burning in hell.
This, and any code base of significant size is unknowable and starts to produce bugs naturally. Requiring tests and verifying minimum coverage are a few things you can do to control the death spiral.
I have worked on large systems devoid of tests. Not recommended. I literally witnessed multi-million dollar losses that would have been prevented by requiring tests.
Apart from the Linux Test Project [0], run by all the big Linux names, who regularly issue very detailed bug reports and usually patches as well, you mean?
And the test covers much less surface area than most manual tests.
For code that's expected to be stable for a LONG time - sure, write lots of good tests.
For code that breaks at someone else's whim, which has a small shelf life, or which has a large surface area, think really, really hard about whether the test is actually going to be worth it.
> Fastapi is far from world class in any category other than usage.
Imho FastAPI's weakest point is maintenance. The Github repo has 800+ open issues and 400+ open PRs. Tiangolo is the only user that constantly makes non trivial contributions. I just can't see that being sustainable in the long term if all those items are not actively triaged.
Yeah it is definitely in the wildly popular upswing phase. I'm hoping it attracts a crew of maintainers to take some of the burden off.
The one thing it has going for it is much of the heavy lifting is done by starlette, maintained by encode.io, which is actively funded. It's not trying to be rails, rather it's relying on other libraries and packages to add functionality.
The documentation is the worst I've ever seen. There is no API reference! Just a bunch of incohesive tutorials that hopefully overlap with what you're trying to achieve.
I agree, but as someone who has been working with Django for years, my standards are pretty high, and I'm opinionated when it comes to docs.
Check out my latest post on HN. Seemingly the creator and single maintainer is ignoring requests from developers to let other people maintain the project. I used FastAPI at work some time ago, but I can't see myself using it again anytime soon. Imho relying on someone's personal project for software that's going to be in production indefinitely is a big risk.
I didn't like the Django philosophy. So it was FastAPI vs Flask RESTful. People kept saying FastAPI was the next big thing, but nothing can beat Flask documentation and the FastAPI community and documentation felt like, "you ought to know that before you ask".
OP asked for good projects to read. I think the code quality is very high, the documentation is great, it's been a joy to use, and it's been more than fast enough for my purposes.
I didn't make that speed claim, though I am aware that tidbit is controversial.
In the composite benchmark, fastapi is 75th, express (the most popular node framework) is 94th, Gin (a popular go framework) is 55th, NodeJS is 56th.
In the continuous benchmarks, that you can see here [1], taking the last one that has finished at the time of this post (run id 31abee0e-b0c5-414f-9288-216c48e3a70e): Fastapi is 81st, Express 107th, Gin 57th, NodeJS 63rd. In the fortunes part, plain Go is always higher than Gin but varies wildly, from ~15% to ~43%. FastAPI itself is around 7%
I think Express is still the most used JS framework, by a large margin, so claiming to be faster than NodeJS may be fair, as most people thinking about NodeJS will think Express. For Go, you have to be very generous with the "on par", to the point that it's almost meaningless in my opinion. Especially since frameworks are less popular in Go, people tend to use the standard library, which has great performance here.
That chart shows fastapi and nestjs are 2 of the fastest libraries among dynamic languages. And nestjs is <20% faster than fastapi because fastify is <20% faster than starlette.
Not sure what this has to do with the library’s quality though, it is a high quality modern python library.
> That chart shows fastapi and nestjs are 2 of the fastest libraries among dynamic languages.
With only JavaScript, Perl, Lua, PHP, Python and TypeScript enabled, fastapi is 64th and nestjs is 73rd, out of 136 libaries. They have a score that's ~10 times lower than the fastest libraries.
You have to deselect platforms first off but even then you will still see starlette and fastify on the list being compared to frameworks like nestjs and fastapi. The anomaly is workerman/swoole based PHP libraries which are significantly faster than other dynamic languages frameworks by 2-10x it’s not that express and Koa and fastapi etc are slow it’s that PHP is an anomaly. This is the problem with this benchmark it’s very misleading.
This is not an anomaly. Workerman and Swoole are asynchronous PHP frameworks. Node is asynchronous by default, so Express/Koa/Fastify/NestJS are asynchronous. Starlette is an ASGI framework/toolkit, so it's asynchronous too. FastAPI is based on Starlette. The thing is that asynchronous PHP is way faster than asynchronous Python or asynchronous JS. There is nothing misleading about this. If you need performance, PHP is a better choice than Python or Javascript
If you have to deselect 20 default filters and then read through the frameworks in the list to see which ones are fully featured web frameworks in order to evaluate whether a library is suitably fast for your next project it is misleading. But again, I'm not sure what this has to do with it being a high quality modern python library.
> If you have to deselect 20 default filters and then read through the frameworks in the list to see which ones are fully featured web frameworks in order to evaluate whether a library is suitably fast for your next project it is misleading.
It is not, this benchmark is purely about speed, not about being "suitable for your next project". You're the one adding all these other constraints. You only need to deselect some filters when you're doing something like comparing dynamic languages, which you did and wasn't even the initial claim discussed. I also doubt most people would call FastAPI "suitable for your next project" compared to something like Django or Flask that is already well known and maintained.
> But again, I'm not sure what this has to do with it being a high quality modern python library.
We're in a subthread discussing a claim on the FastAPI website that it's "Fast: Very high performance, on par with NodeJS and Go.", and how it's obviously wrong for Go, and possibly wrong for NodeJS.
NestJS is what I use for my website, https://www.codehawke.com. I have no idea if this provides any speed burst over fastapi, but I'll say it's a lot of code making Nestjs run. It can't be a good choice for basic static/serverless apps. These benchmarks are questionable.
I use it for a side project, I had to disable a lot of it’s useful features to get anything resembling performance out of it. A lot of this seems to stem from Pydantic though but is in no way as fast as Go out of the box and I also feel they should remove that line.
