YARP is yet a another example of how C# is becoming a dominant systems language.
The ease with which you can build a tailor-made reverse proxy is pretty amazing.
The ease with which you can build a tailor-made reverse proxy is pretty amazing.
In 2022 everything is a system programming language. Next on that list is Javascript, I am sure.
Yes but cool people will write their systems software in Typescript. :)
Perhaps a bit of a stretch. I am currently choose golang for a more systems like project because of startup time and gc pauses in c#/dotnet. Definitely nice to see nativeaot which should address the startup time issues.
Microsoft made a huge organizational change to support their cross-platform initiatives.
Additionally, YARP is cross-platform capable, so you can run the same proxy on Linux, macOS, and Windows. NGINX doesn’t even provide that, for example.
In terms of customizations, YARP is more like “what feature do you need to build in” than “how do I need to configure”. You can quickly build a simple reverse proxy and just about as easily setup a full load balancing solution, but the simple use case doesn’t need to include any of the code for the advanced use case.
nginx runs on all three of those platforms. If you mean the binary, this is surely misleading as you just move the burden from getting your platform specific binary to your platform specific .net runtime.
I can literally throw a stick and hit several devices in my office that NGINX runs on but C# does not.
Yes, when does this happen? That's what I'm trying to understand. You've provided some possible feature benefits to a DIY solution but you're really just trading NGINX internals for YARP internals here. At first glance, to my eye, one of those is going to have better community support and documentation.
> Additionally, YARP is cross-platform capable, so you can run the same proxy on Linux, macOS, and Windows. NGINX doesn’t even provide that, for example.
Yes it does? You might need to elaborate because this is just incorrect but I suspect you're trying to make a different point.
> In terms of customizations, YARP is more like “what feature do you need to build in” than “how do I need to configure”. You can quickly build a simple reverse proxy and just about as easily setup a full load balancing solution, but the simple use case doesn’t need to include any of the code for the advanced use case.
My main issue with this idea is that the average consumer of this is going to be better positioned to handle the engineering hurdles of writing their own advanced use cases.
So you are right, it is a very specialized situation, but the key stakeholders who asked, contributed and collaborated with the .NET group are exactly these engineers who previously did a DIY solution.
This is an interesting take that I think is perhaps naive. Microsoft has a vested interest in pushing .NET as a development platform and can push teams to use the company's flagship programming stack in everything it does. From the perspective of given individual teams within the company this may not appear to be self-motivated but how could it not be, given the driving requirements to use MS-approved technology stacks?
What your comment misses the mark on is what the driving force behind those engineering decisions is. If the decision is driven by corporate guidance to use .NET or else (this is a hypothetical), it's not exactly because the engineers themselves wanted to write something from scratch in .NET to solve a particular well-solved problem.
Office for example took React Native as a UI toolkit and invested in that instead of .NET. Typescript was invented to help them. The Windows division uses C++ based COM / WinRT and built a independent framework.
Microsoft is not a pure .NET shop. There are not even a anti-Java shop
While this is no doubt true the implied context of my reply was to the idea that Microsoft's engineers were selecting the best available option, the terms of "best" insinuating "best for anyone" rather than "best for software developer at Microsoft" -- a key difference.
> Office for example took React Native as a UI toolkit and invested in that instead of .NET.
Only after many years of trying to make WPF work and seeing the tide go another way.
> Microsoft is not a pure .NET shop. There are not even a anti-Java shop
For sure, C# and J# were basically the replacements for the failed attempted co-opting of Java that was J++. As far as I can tell their only Java related product is their own build of OpenJDK designed to be used on Azure. It's unclear what contributions they've really made in the space.
While they may not be a "pure .NET shop", I'd bet they're the closest thing out there.
I'm not suggesting Microsoft 100% ignores broader trends but this is sort of an aside from the crux of the original commentary.
As Ballmer used to say: “developers, developers, developers”. Microsoft has long known that what is best for developers is what is best for Microsoft.
In highly regulated or extremely sensitive industries.
The first specific example I can think of is JupyterHub - it handles user management and starting/stopping Jupyter Notebook servers, then provides a reverse proxy for users to access their notebook servers directly.
Basically, we needed to to auth on each request (can the user see this per a slightly complicated rights system) and we routed to automatically spin up containers,so discovery was also custom
It won't become a systems language until it will let you to directly access hardware and do memory management, it will have improved performance and it will be natively AOT compiled.
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...