Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

341–350 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#341

Post by gruez »

kstrauser wrote: post #324
frollogaston wrote: post #307

Earlier quoted context omitted.

"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.

Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.

Plenty of mobile users use wifi at home/work. Telling them to disable their ipv4-only wifi just to play your game is going to be a non-starter, especially when the cost of ipv4 address adds negligible cost to infrastructure. Is your CTO really going to massively increase user friction ("turn of your wifi to play!") just so try to save a few cents (comparatively speaking) on infra?

Re: HTTP/3 is everywhere but nowhere

#342

Post by ezfe »

antisthenes wrote: post #207
JimDabell wrote: post #184

Earlier quoted context omitted.

It’s not evolving at all: > Requests is in a perpetual feature freeze, only the BDFL can add or approve of new features. The maintainers believe that Requests is a feature-complete piece of software at this time. > One of the most important skills to have while maintaining a largely-used open source project is learning the ability to say “no” to suggested changes, while keeping an open ear and mind. > If you believe…

It takes a very special case of a person to complain about a feature-complete piece of software not evolving fast enough.

But it's not feature complete if it can't make modern networking requests when the whole point of a library like requests is to make networking requests.

Re: HTTP/3 is everywhere but nowhere

#343

Post by fireant »

CharlieDigital wrote: post #257
hu3 wrote: post #253

Earlier quoted context omitted.

LINQ alone is unmatched.

Addendum: having `Expression`[0] type representing the expression tree is a really killer feature. I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs. [0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

LINQ in EntityFramework certainly isn't perfect, but frankly it's so far ahead of anything else available in all other languages. It was a brilliant idea to add expressions type into the language AND to create a standard set of interfaces that enable collection interop AND to to then create universal clients for local and remote collections that use all this machinery to deliver first class DX.

Re: HTTP/3 is everywhere but nowhere

#344

Post by kstrauser »

frollogaston wrote: post #305
p_l wrote: post #302

Earlier quoted context omitted.

And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets. Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol. On hw side, by mid-1990s even changing one routing-im…

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant. And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.

Where would you store the other 96 bits. In the body?

Re: HTTP/3 is everywhere but nowhere

#345

Post by int_19h »

redeeman wrote: post #314
ziml77 wrote: post #273

Earlier quoted context omitted.

It's not about different teams, it's that System.Windows.Forms is exactly what the namespace says. It's Windows Forms. It's a fairly thin wrapper over the Windows API. It's never going to be adapted to be cross-platform and isn't really something they've put any development work into for many years at this point. If you want a cross platform UI, use WPF with Avalonia. Or if you want something entirely from Microsoft…

obviously system.windows.forms could easily be implemented elsewhere, but okay, does any of the other UIs work fully properly on for example linux?

> obviously system.windows.forms could easily be implemented elsewhere

It can, but not easily. As OP has said, it is a wrapper around Win32, and not an opaque one - it literally has stuff like e.g. the Message struct with members like HWnd and LParam.

Mono did try at one point, but they kept hitting edge cases where this kind of stuff would break things. Eventually they gave up and just wrapped Wine. So, yes, if you really really want to run WinForms on Linux, Mono is where it's at. But ... why?

Re: HTTP/3 is everywhere but nowhere

#346

Post by int_19h »

CharlieDigital wrote: post #322
einpoklum wrote: post #312

Earlier quoted context omitted.

Can you name some examples of popular .Net applications on GNU/Linux or *BSD operating systems?

I can't even name any on Windows. But that's not really what's being discussed in the context of this thread: application servers handling HTTP/3.

On Windows, a lot of desktop software is .NET these days. It can be pretty hard to say when the apps use native (or XAML) UI, though.

To give one example with a particularly large user base, NVidia control center was a WinForms app for a very long time.

Re: HTTP/3 is everywhere but nowhere

#347

Post by int_19h »

fireant wrote: post #343
CharlieDigital wrote: post #257

Earlier quoted context omitted.

Addendum: having `Expression`[0] type representing the expression tree is a really killer feature. I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs. [0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...

LINQ in EntityFramework certainly isn't perfect, but frankly it's so far ahead of anything else available in all other languages. It was a brilliant idea to add expressions type into the language AND to create a standard set of interfaces that enable collection interop AND to to then create universal clients for local and remote collections that use all this machinery to deliver first class DX.

"All other languages" is a stretch IMO. Any language that has proper macros (e.g. Rust, Clojure) can do something LINQ-like as well as C#.

Re: HTTP/3 is everywhere but nowhere

#348

Post by int_19h »

CharlieDigital wrote: post #327
neonsunset wrote: post #318

Earlier quoted context omitted.

TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole. There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).

Got it; thanks for the tip!

The TL;DR version is that they don't really use classes and inheritance (which is the part that would be hard to map to Go but easy to map to C#). It's all functions dealing with struct-like objects.

The other part of it is that C# is very firmly in the nominal typing camp, while TS is entirely structurally typed. Go can do both.

Re: HTTP/3 is everywhere but nowhere

#349

Post by int_19h »

Teckla wrote: post #86
CharlieDigital wrote: post #38

Earlier quoted context omitted.

> So I think it is safe to say C# is indeed a minor language That's not really the case; StackOverflow survey[0] shows C# (27.1%) right behind Java (30.3%) and well ahead of Go (13.5%), Rust (12.6%), Kotlin (9.4%), Ruby (5.2%), and Scala (2.6%). If we exclude HTML/CSS, Bash/Shell, and SQL, C# would be #5 in actual languages used over the past year by devs in this survey. You get the same result from scraping job post…

But because they had an existing body of code that was not class based, it would be more of a re-write (C#) versus a refactor (Go). I don't understand this reasoning at all, and I'm hoping you can shed some light on it. As far as I know, C# supports static methods. Thus, using OO in C# would not have been required, would it? I feel like I'm missing something here.

C# supports top-level functions as well, that's not the issue. But, just to give a simple example, in TS you can do things like:

   var foo: { bar: { baz: string } }
which have no equivalent in C#, because it doesn't have anonymous struct types, and its typing system is almost entirely nominal. Go, on the other hand, can translate this directly pretty much mechanically:

   var foo struct { bar struct { baz string } }
And keep in mind that they aren't completely ditching the existing implementation, either, so for a while they're going to have to e.g. fix bugs in both side by side. It helps when the code can also be mapped almost 1:1.

Re: HTTP/3 is everywhere but nowhere

#350

Post by int_19h »

jabart wrote: post #117
xpressvideoz wrote: post #35

Earlier quoted context omitted.

> side note: sad that .NET and C# are not considered "major"... Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.

The interviews with the Typescript dev doing the rewrite will tell you why. Switching their compiler to Go was a quick transition since Go matched their current JS build. The dev also wanted to use go, and use functional programming. It would have required more work to switch from functional to OOP style that C# has. Dev also didn't want to learn F#. Nothing about C#, just a personal decision with the least amount of…

FWIW the "functional programming" angle here is misconstrued - C# has better facilities for it than Go.

The thing that they actually wanted is data-centric programming with structural types.

Post reply on HN