4 ms·

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

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?
    - eksemplar 8y ago
      GraphQL is strongly typed though, and you can always use typescript, I wouldn’t personally advice it unless it works for you. We’ve not really seen any real trouble moving to dynamic types, possibly because we utilize stuff like SOLID. When you’re not really using object oriented to its fullest, because it’s fullest adds complexity and complexity costs a lot of money and you’re already pretty fascist in your approach to how responsibility and changes are handled in your systems, dynamic types aren’t really a problem. If I was building a huge system with a lot of complexity, I wouldn’t pick JavaScript, but I probably wouldn’t chose C# instead of JAVA either. And that’s not the way I would’ve viewed the world 5 years ago. Anyway, I think people should use what works, I just think C# has lost its usefulness compared to other technologies and I really think web assembly is s terrible move for Microsoft. But I’d love to be proven wrong.
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?

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?
  - eksemplar 8y ago
    GraphQL is strongly typed though, and you can always use typescript, I wouldn’t personally advice it unless it works for you. We’ve not really seen any real trouble moving to dynamic types, possibly because we utilize stuff like SOLID. When you’re not really using object oriented to its fullest, because it’s fullest adds complexity and complexity costs a lot of money and you’re already pretty fascist in your approach to how responsibility and changes are handled in your systems, dynamic types aren’t really a problem. If I was building a huge system with a lot of complexity, I wouldn’t pick JavaScript, but I probably wouldn’t chose C# instead of JAVA either. And that’s not the way I would’ve viewed the world 5 years ago. Anyway, I think people should use what works, I just think C# has lost its usefulness compared to other technologies and I really think web assembly is s terrible move for Microsoft. But I’d love to be proven wrong.

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?