Quick question



  • Most of his complaint seems to consist of disgust over the .NET ecosystem not having a "high-performance TCP/UDP socket server middleware". Later he calls it a "a reactive, server-side socket library".

    His project is described as follows:

    Helios is concurrency and networking middleware for .NET - think of it as a loose C# port of Java's wildly influential Netty library. Helios offers .NET developers the ability to develop high-performance networked applications on top of TCP and UDP sockets combined with powerful stream-management, event brokering, and concurrency capabilities.

    My question is simply this:

    What does it do?

    Or more specifically, what does it do that you can't simply do yourself in a few lines of code exercising System.Net.Sockets?



  • Very cursory lookover + rusty .NET chops, so take it for what's it worth.

    a reactive, server-side socket library

    If memory serves me, in standard .NET, you create a socket object and then actively listen for connection. Thread locks in a loop until a connection is made. Then your handler code runs. Rinse and repeat. This is standard "old-fashioned" way to do servers.

    His "reactive socket", I suppose, means that this waiting code is hidden inside his framework. He probably has some kind of thread pool, so he can quickly spin off handlers that run your code, while his socket code can go back to listening for new connections. Kind of like what node.js does.

    He also has a bunch of other utilities listed on the git page.

    So it's like any other library. Nothing you couldn't theoretically code yourself, he just does the dirty work (including testing etc), so you can focus on the higher layers.



  • @cartman82 said:

    His "reactive socket", I suppose, means that this waiting code is hidden inside his framework.

    Right; but you're just guessing.

    I'm trying to figure out why this thing, which sounds on the surface to be...

    @cartman82 said:

    He probably has some kind of thread pool, so he can quickly spin off handlers that run your code, while his socket code can go back to listening for new connections.

    ... literally a dozen lines of C# is so goddamned important that it indicates this "terrible problem" of lacking OSS.

    I mean, hell, I've written that at least twice my own lonesome self. I guess if I had realized I could have become an open source HERO! by sharing my code, maybe I missed an opportunity.

    @cartman82 said:

    Kind of like what node.js does.

    ... kind of like what literally any server app written since threading support existed do, you mean.



  • Don't know, I guess the proof would be in a comperasment test between his library and .NET native.

    BTW that's a pretty good article.



  • Also, comments are fun.

    Why would i pay for a license to develop something that nodejs can do with much less of everything. .NET is broken. It is not inherently asyncronous, it is stack heavy, and most importantly, it is mostly used on an operating system with Command Prompt as a shell. I mean.. Get real. The clicky clicky run crash windows method will never match the kernel hacking, shell scripting, performance squeezing approach of REAL developers who consider a mouse cursor as a fisher price wannabe.



  • I concede that there are fewer OSS projects for the .NET ecosystem, but the cause and effect are wrong.

    There are fewer because you don't need a seedy OSS library to do most of the stuff you want to do in .NET-- it's already built-into the excellent framework. So the fact that there are fewer libraries is actually a good thing.

    .NET is structured basically like Classic Mac, with a "thick" library that contains just tons and tons and tons of building blocks you can put together to build your house. Win32 and Linux and open source-y stuff is generally build with the C philosophy, where the standard library is extremely thin and you're basically relying on third-party libraries to do almost anything useful at all.



  • OK, there's some of that.

    But how do you explain Java then? It's a thick library, but also a vibrant ecosystem surrounding it.

    Also, as the guy said, MS is focused on the CRUD-like stuff that Enterprises want. So, without a strong OSS ecosystem, if MS isn't interested, you aren't getting it.


  • Discourse touched me in a no-no place

    @cartman82 said:

    Thread locks in a loop until a connection is made.

    Possibly minor nitpicks: you actually block (wait), not loop. And there are non-blocking sockets, where you get a notification when data comes in (or else you get an error saying "operation would block").

    Maybe that's what he thinks is "missing"?



  • @cartman82 said:

    But how do you explain Java then? It's a thick library,

    But it's not.

    All the Java stuff was stuff added in by the community. It started out with complete crap. It didn't even have an IDE or build system until third parties came around and made one. I mean just list the stuff Java projects use that wasn't originally developed by Sun/Oracle:

    • Unit testing
    • Freakin' Build system
    • REST API of any sort

    probably more I can't think of off the top of my head.

    @cartman82 said:

    Also, as the guy said, MS is focused on the CRUD-like stuff that Enterprises want.

    I mean I get what you're saying, but the basic building blocks are there to create a "reactive socket library" in like 12 lines of code. Is it any wonder nobody ever took those 12 lines and said, "hey I'm a total douchebag, I'll make an open source library out of this and be the open source hero-man!"

    Like go back to the Java REST API example. Even before WebAPI existed in .NET, there was the .ASHX WebHandler class, which could (with about a dozen lines of code) do the exact same fucking REST API as your WebAPI application. Again: I've written that like twice, and never thought about making an open source project out of it because it was so fucking easy to write.

    @cartman82 said:

    So, without a strong OSS ecosystem, if MS isn't interested, you aren't getting it.

    Even when MS is interested, sometimes you don't get it. (For example, my constant griping about the lack of DirectShow support in .NET. DirectShow has been part of Windows since like 1997. Jesus.)



  • There's major lack of actual examples in his stuff.

    I'm gonna give this a try: https://petabridge.com/bootcamp/

    I'm interested in seeing how his system works.



  • It sounds like that microservices bullshit we've talked about here before.



  • @cartman82 said:

    But how do you explain Java then? It's a thick library, but also a vibrant ecosystem surrounding it.

    .NET didn't need a thousand reinventions of date/time. So shave off half of that vibrant ecosystem.

    Other than that...

    • Oracle and billion-dollars enterprise ventures needing their AbstractFactoryDecoratorBeans
    • Cross-platforming (which MS is slowly getting right, but Java had it from the start and it probably contributed heavily to those OSS-y parts of the ecosystem)
    • Applets (hate them as much as the other guy, but they were rather popular for hobbyist stuff)
    • Seven-or-so year head start


  • @blakeyrat said:

    I mean I get what you're saying, but the basic building blocks are there to create a "reactive socket library" in like 12 lines of code. Is it any wonder nobody ever took those 12 lines and said, "hey I'm a total douchebag, I'll make an open source library out of this and be the open source hero-man!"

    Well his Helios library has like 1800 LOC, so there's obviously more to it than it seems.



  • @Maciejasjmj said:

    .NET didn't need a thousand reinventions of date/time. So shave off half of that vibrant ecosystem.

    You mean like Skeet's NodaTime?

    @Maciejasjmj said:

    Oracle and billion-dollars enterprise ventures needing their AbstractFactoryDecoratorBeans

    That's sort of Java core. OSS ecosystem is everything but that.

    @Maciejasjmj said:

    Seven-or-so year head start

    Disregarding a bunch of even younger languages that are already more vibrant than NET.



  • @cartman82 said:

    Disregarding a bunch of even younger languages that are already more vibrant than NET.

    Like. Fucking. What.



  • @cartman82 said:

    You mean like Skeet's NodaTime?

    The builtins below java 8 are all horrible.
    Date time in.. Net is acceptable, and importantly simple.

    Swing (java) is horrible. you have to create several classes to display and sort a table with data.



  • @swayde said:

    Date time in.. Net is acceptable, and importantly simple.

    My only criticism is that DateTimeOffset should be the default, and DateTime should be the weird special-case one you never use.

    Basically, rename DateTimeOffset to "DateTime" and "DateTime" to something like "LocalDateTime".



  • PowerShell



  • @blakeyrat said:

    Like. Fucking. What.

    Python. Ruby. node.js. Even fucking PHP has a more vibrant OSS ecosystem than .NET.

    @blakeyrat said:

    My only criticism is that DateTimeOffset should be the default, and DateTime should be the weird special-case one you never use.

    Basically, rename DateTimeOffset to "DateTime" and "DateTime" to something like "LocalDateTime".

    Although a DateTimeOffset value includes an offset, it is not a fully time zone-aware data structure. While an offset from UTC is one characteristic of a time zone, it does not unambiguously identify a time zone. Not only do multiple time zones share the same offset from UTC, but the offset of a single time zone changes if it observes daylight saving time. This means that, as soon as a DateTimeOffset value is disassociated from its time zone, it can no longer be unambiguously linked back to its original time zone.

    Still not perfect.



  • @blakeyrat said:

    Like. Fucking. What.

    Let's see... The number of popular .NET projects on the first page is... Oh, zero.



  • @cartman82 said:

    Python.

    @cartman82 said:

    Ruby.

    @cartman82 said:

    node.js.

    JavaScript is 1995. Node is much younger, but if JS wasn't hyped already, the hell would freeze before it took off.

    Actual "vibrant" new languages (i.e. ones you could have heard of)? Dart (current userbase of statistical error), Go (current userbase of @ben_lubar ) and Swift (which fights for userbase with ObjC, and punching retards doesn't count).



  • @cartman82 said:

    Python. Ruby. node.js. Even fucking PHP has a more vibrant OSS ecosystem than .NET.

    :moving_goal_post:

    @cartman82 said:

    Still not perfect.

    It tells you the exact time something happened. What it can not tell you is the exact time zone it happened in. Then again, neither can anything else-- unless you keep track of GPS coordinates and have a running history of time zone changes throughout history.



  • Trying to explain what Netty is:

    Netty is an asynchronous event-driven network application framework

    Tomcat for example, is not async. So with Netty you can build your own asynchronous HTTP server. There are several projects based on it: http://netty.io/wiki/related-projects.html



  • @blakeyrat said:

    REST API of any sort

    That depends... are you including JavaEE as Java?

    If so, I'm going to point out that JAX-RS is part of the JavaEE specification and an implementation of it should be shipped with any JavaEE server, even if it's the reference implementation, Jersey.

    Still, you're right about the other two.



  • @Eldelshell said:

    Tomcat for example, is not async. So with Netty you can build your own asynchronous HTTP server.

    Not even sure what that means. It sounds more like a bug in Tomcat than anything, since it's really trivial to make IIS do async stuff. (Which I assume means Discourse-like long-polling? Mostly? I have no idea, since these products are always described in vagueries.)

    .NET has native support for WebSockets, but whatever it is Netty does it doesn't seem to use WebSockets.



  • The newer class of Web Server software follow what is referred to as the event-based or the asynchronous i/o model. In this model, the Web Server uses a single (or at most a few) threads to handle incoming requests. A new thread is not started for each request but rather asynchronous input/output facilities of the underlying Operating System (OS) coupled with event-based processing multiplexes all requests onto a limited number of worker threads. The result is the ability to scale magnitude of times better than Apache while consuming very little memory and CPU.
    Quoted from: (Too lazy to disco quote on 📱)

    As usual that doesn't really represent reality, but...



  • How is that any different from using a thread pool?

    Apart from it being more complicated and probably requiring a lot more bookkeeping, that is.



  • I don't think it is, and IIS already does that so...

    Good job open source .NET guy.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    How is that any different from using a thread pool?

    It's potentially more efficient than a thread pool when your handling of the connection load is highly I/O-bound. Thread pools start to become better once you need to do more processing per connection, as the costs of minor context switching become a smaller proportion of the overall costs.

    A lot of front-end web work is indeed highly I/O-bound, as it is just serving up static files or passing connections through to back-end services. Tomcat is a web service container and is tuned for more CPU-bound load than gains from the Netty approach.


  • I survived the hour long Uno hand

    Oh, so that thing Node does where you can't make sense of what you're reading because it's a series of three-line callbacks instead of just being code.



  • ...I'm still not seeing it. Maybe because I tend to use Linux web servers, which for static files can just write the header to the socket, then use the sendfile system (read: kernel) call to send the file directly to the socket.


  • Discourse touched me in a no-no place

    @powerlord said:

    Maybe because I tend to use Linux web servers, which for static files can just write the header to the socket, then use the sendfile system call to send the file directly to the socket.

    That's because that's what a good I/O-bound service does. OTOH, moving the stuff via normal read/write calls isn't much more expensive (provided you get the buffer size right). The time is dominated by the disk I/O and the network I/O themselves; the CPU is just twiddling its thumbs (and typically can do that very power-efficiently).

    Thread based approaches win more when you need to do substantial computation to product a live result. Web applications tend to be a mix of the two, with a bunch of static content and some live results, especially when the service provided is computational, but reformatting DB query results isn't nothing either. (You could try offloading the computation to produce JSON to the DB, but SQL is a miserable language for efficient string manipulation.)



  • So I started doing a course on Akka .NET, which is a framework also maintained by this guy.

    I just got this.

    "Hey bud, do me a favor and tweet this AWFUL SHILL-LIKE COPY, mkay?"

    I mean, the course is pretty good, but really. Give it a rest with the marketing dude, you're not Patrick McKenzie.


Log in to reply