> Maybe its me being stupid but why don't we use quic always instead of tcp?

A big reason is because QUIC is a lot younger than TCP and it will take a while for all the use cases of TCP to decide (if they are actively maintained and looking at possible upgrades) if QUIC is a good option worth testing.

QUIC's rollout so far hasn't been entirely without bugs/controversies/quirks/obstacles/challenges. You still see a lot more HTTP/2 than HTTP/3 connections in the current wild and that doesn't seem to be changing near as fast as major providers upgraded HTTP/1.x to HTTP/2. There's still a bunch of languages and contemporary OSes without strong QUIC support. (Just the other day on HN was a binding for Erlang to msquic, IIRC, for a first pass at QUIC support in that language.)

Some point soon QUIC might start feeling as rock solid as TCP, but today TCP is (decades of) rock solid and QUIC is still a lot new and a little quirky.

Safari on IOS still has a ton lingering HTTP/3 / QUIC bugs.

I think it is to the point that if your user base doesn't warrant it, (i.e. you are targeting well connected devices with minimal latency/packetloss) it's not even worth turning HTTP/3 on

so quic just lacks the decades of experience but is a better protocol than tcp overall ?

That is kind of nice to know actually. The support will come considering its built on top of UDP. You just need people pushing and google is already pushing it hard .

The main problem is quic's support in languages. But support will come.So after reading this comment of yours , I am pretty optimistic about quic overall

Not necessarily a "better protocol overall", it still seems too early to tell. I think we're still in the "Find Out" stages because of the rollout issues and the lack of language support and lack of diversity of implementations.

(On the diversity of implementations front: So far we've got Google's somewhat proprietary implementation, Apple's kind of broken entirely proprietary implementation, and Microsoft's surprisingly robust and [also surprisingly to some] entirely open source C implementation. General language support would be even worse without msquic and the number of languages binding to it. Microsoft seems to be doing a lot more for faster/stronger/better QUIC adoption than Google today, which I know just writing that sentence will surprise a lot of people.)

There will be trade-offs to be found with TCP. For instance, a lot of discussion elsewhere in these threads is on the overbearing/complicated/nuanced congestion control of TCP, but that's as much a feature as a bug and when TCP congestion control works well it quietly does the internet a wealth of good. QUIC congestion control is much more a binary: dropped packets or not. That's a good thing as an application author, especially if you are expecting the default case to be "not" on dropped packets, but it doesn't give the infrastructure a lot of options and when pressure happens and those "allow UDP packet" switches are turned off and most of your packets as an application developer are dropped how do you expect to route around that? At least for now most of the webservers built to support HTTP/3 still fallback to HTTP/2 on request, go back to the known working congestion control of TCP that most of the internet and especially the web was built on top of.

I'm not a pessimist on QUIC, I think it has great potential. I also am not an optimist about it 100% replacing TCP in our near future, and maybe not even in our lifetime. As an application developer, it will be a great tool to have in your toolbelt as a "third" compromise option between TCP and UDP, but deciding between TCP and QUIC is probably going to be an application-by-application pros/cons list debate, at least in the short term and I think probably in the long term too.