7 ms·

It’s not, not really, but it runs a lot of enterprise and reschooling developers is really expensive. I know, because we’re in the process of going from almost

It’s not, not really, but it runs a lot of enterprise and reschooling developers is really expensive. I know, because we’re in the process of going from almost exclusively c# to mostly node.js and powershell scripts with orchestra and SSIS. The fact that Microsoft keeps doing things like core 1, the 2, xamarin and now this web assembly stuff made the business case for changing better though. Because staying up to date on c# has also become expensive. Still, stuff like AD and ADFS, msSQL and windows servers are the backbone in a lot of enterprise, and C# integrates really easily in that environment. I still think node.js, powershell and SSIS does it better, but I can certainly see why c# is still a thing.

Rapzid 8y ago
I mean.. I really like TypeScript and nodejs as an every language that I can use and promote without too much push back but "Does it better" isn't a qualifier that comes to mind. Sure I can come up with specific areas that I enjoy more about nodejs/TypeScript, but I can also come up with just as many for C#/.Net: * Async/Await implementation is pretty much superior * Real threading; great for task pools as well * Task local storage; something the nodejs community is very interested in but thus far only lives in hacks on obscure run-time features * Speed? * Integers?; come on man * Linq/Entity Framework(though these should mostly be possible to implement in TypeScript now) If I had my druthers I'd be using F# though, TBH.
- eksemplar 8y ago
  I don’t think C# has superior async functionality, it used to, and certainly had for a long time, but not today. Threading and tasks add unnecessary complexity. Speed? What speed, this web assembly example is more than 5mb of .net libraries. We make apps for people on less than 3g. Entity is one of the worst, least productive and most error prone frameworks we’ve ever had in our stack. Especially code first. Linq almost made us stick with C# forever.
  - tluyben2 8y ago
    > Entity is one of the worst, least productive I think that hits the nail on the head; I never got why anyone used that. We never did and we have been using c# for a long time (all over to Core now) and all the horror stories never applied to our work, I think, because we never touched entity.
    - Rapzid 8y ago
      That's... Odd. I have used a LOT of different ORMs and nothing else came even close to the experience of Entity Framework with its fantastic type inference and Linq integration. Bring your contexts into linqpad and you have one of the most transparent and streamlined ORM development sessions I could possible imagine. This was all with 6 though(IIRC) and code first; not with Entity Framework Core. There were certainly a couple gotcha's and quirks to get used to, particularly around initial modeling, but the unit of work pattern made possible with task local storage was spot on.
  - manigandham 8y ago
    Webassembly is a brand new runtime, it has nothing to do with C#. Blazor is alpha stage and hasn't even finished designing functionality yet. C# on the server running on .NET Core is one of the fastest web stacks, and the async and threading help greatly with that. You can keep everything synchronous if you want, but it's good to have the flexibility when needed. How is EF unproductive? What options are better?
    - eksemplar 8y ago
      .Net core isn’t faster in a way that’s relevant to us. You have to keep in mind that being productive is what’s important when your primary focus is supporting the business. Whether we gain a little efficiency or not from core is relatively irrelevant if it takes longer to produce the solutions. We’re not Netflix, our max load is 60.000 concurrent users, and that’s relatively rare. What isn’t rare, is someone loading an app in a remote area, where the mobile coverage is terrible, and if it had to load .net libraries in that setting, they’d frankly never be able to do their jobs. So the speed of .net core is irrelevant to us, and to most people really, I mean, Netflix runs on node. If you don’t know why EF is terrible, I’d wager you’d never used it. We use LinqToSql in our C# apps. Why? Because it’s productive, and again, it may be slower than entity, but it’s slower in a way that really doesn’t matter to us. I mean, the video highlights it so perfectly when the guy goes “look how fast it compiles”, as if that’s ever useful when your application takes much longer to load for the user.
manigandham 8y ago
Javascript still doesn't have 64-bit numbers or real multithreading or serious async or proper namespaces and modules. C# the language is also not the same as the .NET runtime and framework, but Microsoft is the best organization in the world when it comes to backwards compatibility and the C# code you wrote a decade ago will still work flawlessly today. I don't understand how you're switching to Node.js and shell scripts(?!) to take over all that functionality.
- eksemplar 8y ago
  Node.js is better at web apps, and for us it’s been much faster to get stuff out too. The ability to quickly prototype is instrumental when you’re doing service design, and node excels at that. SSIS is better at moving data. Powershell has come really far, it’s certainly not C#, but where it really excels is when it’s integrated into our Azure orchestra giving us faster error reporting and making us capable of addressing those errors quicker. It’s also a language that’s shared between developing and operations. So while C# is better technically, powershell is better organizational and that means it’s better. Simply put C# has become an unnecessary burden, in our setup. I’m not sure I’d use node for huge projects, but our backends are mostly simple frameworks for manipulating relatively small amounts of data. We’re not leaving .Net or Microsoft, our node server runs behind an IIS with IIS node. SSIS, powershell and Azure are obviously Microsoft. Our entire security model is based around AD and ADFS.

Rapzid 8y ago

I mean.. I really like TypeScript and nodejs as an every language that I can use and promote without too much push back but "Does it better" isn't a qualifier that comes to mind. Sure I can come up with specific areas that I enjoy more about nodejs/TypeScript, but I can also come up with just as many for C#/.Net: * Async/Await implementation is pretty much superior * Real threading; great for task pools as well * Task local storage; something the nodejs community is very interested in but thus far only lives in hacks on obscure run-time features * Speed? * Integers?; come on man * Linq/Entity Framework(though these should mostly be possible to implement in TypeScript now) If I had my druthers I'd be using F# though, TBH.

eksemplar 8y ago
I don’t think C# has superior async functionality, it used to, and certainly had for a long time, but not today. Threading and tasks add unnecessary complexity. Speed? What speed, this web assembly example is more than 5mb of .net libraries. We make apps for people on less than 3g. Entity is one of the worst, least productive and most error prone frameworks we’ve ever had in our stack. Especially code first. Linq almost made us stick with C# forever.
- tluyben2 8y ago
  > Entity is one of the worst, least productive I think that hits the nail on the head; I never got why anyone used that. We never did and we have been using c# for a long time (all over to Core now) and all the horror stories never applied to our work, I think, because we never touched entity.
  - Rapzid 8y ago
    That's... Odd. I have used a LOT of different ORMs and nothing else came even close to the experience of Entity Framework with its fantastic type inference and Linq integration. Bring your contexts into linqpad and you have one of the most transparent and streamlined ORM development sessions I could possible imagine. This was all with 6 though(IIRC) and code first; not with Entity Framework Core. There were certainly a couple gotcha's and quirks to get used to, particularly around initial modeling, but the unit of work pattern made possible with task local storage was spot on.
- manigandham 8y ago
  Webassembly is a brand new runtime, it has nothing to do with C#. Blazor is alpha stage and hasn't even finished designing functionality yet. C# on the server running on .NET Core is one of the fastest web stacks, and the async and threading help greatly with that. You can keep everything synchronous if you want, but it's good to have the flexibility when needed. How is EF unproductive? What options are better?
  - eksemplar 8y ago
    .Net core isn’t faster in a way that’s relevant to us. You have to keep in mind that being productive is what’s important when your primary focus is supporting the business. Whether we gain a little efficiency or not from core is relatively irrelevant if it takes longer to produce the solutions. We’re not Netflix, our max load is 60.000 concurrent users, and that’s relatively rare. What isn’t rare, is someone loading an app in a remote area, where the mobile coverage is terrible, and if it had to load .net libraries in that setting, they’d frankly never be able to do their jobs. So the speed of .net core is irrelevant to us, and to most people really, I mean, Netflix runs on node. If you don’t know why EF is terrible, I’d wager you’d never used it. We use LinqToSql in our C# apps. Why? Because it’s productive, and again, it may be slower than entity, but it’s slower in a way that really doesn’t matter to us. I mean, the video highlights it so perfectly when the guy goes “look how fast it compiles”, as if that’s ever useful when your application takes much longer to load for the user.

manigandham 8y ago

Javascript still doesn't have 64-bit numbers or real multithreading or serious async or proper namespaces and modules. C# the language is also not the same as the .NET runtime and framework, but Microsoft is the best organization in the world when it comes to backwards compatibility and the C# code you wrote a decade ago will still work flawlessly today. I don't understand how you're switching to Node.js and shell scripts(?!) to take over all that functionality.

eksemplar 8y ago
Node.js is better at web apps, and for us it’s been much faster to get stuff out too. The ability to quickly prototype is instrumental when you’re doing service design, and node excels at that. SSIS is better at moving data. Powershell has come really far, it’s certainly not C#, but where it really excels is when it’s integrated into our Azure orchestra giving us faster error reporting and making us capable of addressing those errors quicker. It’s also a language that’s shared between developing and operations. So while C# is better technically, powershell is better organizational and that means it’s better. Simply put C# has become an unnecessary burden, in our setup. I’m not sure I’d use node for huge projects, but our backends are mostly simple frameworks for manipulating relatively small amounts of data. We’re not leaving .Net or Microsoft, our node server runs behind an IIS with IIS node. SSIS, powershell and Azure are obviously Microsoft. Our entire security model is based around AD and ADFS.