An award for being one of MS's best pimpers just doesn't hold the same level of street cred.
Now whenever I see someone wearing an MVP badge in their twitter bio I immediately discredit their pro-MS "advice" as an MVP shill wanting to score points towards their next renewal.
But really, if the MVP program was what it is said to be, people like you'd be in it.
ServiceStack has been a valuable contribution to the .NET community, and your continued development/support of it should defacto make you an MVP.
> ServiceStack has been a valuable contribution to the .NET community, and your continued development/support of it should defacto make you an MVP.
Yes, and back in the days when I received my MVP title, this kind of thinking was part of the criteria. Nowadays... no way. It started 7-8 years ago I think when they decided there couldn't be more than X mvp's for a given category and they wanted at least Y mvp's in a given region. So less in the west, and more in say India. While it's fine to make it a more world-wide program and recognize people in communities which are less known to people in 'the west', the criteria to accomplish this changed with it: if you started a user group somewhere in a region without an mvp and someone nominated you, you had a good chance becoming one.
This is all OK btw, if your criteria is about evangelizing. If your criteria is about 'the people who are the most skilled in ABC' then it's not. So this shift in who would receive the award changed the program.
Nowadays it's rather silly tbh. If you want to get renewed you have to fill in a form where you describe why you want to get renewed. wtf... it's an award you receive. Why would you need to tell MS why you'd want to receive an award you haven't received yet as they decide who gets it...
It's one of the marketing tools used to self-reinforce .NET's mono culture - which I view as the worst thing about .NET.
It stopped being anything remotely to do with technical merit or being an "MVP" years ago. I'd prefer to see the program abolished, then maybe we'll start seeing more tech diversity in .NET.
People have arguments in JVM-land about why you should use X web framework or Y SQL/ORM library or Z foobaz. Too often in the .Net world I see complete dismissal of everything but ASP.Net MVC, EF+MSSQL, etc. Oh, and of course you should use Azure for everything.
I freaking love F#, and to a lesser extent C# - but I can’t stand .NET as a whole because of this.
98% of projects can be accomplished just as well with react or Angular, typescript or Vue, mysql or sql server, hibernate or EF, asp.net mvc or Nancy, c# or f#, git or tfs, Asana or VSTS. These decisions don't matter nearly as much as the expertise of the team. So it's nice to be able to field or join a team of experts on every part of the stack and focus on solving problems with technology and not the technology.
I do think I understand your point - there is comfort in knowing there is one default solution for almost every abstraction. But how much can you love it when each one tends to be mediocre?
Disclosure: I spent 10 years working on .NET from 2006 to 2016 , so I've missed the last revolution of .NET Core, so maybe things got better?
Not sure what you worked on but .NET has gotten better since 2016 but not by leaps and bounds(exception EF Core is leaps and bounds better than the prev. version). I've always thought asp.net mvc was good, newest one is better but not by a huge margin. Original EF was bad but EF Core is far better. TFS was mediocre but now everyone uses git. Typescript is absolutely delightful. Xamarin's kind of painful but all cross platform mobile development seems to be. Visual Studio is probably best in class of the heavy duty IDE's. I've heard complaints about nuget but it always seems reliable which is more than I can say about npm. The work item tracking kind of sucks but it makes up for it with streamlined integration from the IDE->commit->task tracking->time tracking->reporting->invoicing.
The part of the stack that always bothered me were the poorly designed DevExpress/Infragistics controls that were ubiquitous. They get weird impossible to debug errors. They seem to trade extensibility for endless amounts of configuration. But with modern .NET applications you don't see them anymore which has brought me great joy.
[0] - One time upper management forced all of the devs in the organization to use a high performance real time database that fell down with 200 points/minute. And would sometimes(monthly) crash so hard both the data and the installation and sometimes the vm were unrecoverable. It took 3 days to install and we required one full time person on a team of 5 whose full time job(she was working 60 hr weeks) was just to keep 3 instances running(Dev/test/stage).
Even Google if they wanted to actually get away with their little action, could have taken the opportunity to own Java.
Kafka, Hadoop, Flink, Ant, Maven, Impala, Parquet, Avro, Spark...
It was mostly JEE or Spring, Swing or SWT, Ant or Maven, .... everything else tends to be loved in online forums but hardly seen live across the globe.
Stack Overflow recent survey results are yet another proof of it, every JVM language that is going to "replace" Java is stuck in single digit percentage.
Don't confuse your corporate monoculture for a monoculture of an entire ecosystem.
> It was mostly JEE or Spring, Swing or SWT, Ant or Maven, .... everything else tends to be loved in online forums but hardly seen live across the globe.
Yeah, big frameworks are still popular, nothing surprising about that. Thing is, these big frameworks are usually designed to be modular out of the box - if you don't like a certain component don't use it and pull in something else. No need to throw the baby out with the bathwater, and there is plenty of choice for individual parts of your stack without nixing Spring Framework or CDI. Hell, even if you do you have micro-frameworks like Dropwizard that are just various components welded together because the ecosystem makes doing it fairly easy.
> Stack Overflow recent survey results are yet another proof of it, every JVM language that is going to "replace" Java is stuck in single digit percentage.
And? Nothing "needs" to replace the language, though nothing until Kotlin has ever been in a position to even be a #2. Scala can't stop breaking compatibility every release, nobody ever heard of Ceylon, Groovy & Clojure don't fit the same statically-typed niche. All of these work though, and they all can share code with each other so it doesn't have to be a zero-sum game either.
I think this is a really important thing about JVM langauges. They can exist successfully at much lower thresholds of popularity because they piggy back on Java. So I don't have to worry about Groovy dying off (which is not to say it is) - because basically as long as Java is around it is going to have access to a giant community of developers. So using Groovy or Clojure or Scala etc is a much lower risk proposition than jumping in the deep end with a stand alone language. In that sense, Groovy / Clojure / Scala / Kotlin don't really compete with each other or Java as much as help each other, and Java's popularity is really the sum of all of them.
Apache Groovy is dying off. Whenever some software product bundles it as a built-in scripting language, after a short time Groovy's snags become apparent and that software starts bundling another scripting solution, e.g. Kotlin for build scripts in Gradle [1], or the Declarative Pipeline Syntax for Jenkins [2].
[1] https://docs.gradle.org/5.0/userguide/kotlin_dsl.html
[2] https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta...
There is rarely a case to use EF.
For example, you'll quickly realize you need to have ```AsNoTracking``` on your queries because the performance is terrible.
You'll also find that you can batch update/delete items.
I've also had problems with migrations after updating EF Core (don't remember exactly).
You can get spun up quickly, with Linq, using something like Dapper or ServiceStack.OrmLite. They work on raw ADO.NET, so they are incredibly easy to reason/work with. The errors that you'd run into wont be shrouded in layers/abstractions that are specific to EF/Core.
But I also think that heavier duty ORMs have their place. Recent circumstances have meant that I'm building out a lot of applications from start to finish in one to three weeks. These applications deal with very little data, the largest tables are in the 1000's of records and in circumstances like that I need crank developer productivity to 11 and for that I'm willing to sacrifice performance and simplicity. And for that EF has been a great companion.
I've also used a combination of EF and DACPAC. Where I used DACPAC to manage the schema and migrations and used EF for CRUD and that's been a pretty great combo. And I definitely have to drop down to sql, especially for reporting/analysis type queries.
My default is to just use ADO.NET with Dapper or ServiceStack.OrmLite.