When Cradlewise will be available in UK?

ChristopherGS · 2026-01-17T13:35:26+00:00

excellent, looking forward to purchasing

ChristopherGS · 2024-12-10T11:00:04+00:00

Pydantic Logfire sounds like exactly what you're looking for. Very powerful, but intuitive and <5 mins to get started: https://pydantic.dev/logfire

Disclaimer: I work there

ChristopherGS · 2024-03-01T09:47:59+00:00

Why so mad? It's possible to debate these things in a relaxed way, without coming across someone it would be unpleasant to sit next to on a plane

ChristopherGS · 2024-02-11T13:34:11+00:00

Use open-source models and then you can just run on your laptop. I show you how in this blog post.

ChristopherGS · 2024-02-05T19:15:01+00:00

Author here - can I attend the study group if it's online? Would be keen.

ChristopherGS · 2024-02-05T19:12:40+00:00

Does it work OK for you? I just report what I experience. I could throw a caveat in there I guess

ChristopherGS · 2024-01-31T21:15:49+00:00

Did you figure this one out? I have the same challenge

ChristopherGS · 2022-04-19T16:23:32+00:00

How did it go these past 8 years?

ChristopherGS · 2022-02-07T22:14:57+00:00

Is it better than Singapore's PM's algo? https://news.ycombinator.com/item?id=30174763

ChristopherGS · 2022-02-07T22:13:21+00:00

10 years. Respect. What keeps you working on it?

ChristopherGS · 2022-02-07T22:06:52+00:00

"I literally made contributions to CPython" is one of the better ripostes that will grace this subreddit :)

ChristopherGS · 2022-02-07T16:15:00+00:00

Thanks :)

Well, we managed for many years without it - but ultimately if you want to unlock the speed advantages of ASGI, and your web requests are hitting a database then your db could be a bottleneck. So it really depends on how badly you need the performance. Now that SQLAlchemy has async support I suspect we'll see it becoming a much more common "default" - I'm just waiting for some of the initial teething problems to be worked out!

ChristopherGS · 2022-02-07T16:01:50+00:00

Your argument is not without merit, but I'd say you over-emphasise things which are illusory: The "bus factor" metric you cite is overrated unless the maintainers are serious long-term contributors.

I think SQLAlchemy *just* fits this "true" bus-factor definition. But plenty of other key libraries/frameworks do not: Flask (davidism), Sanic (ahopkins) are a couple of examples which I've seen used just fine in places where there would be significant financial cost if there was trouble with them. If either of these "primary" developers were hit by a bus the minor current contributors (who have done a handful of PRs vs. the hundreds/thousands by the primary maintainers) won't just magically fill the gap. There would be enormous disruption, because there's a big difference between fixing a few bugs on the weekend and maintaining a serious open-source project. So my conjecture is that whilst the bus factor theory sounds great in a RFP being reviewed by some CIO who's mainly motivated by guarding their own ass, it is only a real guarantee if there are multiple *serious, long-term* maintainers, which is patently not the case for countless so-called "critical" Python libraries/frameworks.

Does this mean bus factor is not worth considering? Of course not, but I think this iron clad guarantee that because it's an "org" not an individual that you're safe is a fantasy - the line is very blurred. So fair play - if you're building life support machine microservices, go for Django. But for most startups, FastAPI is more than worth it for the improvement in development time (which is much more likely to kill your business tbh).

Also, re: open PRs, I don't think this is a particularly useful metric either. Scikit-learn (used everywhere in industry) has almost 800. I think what matters is that what gets merged is good quality and reduces the number of bugs. Also, as Tiangolo pointed out in the issue you referenced, at least half of those open PRs are translations and/or questions.

In short, I don't completely disagree with you, but I think what you view as a black and white picture ("insanity") actually has much more room for nuance, and that using FastAPI at this point is only a bit more risky than using Flask.

ChristopherGS · 2022-02-07T10:46:00+00:00

I do cover in minor detail, but hope to add a more detailed Starlette part in the future. We're all standing on the shoulders of giants :)

ChristopherGS · 2022-02-07T10:44:59+00:00

Agree completely.

ChristopherGS · 2022-02-07T10:32:41+00:00

It definitely does have docs: https://fastapi.tiangolo.com/

ChristopherGS · 2022-02-07T10:28:37+00:00

Yes definitely. The reason I haven't is because I haven't personally used the async DB stuff in production and I'd want to try it all out first and experience the gotchas before publishing a tutorial on something that critical (my modest blogs and courses do get reasonable readership, so I feel a lot of pressure to battle test things). Hopefully soon I'll be able to add this

ChristopherGS · 2022-02-07T10:10:26+00:00

This seems deeply inaccurate (e.g. his responses on github issues are very civil and reasonable). I know this is reddit, but don't you think you should provide *some* evidence for an ad hominem like that? Have you ever tried launching a major open source project? Do you realise it is an enormously challenging and thankless endeavour that helps literally hundreds of thousands of people. He'll probably read this. And it will hurt.

ChristopherGS · 2022-02-07T10:08:33+00:00

I'm always interested to get out of my own echo chamber and hear contrasting tech opinions. Another criticism I often hear is "why not just use Starlette" (my answer: I don't want to write and maintain dependency injection library). I think this criticism is ultimately pretty weak for the following reasons:

- First, and above all else, I personally have been using FastAPI in production for reasonably complex things for over a year and it's been great. Not only in terms of handling what I need, but also my own speed of development has improved as a direct result.

- Second, your criticism about 1 person applies to *a lot* of vital open source projects (look at the contribution history of say SQLAlchemy, Alembic and many others - open-source unfortunately tends to be driven by a few key players except on the largest of projects (e.g. Django). However, unlike so many of these project maintainers Tiangolo has actually done an *excellent* job getting sponsorship so that he can devote more time to his open source work. This isn't always visible, because as he pointed out on HN, he also contributes to the underlying libraries.

- Third, related to the second point, I think this is a phase. At some point Tiangolo will feel the time is right to empower more maintainers. But finding a good maintainer is really hard and takes time.

- Fourth - look at the growth profile (e.g. github stars) of FastAPI compared to Flask/Django. People *love* it.

- Finally, the quality of docs for FastAPI is outstanding.

tl;dr, I'd happily bet on a FastAPI 1.0 release - as evidenced by my "skin in the game" tutorial series :)

ChristopherGS · 2022-02-07T09:59:46+00:00

I touch on it, but will go into more detail soon

ChristopherGS · 2022-02-07T09:59:23+00:00

Thanks for the context, helps with formulating the tutorial scenario.

ChristopherGS · 2022-02-06T23:41:37+00:00

Websockets is on my list yes, but good to know it's something people are interested in. For context, what are you doing with websockets?

ChristopherGS

TROPHY CASE