5 ms·

I will take .NET posts over Node.js ones any day of the week. I feel like I am taking crazy pills whenever somebody celebrates discovering "async performance" i

I will take .NET posts over Node.js ones any day of the week. I feel like I am taking crazy pills whenever somebody celebrates discovering "async performance" in Node.js.

skrowl 13y ago
A Node.js post here is how I discovered the excellent http://nancyfx.org http://nancyfx.org framework, but I agree that the node.js performance benefits are overblown quite a bit.
gum_ina_package 13y ago
Well in .NET, C# especially, asynchronous programming is a first class citizen.
- thesz 13y ago
  Not as much as in Haskell and/or Erlang.
  - bunderbunder 13y ago
    Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.
    - thesz 13y ago
      I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
      - thirsteh 13y ago
        I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
        thesz 13y ago
        We are talking not only about I/O. We are talking about async stuff in general. Lazy evaluation, combined with par/pseq functions and concurrency, is essentially asynchronous computation. You fire the computation, you take result later if you need it at all.
- corresation 13y ago
  Few C# developers actually use asynchronous rudiments, and instead the overwhelming bulk of code is of the classic stop and wait variety (I've developed in .NET, among other platform, from its beginnings). thirsteh's cynicism is misplaced. node.js is effectively predicated on asynchronous implementations, and you have to work hard to do otherwise. The end result tends to be very efficient implementations that can serve large numbers with ease. .NET bolted on asynchronous sugar as it matured, and while that is very good, and you can make efficient implementations, most don't. So it's not really reasonable to dismiss the talk about one because it's possible in another. EDIT: thirsteh is continually editing their posts so assume their commentary is very different from what it originally was.
  - thirsteh 13y ago
    I'll wager that you haven't written much Erlang, Go, Haskell, or any other language with transparently asynchronous I/O but blocking semantics. If you have, I don't understand how you can believe my cynicism is misplaced. Despite what you seem to imply in your comment, I/O does not block an entire thread in any of these languages, however the control flow in a single thread does block, i.e. err = fireTheRockets() does block until fireTheRockets completes, but performance-wise it is equivalent to fireTheRockets(function(err) { ... }). Only now you're saved the callback spaghetti. Node.js advocates are literally peddling callback spaghetti as an advantage because "it lets you write much faster applications with ease", yet Haskell's threads and blocking semantics blow any Node.js out of the water by an order of magnitude. (Check out Mighttp/Warp or Go's net/http vs. Node.js.) I come across as cynical because that is sad. It feels like we're travelling back in time, not forward. The only thing that makes node.js "good" when it comes to threading and async is that it doesn't require synchronization as there is no concurrency. (Same thing for Python with Twisted.) Neverminding that that opens up its own can of worms (I hope you don't do any actual computation in your program, as that's going to block everything): Pretending that it's anything more than that comes across as incredibly ignorant of contemporary language design.
    - corresation 13y ago
      I'll wager... And you would lose. This conversation was about .NET, and then you (rather oddly) decided to pull in nodejs. It has nothing, at all, to do with Erlang, Go, Haskell, or any other language, and the tactic of using them as the "big brother" to discount another language is petty and disingenuous.

I will take .NET posts over Node.js ones any day of the week. I feel like I am taking crazy pills whenever somebody celebrates discovering "async performance" in Node.js.

skrowl 13y ago

A Node.js post here is how I discovered the excellent http://nancyfx.org http://nancyfx.org framework, but I agree that the node.js performance benefits are overblown quite a bit.

gum_ina_package 13y ago

Well in .NET, C# especially, asynchronous programming is a first class citizen.

thesz 13y ago
Not as much as in Haskell and/or Erlang.
- bunderbunder 13y ago
  Perhaps, perhaps not. My impression has been that of late the top-tier .NET langauges have better support for asynchronous programming when considered from a pragmatic perspective, because a lot more care has been spent on designing the relevant APIs and language features to be accessible and easy to learn. Async/await really is a great abstraction on top of task parallelism; it's easy to understand without having to wade through a zillion blog posts explaining how it's just like burritos, Lego blocks, the OSI model, or homeobox genes, or underpants. Which means that it's something you could actually get away with using in enterprise software development, rather than something that'll earn you a reputation for developing software that your colleagues wouldn't be able to maintain.
  - thesz 13y ago
    I don't know. I still struggle to use async/await for, for example, async reading from file. It is not that easy, actually. I have to disagree to you also on the ground that almost everything in Haskell is (and many important things in Erlang are) async without any annotations. Haskell is lazy and that alone makes many operations "asynchronous", so to say. It's run-time system is heavily threaded and employs work stealing to fit millions of green threads into several system threads. You can write your own scheduler [1] for your purposes, if you please. As fine grained as you want it to. [1] http://hackage.haskell.org/package/meta-par http://hackage.haskell.org/package/meta-par In fact, .Net is years behind of Haskell and Erlang. Just because it borrows features from Haskell (and other languages) libraries and bolts them into language. The difference here is that things in libraries are first-class, you can create them at run-time. That does not often apply to language constructs.
    - thirsteh 13y ago
      I'm just being pedantic, but the asynchronous I/O of Haskell isn't really associated with laziness, although it does have lazy I/O (which often is a bad idea.) Go essentially does all the same things (all I/O is asynchronous under the hood using epoll, kqueue, etc.) without being lazy.
      - thesz 13y ago
        We are talking not only about I/O. We are talking about async stuff in general. Lazy evaluation, combined with par/pseq functions and concurrency, is essentially asynchronous computation. You fire the computation, you take result later if you need it at all.
corresation 13y ago
Few C# developers actually use asynchronous rudiments, and instead the overwhelming bulk of code is of the classic stop and wait variety (I've developed in .NET, among other platform, from its beginnings). thirsteh's cynicism is misplaced. node.js is effectively predicated on asynchronous implementations, and you have to work hard to do otherwise. The end result tends to be very efficient implementations that can serve large numbers with ease. .NET bolted on asynchronous sugar as it matured, and while that is very good, and you can make efficient implementations, most don't. So it's not really reasonable to dismiss the talk about one because it's possible in another. EDIT: thirsteh is continually editing their posts so assume their commentary is very different from what it originally was.
- thirsteh 13y ago
  I'll wager that you haven't written much Erlang, Go, Haskell, or any other language with transparently asynchronous I/O but blocking semantics. If you have, I don't understand how you can believe my cynicism is misplaced. Despite what you seem to imply in your comment, I/O does not block an entire thread in any of these languages, however the control flow in a single thread does block, i.e. err = fireTheRockets() does block until fireTheRockets completes, but performance-wise it is equivalent to fireTheRockets(function(err) { ... }). Only now you're saved the callback spaghetti. Node.js advocates are literally peddling callback spaghetti as an advantage because "it lets you write much faster applications with ease", yet Haskell's threads and blocking semantics blow any Node.js out of the water by an order of magnitude. (Check out Mighttp/Warp or Go's net/http vs. Node.js.) I come across as cynical because that is sad. It feels like we're travelling back in time, not forward. The only thing that makes node.js "good" when it comes to threading and async is that it doesn't require synchronization as there is no concurrency. (Same thing for Python with Twisted.) Neverminding that that opens up its own can of worms (I hope you don't do any actual computation in your program, as that's going to block everything): Pretending that it's anything more than that comes across as incredibly ignorant of contemporary language design.
  - corresation 13y ago
    I'll wager... And you would lose. This conversation was about .NET, and then you (rather oddly) decided to pull in nodejs. It has nothing, at all, to do with Erlang, Go, Haskell, or any other language, and the tactic of using them as the "big brother" to discount another language is petty and disingenuous.