5 ms·

Awesome stuff. As a side note, anyone else see a rise in .NET/Microsoft related posts recently?

skrowl 13y ago
I'm actually GLAD to see this rise in .NET stuff. I feel like us enterprise developers are left out on [Y] sometimes. Not everyone rolls python / ruby / node / etc.
- thirsteh 13y ago
  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.
- mattgreenrocks 13y ago
  It's a shame that .NET is considered 'just' enterprise. C# is a great language, and there are several libraries with fantastic design aesthetic; one that is much better than most of Ruby/JS.
  - UK-AL 13y ago
    Most people will admit they like c# and F#. However they won't like the microsoft tax, and the fact its tied to windows.
    - deleted 13y ago
      [deleted]
    - pjmlp 13y ago
      Yep many rather pay the company X tax, but only Microsoft's tax is evil.
      - mattgreenrocks 13y ago
        Yeah, nobody seems to sweat coupling their entire codebase to Ruby on Rails. #nerdlogic
    - profquail 13y ago
      How are C# and F# tied to Windows? They run quite nicely on Mono, although I'll admit that even with the significant, recent improvements Mono has made it's still not as fast (generally) as the .NET CLR on Windows. Also -- F# is completely open-source, so there's no "Microsoft tax" to be paid. In fact, a large portion of the F# community runs exclusively on non-Windows platforms (e.g., OS X, Linux, FreeBSD, Android).
      - UK-AL 13y ago
        The languages themselves are fine. The frameworks around them on mono are always half incomplete or not the latest version. Although I have noticed its getting better lately. For example its easier to get started with F# with MVC on the Xamarin IDE then it is in VS. Hope it takes off.
- Pxtl 13y ago
  I think the big problem is that MS has a lot of catch-up to do in terms of growing a nice open-source community around the language. .NET suffers from too much "Cathedral" and not enough "Bazaar" so too many developers suffer Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. I mean, C# is a fantastic language, but a lot of the libs MS has bundled into it are absolutely horrible and people use them anyways because they're the blessed first-party product. And rather than fixing the problems, Microsoft simply creates a new replacement lib with a new approach. I mean, how many kicks at the can did they get with remoting? DB access? Serialization? Microsoft has gotten a lot better recently, taking an open-source-style development approach to Entity Framework and MVC, but they're very late to this particular party.
  - mattgreenrocks 13y ago
    This nails it. They should fund the best C# open source projects and promote them as micro replacements for existing monolithic libraries.
  - balls187 13y ago
    This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternatives: DHTML, PHP, Python, RoR, NodeJs And the language and framework has been thoughtfully improved over that period of time. > Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. Developers have been writing great software with these tools for decades. And rapidly-released libs could just as easily be classified as "not-yet-ready-for-production." > I think the big problem is that MS In my estimation, the biggest problem is that using .NET "requires" the rest of MS along for the ride. Yes you can use mono, yes you can use apache, but everything just works if you use the WINS stack. I like .NET and I really like C# as a language, but I'd rather have my infrastructure be linux. [1] Not all of these have "declined", but popularity has shifted focus.
    - Pxtl 13y ago
      I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.
sdegutis 13y ago
Yep, I've noticed more of them. For me at least, it's because I'm beginning to throw out whatever political ideologies are stopping me from being open to using whatever technologies suit my problems best. In this case, it means I'm now open to writing GUI programs for Windows (and I'm even considering using Windows as my new development platform) if it proves to be technologically more innovative and fruitful than its competitors. Same with Windows phones. And since C# with .NET happens to be the language of the platform, I've been toying with that with an open mind. I don't know if other people have the same reason.
- gum_ina_package 13y ago
  That's actually really interesting - what makes you excited about Win Phone? Is it just that the other platforms are getting stale/boring and WP is the "final frontier"?
  - sdegutis 13y ago
    From what I've seen, the UI looks more intuitive and easy to use, and all the iPhones and Androids I've tried are sluggish, so I'm holding out hope that Winphones won't be as sluggish. My contract's up in May though, so it'll be a while before I can really try it.

I'm actually GLAD to see this rise in .NET stuff. I feel like us enterprise developers are left out on [Y] sometimes. Not everyone rolls python / ruby / node / etc.

thirsteh 13y ago
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.
mattgreenrocks 13y ago
It's a shame that .NET is considered 'just' enterprise. C# is a great language, and there are several libraries with fantastic design aesthetic; one that is much better than most of Ruby/JS.
- UK-AL 13y ago
  Most people will admit they like c# and F#. However they won't like the microsoft tax, and the fact its tied to windows.
  - deleted 13y ago
    [deleted]
  - pjmlp 13y ago
    Yep many rather pay the company X tax, but only Microsoft's tax is evil.
    - mattgreenrocks 13y ago
      Yeah, nobody seems to sweat coupling their entire codebase to Ruby on Rails. #nerdlogic
  - profquail 13y ago
    How are C# and F# tied to Windows? They run quite nicely on Mono, although I'll admit that even with the significant, recent improvements Mono has made it's still not as fast (generally) as the .NET CLR on Windows. Also -- F# is completely open-source, so there's no "Microsoft tax" to be paid. In fact, a large portion of the F# community runs exclusively on non-Windows platforms (e.g., OS X, Linux, FreeBSD, Android).
    - UK-AL 13y ago
      The languages themselves are fine. The frameworks around them on mono are always half incomplete or not the latest version. Although I have noticed its getting better lately. For example its easier to get started with F# with MVC on the Xamarin IDE then it is in VS. Hope it takes off.
Pxtl 13y ago
I think the big problem is that MS has a lot of catch-up to do in terms of growing a nice open-source community around the language. .NET suffers from too much "Cathedral" and not enough "Bazaar" so too many developers suffer Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. I mean, C# is a fantastic language, but a lot of the libs MS has bundled into it are absolutely horrible and people use them anyways because they're the blessed first-party product. And rather than fixing the problems, Microsoft simply creates a new replacement lib with a new approach. I mean, how many kicks at the can did they get with remoting? DB access? Serialization? Microsoft has gotten a lot better recently, taking an open-source-style development approach to Entity Framework and MVC, but they're very late to this particular party.
- mattgreenrocks 13y ago
  This nails it. They should fund the best C# open source projects and promote them as micro replacements for existing monolithic libraries.
- balls187 13y ago
  This isn't a very fair criticism. .NET has been around for a long time, long enough to have gone through the rise an decline[1] of many open source alternatives: DHTML, PHP, Python, RoR, NodeJs And the language and framework has been thoughtfully improved over that period of time. > Microsoft's bloated and broken enterprise tools instead of sensible, rapidly-released libs. Developers have been writing great software with these tools for decades. And rapidly-released libs could just as easily be classified as "not-yet-ready-for-production." > I think the big problem is that MS In my estimation, the biggest problem is that using .NET "requires" the rest of MS along for the ride. Yes you can use mono, yes you can use apache, but everything just works if you use the WINS stack. I like .NET and I really like C# as a language, but I'd rather have my infrastructure be linux. [1] Not all of these have "declined", but popularity has shifted focus.
  - Pxtl 13y ago
    I've been using the MS stack since '05. I didn't say it wasn't ready for prime-time. Just that MS, like any other team, makes missteps - their libraries tend to be a bit overcomplicated and messy, but understandably so since they try to be all things to all people. Sometimes they hit on the wrong design. But where other libraries would have to compete in the open market-place of ideas, Microsoft's failures are still "blessed" by MS and so we still use them. But the bigger frustration is that they don't seem to really properly iterate on the libraries. They get fired out as part of a .NET major version release and get at most minimal bug-fixes beyond that. If there's a major flaw in the lib, it will not get fixed. Instead, a completely new library with its own flaws and a whole new learning curve will appear, and the old lib will remain and languish in its "functional but still fundamentally frustrating" state. Like I said, I'm ecstatic to see that MS has moved away from this methodology with Entity Framework - they've de-coupled it from the .NET core and are iterating on it faster than Once Every Major Language Release.

sdegutis 13y ago

Yep, I've noticed more of them. For me at least, it's because I'm beginning to throw out whatever political ideologies are stopping me from being open to using whatever technologies suit my problems best. In this case, it means I'm now open to writing GUI programs for Windows (and I'm even considering using Windows as my new development platform) if it proves to be technologically more innovative and fruitful than its competitors. Same with Windows phones. And since C# with .NET happens to be the language of the platform, I've been toying with that with an open mind. I don't know if other people have the same reason.

gum_ina_package 13y ago
That's actually really interesting - what makes you excited about Win Phone? Is it just that the other platforms are getting stale/boring and WP is the "final frontier"?
- sdegutis 13y ago
  From what I've seen, the UI looks more intuitive and easy to use, and all the iPhones and Androids I've tried are sluggish, so I'm holding out hope that Winphones won't be as sluggish. My contract's up in May though, so it'll be a while before I can really try it.