as far as I've heard from HFT people Java's relatively popular in HFT
what C# lacks here?
is there huge gap between CLR and JVM?
what C# lacks here?
is there huge gap between CLR and JVM?
Java's popularity depends how HF in HFT is and the threshold for pain developers are willing to go through to develop Java in a way to avoid GC and reduce memory use (and hence reduce cache misses)
Deploying to Linux boxen in colocation facilities is the norm and there is little/no culture of using dotNet on Linux. We all know it exists and it's open source now, but most Linux developers don't reach for dotNet.
On that note, how bad is .NET experience on Linux vs. on Windows? Besides the IDE (MonoDevelop is no Visual Studio).
I was about to dig into this topic soon - I'm particularly interested in how useful PowerShell is on Linux these days. On Windows, I appreciate the deep .NET interop it offers; I think it's closest experience to Lisp Machines that you can find in mainstream computing.
EDIT: Big thanks to the commenters who mentioned Rider, I didn't realize JetBrains had an IDE for .NET!
That said, to clarify my comment above, I'm more interested in the experience with the platform itself - how does .NET Core work on Linux in terms of performance, fragility, access to first-party and third-party libraries? Can I expect non-UI .NET code to port well to Linux? And, in PowerShell, do I get to do things like Add-Type "<insert bunch of C# code here>", or $foo = [Some.dotNET.Type]::new()?
JetBrains Rider is such a pleasure to work with.
If it wasn't written with tons of pinvoke to win32 or using Windows-only services (like WCF), then sure.
I've been building NET Core applications for Linux and exclusively on Linux for a few years now, mostly using Rider as the IDE. No complaints. I haven't seen any Windows-exclusive libraries worthy of any attention in all that time. Even libraries with tons of native code (like imagemagick) have Linux support.
The official MS tooling is behind what they offer on windows, but it's getting there. You can collect GC and memory dumps
https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dot...
https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dot...
traces:
https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dot...
and here's the port of the veritable sos tool:
https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dot...
it's pretty weird sentence "most Linux developers dont use dotNet", but on the other hands dotNet (Core) developers definitely do use Linux - I have dotNet things on Linux on prod for 2 years atm
- More support for UNIX and mainframe flavours
- Given the multiple implementations, there are plenty of GC, JIT and tuning options to chose from
- .NET Core is the Python 3 of .NET world, not everything from .NET Framework is available or portable to non-Windows platforms
- Several JIT optimizations quite common in JVM world are only now coming to CLR, like dynamic rewrite of native code
Source being compatible doesn't help when the libraries require code rewrites anyway.
Leave CLR in applications, where it belongs.
Also from my experience coaching and consulting there's a significant learning curve for .NET framework developers to work in the new core/.NET 5 systems.
https://docs.microsoft.com/en-us/lifecycle/products/microsof...
I bit the bullet and transitioned from WebForms to ASP.NET Core. I think it's easier than WebForms ever was. You can replicate 90% of what WebForms did with Razor Pages, but you also get much easier support for building RESTful APIs. And with DI built-in, I don't have to worry about junior devs forgetting to close/dispose database connections ever again.
If you've followed the .NET blogs at all, they have very good reasons they haven't prioritized support for these legacy systems. There isn't some cabal of platform designers in Redmond scheming on how to screw over developers at ossified orgs.
Not sure why I'm bothering. Everytime someone mentions .NET on here, someone comes out of the woodwork to complain about their pet features not being supported. Actually, come to think of it, it's often you in particular. We're going from .NET Framework being fundamentally tied to Windows to a new .NET that runs on everything. ASP.NET was built on HTTP.sys, a Windows driver for a web server. I don't know, is it terribly surprising that trying to migrate .NET off of Windows-only dependencies is going to break things downstream?
But if you still need this stuff that only runs on Windows, well, you got at least decade of support to look forward to.
I literally think you're asking for too much.
On my pet projects I use whatever I feel like.
It's certainly reasonable, but will take re-work for many applications beyond the project structure migration. I think in .NET 6/7/8 the .NET framework migration situation will improve to be mostly pure migration.
For example I migrated about 75% of a moderately large winforms system directly, but 25% needed rewrites due to missing core implementations for framework libraries. e.g. MS chart component not implemented in core yet, soap services changing to grpc, and various others. And this system was originally built to minimise third party dependencies and use the core framework or microsoft provided libraries wherever possible.
Is there anything in .NET 5 you're missing from .net 4.x?
MS is a big company, they aren't going to immediately migrate everything just like Google didn't migrate every single project to Go when they were heading it.
Options. You are talking about the very tiny subset of Java users who actively worry about the relative differences in performance tweakability of different JVM implementations. Chances are that they routinely run multiple VMs and VM configuration sets in parallel on real world inputs to find the fastest configuration.
"Look at this nice VM, trust us, it's very fast, rewrite all your code and see for yourselves!" just won't be very convincing to those. With that crowd, .NET isn't competing against the JVM, it's competing against against an entire market of competing JVMs.
The biggest issue would be avoiding heap alloc, but that is actually not too difficult if you manage your data well enough. Most transactions in this business can be defined in terms of structs that are <1kb in size.
One other approach I have started to look at is sacrificing an entire high-priority thread to handling well-batched transactions (or extremely important timers) so that I never have to yield to the OS. In HFT, you always get an entire physical server to yourself, so eating 1 out of 32 threads is not a huge deal. In testing of this idea, I have found that I am able to reliably execute timers with accuracy of around 1/10th of a microsecond.
Java probably has more optimizations around GC suppression, but I feel like avoiding allocation in the first place is the most important bit. I believe there are already some ways to trick .NET into not running GC.
1 thread for ultra-low-latency timer execution
1 thread for processing the actual client event ring buffer, producing a consistent snapshot after each microbatch execution.
14+ threads for servicing HTTP requests (i.e. enqueuing client events), timers and redrawing client views using the near-real-time snapshots of business state.
My thinking is that if I can build something in this domain that is satisfactory, I could consider bringing it to an HFT firm as well.
[0]: https://www.youtube.com/watch?v=ug_UC4lxMr8 [1]: https://news.ycombinator.com/item?id=24896616
Java is not popular in HFT other than 2-3 shops using it.
C++ is best choice IMHO. It has become easy to use it and plus you can get compile time branch prediction with templates.
RAII also amazing. RAII looks like a GC but it's not but it's works like a GC ..
Branch prediction is a CPU level thing, and mis-predictions has a cost. You can do things like partitioning data beforehand so that a given if condition will take the same branch each time in the partition, but I don’t see how does it apply to templates at all.
You can’t avoid branches that depend on runtime infos, and those branches that depend on compile time known infos can be elided either automatically by the compiler if it can prove it is constant for example, or by things like constexpr, templates as you say. But it’s nothing too fancy, the dumb C-preprocessor macro can do similar things.
JIT-compiled languages can sometimes elide branches based on runtime data, so there is that.