30 ms·

I started a project that I hope to maybe turn into a product (foss/community edition hybrid approach). One of the tech stacks I evaluated was mono-based, using

by trangus_1985 5y ago

I started a project that I hope to maybe turn into a product (foss/community edition hybrid approach). One of the tech stacks I evaluated was mono-based, using c# and the .net libraries. I ended up turning down that choice due to a couple of factors, but one of them was the glacial pace of .net process and development. It just didn't look or feel like a healthy ecosystem, if you weren't paying microsoft $$$$. Just a ton of small warning flags around the community, the stack, and the maintenance of core projects. C#, .NET, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with. I actually have a concrete example of this: one of the features of my project is that you can define yaml based configuration documents, and share them. Using something that was easy to write for small but coherent configurations was crucial - XML was right out. The .NET ecosystem's yaml support is not great, feels kinda janky, and yaml validation is a paid product! That's completely untenable for something that's still in the weekend work phase. And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid. Not to mention that the built in build system was horrific, confusing, and had weak documentation. It's probably a lot easier when you just write a check to a contractor to set up a template for your team, but I have no luxury. Sure, some of this is on me, but I wanted to get started building and the .net ecosystem repeatedly got in my way until I was forced to give up. So, upon hearing that the .net foundation is spending all of its time generating stacks of bureaucracy and causing internal drama, I feel like I made the right choice. At this point, it's unlikely I re-evaluate .net for future projects unless I hear massively good things (like what happened with java, which took a decade).

heavyset_go 5y ago
> And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid. What are some of those things?
- trangus_1985 5y ago
  it's been about a year but it was a death by a thousand papercuts kinda thing. I want to add that I was not an experienced python developer at the time - I'd used it for a handful of simple automation scripts. My day job was writing scala. - targeting mono under nginx on linux, from within windows was really difficult, I could never quite get it to work - no support for monodevelop on windows - cross platform was crucial to me and it just got so onerous. And maybe it's just me, but I was really hitting a lot of frustration with visual studio. - i wanted to use both yamlschema (broken at the time) and jsonschema (paid) - msbuild is abysmal with useless error messages. I struggled to run a simple shell script during the build process. - a couple of libraries I tried were broken or unmaintained. The .net ecosystem seems to have very low quality of community maintained tools. - no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look) - ... and that's all I can remember. There was more. I fully acknowledge that some, if not all, of those complaints may be self-inflicted. I can't say that, for my first complicated project in python, it's been completely smooth sailing. However, with python/falcon, it didn't feel like I was fighting with the ecosystem to define a package, import the package into a microservice codebase, and then get the service running with full test coverage. It didn't feel like I was fighting to bring a third party library in, verify it's actively being maintained, and start using it. I spent as much time getting a simple microservice hello world with authz/authn validation and a reasonable packaging system, in python, set up in about time as it took me to give up on msbuild. I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net.
  - Hawxy 5y ago
    I think the only time I've found people this far off the main track is users that only know C#/mono coming from Unity Engine. > targeting mono under nginx on linux...no support for monodevelop on windows Because you should have never been anywhere near mono. Even a year ago, if you followed the main .NET documentation it would have directed you to install the .NET 3.1 or 5 SDK on to your linux environment and get setup with VSCode. It's the first step in the hello world tutorial: https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install https://dotnet.microsoft.com/learn/dotnet/hello-world-tutori... > no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look) Dapr is not a Microsoft product. Microsoft does not offer commercial support for it. There's docs for the .NET library on the Dapr website, along with various community support channels available. > I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net. Bootstrapping a worker service or ASP.NET Core on windows is either a few clicks in VS, or a one line command via the dotnet CLI.
sumnole 5y ago
the .net ecosystem is somewhat pay to win - its like the apple store of the devtool world, clients are actually willing to pay. if your company has the funds, you have access to some of the best tools in development, but you can get pretty far with its free options too. C# is quite a nice language to work with. historically projects were very enterprisey oop monsters but cleaner functional paradigms are trending in the .net space.
- trangus_1985 5y ago
  Yes, I quite like C#, the language. That's why I put so much effort into trying to make it work - it's become one of my favorite languages!
- hvidgaard 5y ago
  You can absolutely write in a functional style. It does not have to be the enterprise OOP monsters of the past. Apart from something radical such as adapting a Hindley-Milner type system, I'm not sure it can support functions much better than it already is. I think most people simple oppose to the idea of a static type system, and my experience is that static type checking is an absolute time saver in the long run for large long lived. Significantly.
- ahepp 5y ago
  I'd love to hear more about the top tier paid tools. I haven't really experienced that before.
  - to11mtm 5y ago
    Closest I can think of is the days of yore where .NET Component licensing was a thing that was encountered frequently enough it was mentioned more prominently in books. This was useful for a lot of 3rd party developers that wanted to provide either tooling or runtime libraries to IT Shops. UI Toolkits and other 'specialized' libraries would use this mechanism as a way to keep some level of IP Protection. I ran into this scheme in the wild with Devart's DotConnect for Oracle; at the time it was worlds better than the free 1st party providers, and came with some interesting T4 templates for generating models for either EF or their special adaptation of L2S, and MVC CRUD HTML generation. Fairly cheap for an unlimited site license too.
tasogare 5y ago
> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. You must have miss dotnet Core because the modernization you're asking happened years ago.
- trangus_1985 5y ago
  Ah yeah, I was using core I think. Sorry, it's been a while, I kinda glazed over the acronyms and names over time. Since it was my own project, I really was trying to do things "the modern way".
  - deleted 5y ago
    [deleted]
  - gregoryl 5y ago
    Why were you targeting mono then?
    - trangus_1985 5y ago
      Frankly, I don't remember. It's been a long time and using .net was a failed experiment. >Why were you targeting mono then? Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM. I did multiple things, multiple attempts to make it work. I tried to do it "the right way" from various sources. The reason I was targeting mono at some point was because I wanted to run a microservice, without paying windows server licenses fees, and as best I can tell, that was the root runtime I'd need to target. Keep in mind that this was me, going in blind into a large and established ecosystem. I don't think going astray detracts from some of my bigger complaints, such as the poor quality of community open source libraries.
      - Merad 5y ago
        > Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM. Meaning no offense, but it’s hard to see how you ended up so far off the mark. The .Net frameworks and runtimes (.Net Framework, .Net Core, and mono) have always been free. Likewise for the Asp.Net web framework you would have been using for web applications. I’ve been in the .Net ecosystem for over 10 years and I’m not aware of _any_ paid web stacks that would align with the quote above. Not to say that they don’t exist somewhere out there to extract money from foolish enterprise IT departments, but they aren’t even close to mainstream. If you did this experiment within the last 5 years it would have been extraordinarily hard for you to miss out on .Net Core, especially considering it was built to do exactly what you want - microservices with Linux as a first class citizen.
cyral 5y ago
> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. I recently built a company over the past year with .NET (after not using it for 5+ years) and felt the total opposite. I suspect you may be referring to the old .NET back when you needed Mono to run it on anything but Windows? .NET Core has been out for a few years and is an amazing improvement, the APIs (especially for web dev) feel very complete and modern, and there have been a lot of neat language features added in the recent major versions. The old .NET was definitely clunky though for targeting anything but Windows apps or servers. Not sure what you are referring to for the paid products - .NET Core is now open source and even accepts PRs. Although there is no official YAML support still, so maybe the third party library was paid? JSON is a great option these days and .NET's new JSON parser is really fast and uses much less memory (Years ago C# got support for the new Span<T> and Memory<T> types which allow type-safe access to the underlying memory, making serialization operations much better since there isn't a bunch of copying and allocating involved any more)
- billfruit 5y ago
  Not exactly related, how is Xamarin integrated into this ecosystem. Does Xamarin have a future?
  - Mertax 5y ago
    While Xamarin has some pain points it definitely satisfies a market need for “native” cross platform development. My company uses it quite a bit. With .NET MAUI on the horizon as the evolution of Xamarin it has a future. Although I do wonder if the Blazor (mobile bindings) might end up having the brighter future. Kind of seems like the back up plan to appeal more to the HTML/CSS web devs who don’t want to adopt/learn the XAML UI markup.
  - weq 5y ago
    .net7+ is basically .netcore + xamrain integrated into a single product. MS are evolving xamarin into a new UI framework called MAUI
  - crobibero 5y ago
meibo 5y ago
Sadly(or luckily, for the people that haven't had any contact with the ecosystem), you must have missed the semi-recent open source developments around .NET Core. It's open, has a very healthy community and is well supported by Microsoft. Sure, back in the days when you had to rely on Mono for cross-compact, this is exactly the answer you'd expect from anyone, but it couldn't be further away from the truth nowadays with the modern runtime and ASP .NET Core.
cosmotic 5y ago
Why would you start a project on a platform then build that product on a foundation of one of that platforms weaknesses instead of one of its strengths? This anecdote is not good evidence against the platform.
- oneepic 5y ago
  You're referring to the YAML point? The way I read it, it sounds like the poster only learned about the issue when they ran into it during development. That being said, a couple of specific complaints is probably not the best argument against a broader platform.
  - cosmotic 5y ago
    I remember XML support in .NET being excellent. The author could have used C# classes that would serialize/deserialize to/from the XML, then used built-in tools to generate an XML schema for the config files. The schema could then be consumed by vendors or other connected projects using .NET and have perfect, code-first, statically typed interop. You'd never be writing XML itself or the schemas or the serialization/deserialization code. You can't get any of that with YAML, it doesn't support that sort of safety. You'd have to manually implement all the safety checks and serialization/deserialization for a worse end result. Of course that would be a bad outcome.
oneepic 5y ago
I can't refute your examples, but I think on one hand, C#/.NET has a lot of modern stuff you maybe didn't see, which you'd wish other languages had. The lang has great features (i.e. properties; the libraries for collections/concurrent collections; System.Linq; and Tasks, to name some). VS has great profiling tools (cpu/memory) if you know how to use them. Package and dependency management were bad, but I believe got some needed improvements starting with .NET Core. Things like that. OTOH, that said, I don't actually prefer C#/.NET, when I think of those techs I don't think of a great OSS ecosystem (more like marketing blog posts by Microsoft MVPs, as opposed to technical deep dives by passionate engineers). I also think of github repos with at least 10x more open issues than stars or forks. These techs have great features, and they're used for successful projects/companies, but there's something about the fact MSFT owns them that makes me not want to use them at all, and just prefer golang/java/etc.
- mattmanser 5y ago
  MVPs are passionate engineers! They're not microsoft employees. It's just MS has explicitly recognized them. There's an irony that the award MS gives to passionate engineers in the .Net community has been completely misunderstood by someone outside of it. If you want to see a great example of a passionate engineer who's been awarded the MVP, go read a few Rick Strahl blog posts. Another one was Scott Hanselman, though I believe he joined MS like 10 years ago. They addmitedly muddy the waters by awarding the MVP to their own employees writing about their new stuff, but even they can be passionate and interesting. Scott Guthrie's time on ASP.Net is a good example.
  - oaiey 5y ago
    When you join the MVP program you are an evangelist. You are briefed, you are under NDA and you start to have a very different view that the broader community. Not every MVP is like that, but while I like the content they create I see them seriously disconnected from many .NET developers and actual use cases.
    - oneepic 5y ago
Rapzid 5y ago
> The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with I never thought I'd see Spring(or any of those) described as more modern and easy to work with than .Net haha. Spring is the Java land web framework bloatlord. It's quickly fallen behind and out of favor in recent years with the hip crowd preferring micro frameworks like Quarkus or Micronaut. Spring abandoned hot-reload in favor of restarting app context which takes FOR EV ER on larger projects; .Net is releasing hot reload as a first class platform feature as we speak. .Net runtime is one of the hotest pieces of action on the planet. AOT compile, multi-core threading, async/await, Span<T>. Mono is pulling its weight too with compile to WASM. Then you have ASP.NET, Entity Framework, and a lot of other really great and performant build blocks.
bayesian_horse 5y ago
IMHO for startups, productivity and development speed usually beats performance and enterprisy-ness (looking at you, Spring). F# dominates C# there, but Django, FastAPI, various other options for Node or other languages, are simply easier to learn and faster to iterate. You can change/reload a Django app several times before the C# compiler finds a problem with your static types in a bigger codebase... And to me it seems like you can acquire technical debt in C# just as fast as with any other language. Maybe faster because it is harder to learn and less "obvious" with all the DI magic. Of course, if you are proficient in C# and its ecosystem, you can write some damn fine software in it. If so, I wish you the best of luck finding affordable coworkers who can do the same.
- mattmanser 5y ago
  This is pretty much nonsense, not sure when you developed C#, but Type feedback is instant and pretty much always has been. Also, you're making up an impossible scenario, a startup that's moving fast, but somehow has a 'bigger' codebase.
  - bayesian_horse 5y ago
    I'm not saying it's at the same time. And yes, type feedback is mostly instant. The code base I'm currently working on takes a long time to compile and sometimes there are errors. Or there are runtime errors. Combined with the much higher volume of code I have to write, and the greatly reduced readability C# does feel a lot less productive than Python.
    - mattmanser 5y ago
      Usually when I see that, it's because someone's implemented an inappropriate pattern, or gone over board on 'SOLID' principles or whatever. C# developers seem especially prone to getting trapped in stupid implementations that massively bloat the code. For taking some Uncle Bob dictat to an unnecessary extreme, or implementing a dangerous pattern like CRQS stupidly for a simple CRUD app. Less a reflection on the language and more of a reflection of the enterprisey culture. I was interviewing in the C# world recently, it was quite disheartening to hear the same phrases repeated 'hybrid microservices' (i.e. we've got the worst of both worlds in one project! But our TA got to put microservices on his CV!) or 'we value SOLID code' (i.e. we've massively over-engineered our code, development has slowed to a crawl, there are far too many interfaces, and debugging is a nightmare!). But you can write great, terse, code in C#, and I feel much quicker than dynamically typed languages. I feel like I can implement the same code much faster in C# than I do in the equivalent javascript, even though I've been writing javascript for longer, and that's down to the autocompletion and snippets of a powerful IDE, which dynamic languages will never be able to match. It's also much easier and quicker to move code, refactor, and generally redesign your code on the fly as you're exploring the problem space.

heavyset_go 5y ago

> And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid. What are some of those things?

trangus_1985 5y ago
it's been about a year but it was a death by a thousand papercuts kinda thing. I want to add that I was not an experienced python developer at the time - I'd used it for a handful of simple automation scripts. My day job was writing scala. - targeting mono under nginx on linux, from within windows was really difficult, I could never quite get it to work - no support for monodevelop on windows - cross platform was crucial to me and it just got so onerous. And maybe it's just me, but I was really hitting a lot of frustration with visual studio. - i wanted to use both yamlschema (broken at the time) and jsonschema (paid) - msbuild is abysmal with useless error messages. I struggled to run a simple shell script during the build process. - a couple of libraries I tried were broken or unmaintained. The .net ecosystem seems to have very low quality of community maintained tools. - no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look) - ... and that's all I can remember. There was more. I fully acknowledge that some, if not all, of those complaints may be self-inflicted. I can't say that, for my first complicated project in python, it's been completely smooth sailing. However, with python/falcon, it didn't feel like I was fighting with the ecosystem to define a package, import the package into a microservice codebase, and then get the service running with full test coverage. It didn't feel like I was fighting to bring a third party library in, verify it's actively being maintained, and start using it. I spent as much time getting a simple microservice hello world with authz/authn validation and a reasonable packaging system, in python, set up in about time as it took me to give up on msbuild. I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net.
- Hawxy 5y ago
  I think the only time I've found people this far off the main track is users that only know C#/mono coming from Unity Engine. > targeting mono under nginx on linux...no support for monodevelop on windows Because you should have never been anywhere near mono. Even a year ago, if you followed the main .NET documentation it would have directed you to install the .NET 3.1 or 5 SDK on to your linux environment and get setup with VSCode. It's the first step in the hello world tutorial: https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install https://dotnet.microsoft.com/learn/dotnet/hello-world-tutori... > no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look) Dapr is not a Microsoft product. Microsoft does not offer commercial support for it. There's docs for the .NET library on the Dapr website, along with various community support channels available. > I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net. Bootstrapping a worker service or ASP.NET Core on windows is either a few clicks in VS, or a one line command via the dotnet CLI.

sumnole 5y ago

the .net ecosystem is somewhat pay to win - its like the apple store of the devtool world, clients are actually willing to pay. if your company has the funds, you have access to some of the best tools in development, but you can get pretty far with its free options too. C# is quite a nice language to work with. historically projects were very enterprisey oop monsters but cleaner functional paradigms are trending in the .net space.

trangus_1985 5y ago
Yes, I quite like C#, the language. That's why I put so much effort into trying to make it work - it's become one of my favorite languages!
hvidgaard 5y ago
You can absolutely write in a functional style. It does not have to be the enterprise OOP monsters of the past. Apart from something radical such as adapting a Hindley-Milner type system, I'm not sure it can support functions much better than it already is. I think most people simple oppose to the idea of a static type system, and my experience is that static type checking is an absolute time saver in the long run for large long lived. Significantly.
ahepp 5y ago
I'd love to hear more about the top tier paid tools. I haven't really experienced that before.
- to11mtm 5y ago
  Closest I can think of is the days of yore where .NET Component licensing was a thing that was encountered frequently enough it was mentioned more prominently in books. This was useful for a lot of 3rd party developers that wanted to provide either tooling or runtime libraries to IT Shops. UI Toolkits and other 'specialized' libraries would use this mechanism as a way to keep some level of IP Protection. I ran into this scheme in the wild with Devart's DotConnect for Oracle; at the time it was worlds better than the free 1st party providers, and came with some interesting T4 templates for generating models for either EF or their special adaptation of L2S, and MVC CRUD HTML generation. Fairly cheap for an unlimited site license too.

tasogare 5y ago

> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. You must have miss dotnet Core because the modernization you're asking happened years ago.

trangus_1985 5y ago
Ah yeah, I was using core I think. Sorry, it's been a while, I kinda glazed over the acronyms and names over time. Since it was my own project, I really was trying to do things "the modern way".
- deleted 5y ago
  [deleted]
- gregoryl 5y ago
  Why were you targeting mono then?
  - trangus_1985 5y ago
    Frankly, I don't remember. It's been a long time and using .net was a failed experiment. >Why were you targeting mono then? Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM. I did multiple things, multiple attempts to make it work. I tried to do it "the right way" from various sources. The reason I was targeting mono at some point was because I wanted to run a microservice, without paying windows server licenses fees, and as best I can tell, that was the root runtime I'd need to target. Keep in mind that this was me, going in blind into a large and established ecosystem. I don't think going astray detracts from some of my bigger complaints, such as the poor quality of community open source libraries.
    - Merad 5y ago
      > Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM. Meaning no offense, but it’s hard to see how you ended up so far off the mark. The .Net frameworks and runtimes (.Net Framework, .Net Core, and mono) have always been free. Likewise for the Asp.Net web framework you would have been using for web applications. I’ve been in the .Net ecosystem for over 10 years and I’m not aware of _any_ paid web stacks that would align with the quote above. Not to say that they don’t exist somewhere out there to extract money from foolish enterprise IT departments, but they aren’t even close to mainstream. If you did this experiment within the last 5 years it would have been extraordinarily hard for you to miss out on .Net Core, especially considering it was built to do exactly what you want - microservices with Linux as a first class citizen.

cyral 5y ago

> C#, .NET/FCL, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. I recently built a company over the past year with .NET (after not using it for 5+ years) and felt the total opposite. I suspect you may be referring to the old .NET back when you needed Mono to run it on anything but Windows? .NET Core has been out for a few years and is an amazing improvement, the APIs (especially for web dev) feel very complete and modern, and there have been a lot of neat language features added in the recent major versions. The old .NET was definitely clunky though for targeting anything but Windows apps or servers. Not sure what you are referring to for the paid products - .NET Core is now open source and even accepts PRs. Although there is no official YAML support still, so maybe the third party library was paid? JSON is a great option these days and .NET's new JSON parser is really fast and uses much less memory (Years ago C# got support for the new Span<T> and Memory<T> types which allow type-safe access to the underlying memory, making serialization operations much better since there isn't a bunch of copying and allocating involved any more)

billfruit 5y ago
Not exactly related, how is Xamarin integrated into this ecosystem. Does Xamarin have a future?
- Mertax 5y ago
  While Xamarin has some pain points it definitely satisfies a market need for “native” cross platform development. My company uses it quite a bit. With .NET MAUI on the horizon as the evolution of Xamarin it has a future. Although I do wonder if the Blazor (mobile bindings) might end up having the brighter future. Kind of seems like the back up plan to appeal more to the HTML/CSS web devs who don’t want to adopt/learn the XAML UI markup.
- weq 5y ago
  .net7+ is basically .netcore + xamrain integrated into a single product. MS are evolving xamarin into a new UI framework called MAUI
- crobibero 5y ago

meibo 5y ago

Sadly(or luckily, for the people that haven't had any contact with the ecosystem), you must have missed the semi-recent open source developments around .NET Core. It's open, has a very healthy community and is well supported by Microsoft. Sure, back in the days when you had to rely on Mono for cross-compact, this is exactly the answer you'd expect from anyone, but it couldn't be further away from the truth nowadays with the modern runtime and ASP .NET Core.

cosmotic 5y ago

Why would you start a project on a platform then build that product on a foundation of one of that platforms weaknesses instead of one of its strengths? This anecdote is not good evidence against the platform.

oneepic 5y ago
You're referring to the YAML point? The way I read it, it sounds like the poster only learned about the issue when they ran into it during development. That being said, a couple of specific complaints is probably not the best argument against a broader platform.
- cosmotic 5y ago
  I remember XML support in .NET being excellent. The author could have used C# classes that would serialize/deserialize to/from the XML, then used built-in tools to generate an XML schema for the config files. The schema could then be consumed by vendors or other connected projects using .NET and have perfect, code-first, statically typed interop. You'd never be writing XML itself or the schemas or the serialization/deserialization code. You can't get any of that with YAML, it doesn't support that sort of safety. You'd have to manually implement all the safety checks and serialization/deserialization for a worse end result. Of course that would be a bad outcome.

oneepic 5y ago

I can't refute your examples, but I think on one hand, C#/.NET has a lot of modern stuff you maybe didn't see, which you'd wish other languages had. The lang has great features (i.e. properties; the libraries for collections/concurrent collections; System.Linq; and Tasks, to name some). VS has great profiling tools (cpu/memory) if you know how to use them. Package and dependency management were bad, but I believe got some needed improvements starting with .NET Core. Things like that. OTOH, that said, I don't actually prefer C#/.NET, when I think of those techs I don't think of a great OSS ecosystem (more like marketing blog posts by Microsoft MVPs, as opposed to technical deep dives by passionate engineers). I also think of github repos with at least 10x more open issues than stars or forks. These techs have great features, and they're used for successful projects/companies, but there's something about the fact MSFT owns them that makes me not want to use them at all, and just prefer golang/java/etc.

mattmanser 5y ago
MVPs are passionate engineers! They're not microsoft employees. It's just MS has explicitly recognized them. There's an irony that the award MS gives to passionate engineers in the .Net community has been completely misunderstood by someone outside of it. If you want to see a great example of a passionate engineer who's been awarded the MVP, go read a few Rick Strahl blog posts. Another one was Scott Hanselman, though I believe he joined MS like 10 years ago. They addmitedly muddy the waters by awarding the MVP to their own employees writing about their new stuff, but even they can be passionate and interesting. Scott Guthrie's time on ASP.Net is a good example.
- oaiey 5y ago
  When you join the MVP program you are an evangelist. You are briefed, you are under NDA and you start to have a very different view that the broader community. Not every MVP is like that, but while I like the content they create I see them seriously disconnected from many .NET developers and actual use cases.
  - oneepic 5y ago

Rapzid 5y ago

> The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with I never thought I'd see Spring(or any of those) described as more modern and easy to work with than .Net haha. Spring is the Java land web framework bloatlord. It's quickly fallen behind and out of favor in recent years with the hip crowd preferring micro frameworks like Quarkus or Micronaut. Spring abandoned hot-reload in favor of restarting app context which takes FOR EV ER on larger projects; .Net is releasing hot reload as a first class platform feature as we speak. .Net runtime is one of the hotest pieces of action on the planet. AOT compile, multi-core threading, async/await, Span<T>. Mono is pulling its weight too with compile to WASM. Then you have ASP.NET, Entity Framework, and a lot of other really great and performant build blocks.

bayesian_horse 5y ago

IMHO for startups, productivity and development speed usually beats performance and enterprisy-ness (looking at you, Spring). F# dominates C# there, but Django, FastAPI, various other options for Node or other languages, are simply easier to learn and faster to iterate. You can change/reload a Django app several times before the C# compiler finds a problem with your static types in a bigger codebase... And to me it seems like you can acquire technical debt in C# just as fast as with any other language. Maybe faster because it is harder to learn and less "obvious" with all the DI magic. Of course, if you are proficient in C# and its ecosystem, you can write some damn fine software in it. If so, I wish you the best of luck finding affordable coworkers who can do the same.

mattmanser 5y ago
This is pretty much nonsense, not sure when you developed C#, but Type feedback is instant and pretty much always has been. Also, you're making up an impossible scenario, a startup that's moving fast, but somehow has a 'bigger' codebase.
- bayesian_horse 5y ago
  I'm not saying it's at the same time. And yes, type feedback is mostly instant. The code base I'm currently working on takes a long time to compile and sometimes there are errors. Or there are runtime errors. Combined with the much higher volume of code I have to write, and the greatly reduced readability C# does feel a lot less productive than Python.
  - mattmanser 5y ago
    Usually when I see that, it's because someone's implemented an inappropriate pattern, or gone over board on 'SOLID' principles or whatever. C# developers seem especially prone to getting trapped in stupid implementations that massively bloat the code. For taking some Uncle Bob dictat to an unnecessary extreme, or implementing a dangerous pattern like CRQS stupidly for a simple CRUD app. Less a reflection on the language and more of a reflection of the enterprisey culture. I was interviewing in the C# world recently, it was quite disheartening to hear the same phrases repeated 'hybrid microservices' (i.e. we've got the worst of both worlds in one project! But our TA got to put microservices on his CV!) or 'we value SOLID code' (i.e. we've massively over-engineered our code, development has slowed to a crawl, there are far too many interfaces, and debugging is a nightmare!). But you can write great, terse, code in C#, and I feel much quicker than dynamically typed languages. I feel like I can implement the same code much faster in C# than I do in the equivalent javascript, even though I've been writing javascript for longer, and that's down to the autocompletion and snippets of a powerful IDE, which dynamic languages will never be able to match. It's also much easier and quicker to move code, refactor, and generally redesign your code on the fly as you're exploring the problem space.