601–605 of 605 posts
Earlier quoted context omitted.
The majority of software is probably Excel macros.
This probably isn't true but I want to read a super geeky dark sci-fi novel that explores this topic.
Earlier quoted context omitted.
This probably isn't true but I want to read a super geeky dark sci-fi novel that explores this topic.
It's not obvious to me that it isn't true. The number of excel spreadsheets world-wide probably vastly outnumbers the number of software projects.
Earlier quoted context omitted.
Blazor will produce super bloated web apps. I can see it being used for an in-house thing with captive users but for a real world product or a public app? It would be a terrible choice. Also the DX is just not there. Hot reload is a mess. Even when it works it's too slow. Once you start using hot reload with Vite you can't go back to waiting seconds for every change and full page reloads. > Compared to what? Everythi…
>Do you think it's acceptable that it took 4 years for Minimal APIs to get validation? Well thay don't call it Minimal API for nothing. Jokes aside, what stopped you from calling validation yourself explicitly? >What about hot reload being broken for years and years? Can't comment on this, because I have never needed it. I can work faster with writing tests, but I guess it's fair to assume there are some who would ne…
Error messages. Even with the validation in .NET 10 you can't get the actual JSON property to display in the error message, instead you get the C# property.
FastEndpoints fixes this but uses Fluent so now you need to rely on a couple more dependencies.
> I can work faster with writing tests
For Blazor and Razor?
Earlier quoted context omitted.
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
Earlier quoted context omitted.
EF hits you in the face right at the start with the massive convenience that it provides. And then the paper cuts start adding up, and adding up, and adding up. Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
What papercuts?
Fluent syntax can at first seem like the product has achieved persistence ignorance nirvana but then you have to compromise a little here, compromise a little there, until some point, if you’re still thinking critically about the design, you realize that you’re writing your app in Entity Framework as much as you are writing it in C#, as I mentioned.
Passing around a large mutable blob (dbcontext) which, if not managed with the utmost discipline by your dev team, can make it necessary to understand what large swaths of the code do before you can adequately understand what any small part of the code does.