4 ms·

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 t

by 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
      Sure, use whatever is more productive on the server-side, although in my experience the strong-typing and full classes and namespacing make it much easier than JS. I don't get the comparison on the client-side with webassembly though. This is an entire UI framework, and hasn't been fully designed and optimized yet, as stated. It's no different than using React and neither would be good options if optimizing for low-bandwidth remote areas. I've used EF since it was first released, and we haven't encountered any major issues. We migrated from nhibernate a long time ago and fallback to Dapper occasionally for complex SQL and performance. What do use instead? Or is the argument to not use ORMs at all?
- cm2187 8y ago
  They have some projects to reduce the binary size (it is still an alpha project), like doing tree shaking. JavaScript isn’t light either, if you look at the amount of stuff a major website loads.
  - eksemplar 8y ago
    I don’t, I look at what we load.
- codenesium 8y ago
  I'm curious what issues you had with entity framework?

by Rapzid 8y ago

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
    Sure, use whatever is more productive on the server-side, although in my experience the strong-typing and full classes and namespacing make it much easier than JS. I don't get the comparison on the client-side with webassembly though. This is an entire UI framework, and hasn't been fully designed and optimized yet, as stated. It's no different than using React and neither would be good options if optimizing for low-bandwidth remote areas. I've used EF since it was first released, and we haven't encountered any major issues. We migrated from nhibernate a long time ago and fallback to Dapper occasionally for complex SQL and performance. What do use instead? Or is the argument to not use ORMs at all?
cm2187 8y ago
They have some projects to reduce the binary size (it is still an alpha project), like doing tree shaking. JavaScript isn’t light either, if you look at the amount of stuff a major website loads.
- eksemplar 8y ago
  I don’t, I look at what we load.
codenesium 8y ago
I'm curious what issues you had with entity framework?