4 ms·

The problem is Enterprise not .Net. I have the freedom to pick whatever technology I please as long as I deliver a product that works within the specifications

by dep_b 10y ago

The problem is Enterprise not .Net. I have the freedom to pick whatever technology I please as long as I deliver a product that works within the specifications of my customers and I find there is a place for for example ASP.Net MVC API's written in C# or Windows services written in F# even when given a complete free choice. Sometimes I pick PHP as "must run anywhere" is the requirement. The next day I'll pick Swift or Objective-C because it's something Apple related. But .Net is always a possibility. But yet while nobody really forces me to use a .Net stack I still pick it since the stack is really stable and relatively easy to use (compared to the perpetual change and chaos of a Modern Web Stack for example). Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while. I've been in those soulless Enterprise shops and it's just what happens to places where people go everyday to watch the clock go six about 28 times per month so they'll see the number on their bank account grow with a predictable number every time. But somewhere in the world these places exist full of PHP developers or Java developers. The thing with Java or .Net is that some customers have really old stacks and don't want to change anything. It's the new Cobol for some companies while other companies do really cool cross-platform stuff. It can be both. Take care where you take your resumé since the cool jobs are much harder to find since nobody with a living soul wants that kind of enterprise jobs.

c0achmcguirk 10y ago
You made the point I wanted to make. The problem is Enterprise, not a framework. I'll admit--the Microsoft stack is a walled garden. It offers some nice features like Visual Studio integrating with Visual Studio Team Services with its own issue tracker and build server and so on. If Microsoft supports your workflow or integrates with the tooling you like, awesome. If not, well, just wait and hope that it will someday support what you're looking for. That is the frustrating part of the Microsoft stack. It can be overcome with some architecture decisions at the outset of the project. You don't have to stay in the walled garden. But the Enterprise is where innovation dies. The Enterprise is where motivated developers' souls are sucked out as they are told "no" constantly. .NET isn't the problem.
- lmm 10y ago
  But .net is inherently enterprisey. You have to license all the things you're using, or did until recently - Visual Studio, SQL Server... you may not have to pay if you're a small business or whatever but it's always going to be a lot more effort than just clicking download. That has a chilling effect on people using these technologies for the side projects that become productive small businesses, and it compounds because if no-one's using that stack in these places then there's no open-source library ecosystem because there's no-one to create that.
  - cwbrandsma 10y ago
    No different than the Java shops I've seen.
    - lmm 10y ago
      Very different in my experience; there's a lot more on maven central, because the toolchain and other popular components (e.g. mariadb) are freely available, so you can very easily spin up the same environment at home.
- astine 10y ago
  "I'll admit--the Microsoft stack is a walled garden. It offers some nice features like Visual Studio integrating with Visual Studio Team Services with its own issue tracker and build server and so on. If Microsoft supports your workflow or integrates with the tooling you like, awesome. If not, well, just wait and hope that it will someday support what you're looking for." To be fair, they are getting better about that. Git has almost as good support as TFS in Visual Studio these days and MS is even integrating Linux of all things into its latest Windows releases. If that trend continues, MS will eventually be much less of a walled garden.
nxc18 10y ago
This is a really great point. I have 'old' web apps in .Net from a few years ago that just work today; same with old desktop code. Go back to a e.g. Meteor app from a year ago and it will very likely be broken, either by some change to the client js runtime or some change with a newer version of node breaking packages. Unfortunately the changes to the client and security issues tend to force node+package updates. There's a lot of underappreciated value in long term stability
- pc86 10y ago
  > Unfortunately the changes to the client and security issues tend to force node+package updates. Are you sure that shouldn't be "fortunately?" I write 90% C# and 10% JS and I would be so happy if there was some structural reason requiring .NET apps to be updated regularly. The number of apps I've run into that are several years past EOL but the client refuses to update them because "well it works and we haven't been hacked yet" is indeed soul crushing after a while.
  - jsudhams 10y ago
    I am not sure why, i started VB.Net and somehow i dont like any other language i can write an app (CRUD) in a week. Never had an issue , help is available code is like english to me most of the time.
  - inetknght 10y ago
    The bigger problem isn't that people don't update. The bigger problem is why people don't update. Updates often cause things to break. If you want structural changes to force updates, you'd better also have structural changes to force stability of those updates. Otherwise you'll find that you've locked out certain types of customers.
    - zip1234 10y ago
      This isn't a .net problem. This is an almost every software product known to man problem.
  - 10y ago
teh_klev 10y ago
> Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while. This. I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors. Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6. This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas. Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted. Finally.... ...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying. Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world. Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example). [0]: https://msdn.microsoft.com/en-us/library/ff649538.aspx https://msdn.microsoft.com/en-us/library/ff649538.aspx

by dep_b 10y ago

c0achmcguirk 10y ago

You made the point I wanted to make. The problem is Enterprise, not a framework. I'll admit--the Microsoft stack is a walled garden. It offers some nice features like Visual Studio integrating with Visual Studio Team Services with its own issue tracker and build server and so on. If Microsoft supports your workflow or integrates with the tooling you like, awesome. If not, well, just wait and hope that it will someday support what you're looking for. That is the frustrating part of the Microsoft stack. It can be overcome with some architecture decisions at the outset of the project. You don't have to stay in the walled garden. But the Enterprise is where innovation dies. The Enterprise is where motivated developers' souls are sucked out as they are told "no" constantly. .NET isn't the problem.

lmm 10y ago
But .net is inherently enterprisey. You have to license all the things you're using, or did until recently - Visual Studio, SQL Server... you may not have to pay if you're a small business or whatever but it's always going to be a lot more effort than just clicking download. That has a chilling effect on people using these technologies for the side projects that become productive small businesses, and it compounds because if no-one's using that stack in these places then there's no open-source library ecosystem because there's no-one to create that.
- cwbrandsma 10y ago
  No different than the Java shops I've seen.
  - lmm 10y ago
    Very different in my experience; there's a lot more on maven central, because the toolchain and other popular components (e.g. mariadb) are freely available, so you can very easily spin up the same environment at home.
astine 10y ago
"I'll admit--the Microsoft stack is a walled garden. It offers some nice features like Visual Studio integrating with Visual Studio Team Services with its own issue tracker and build server and so on. If Microsoft supports your workflow or integrates with the tooling you like, awesome. If not, well, just wait and hope that it will someday support what you're looking for." To be fair, they are getting better about that. Git has almost as good support as TFS in Visual Studio these days and MS is even integrating Linux of all things into its latest Windows releases. If that trend continues, MS will eventually be much less of a walled garden.

nxc18 10y ago

This is a really great point. I have 'old' web apps in .Net from a few years ago that just work today; same with old desktop code. Go back to a e.g. Meteor app from a year ago and it will very likely be broken, either by some change to the client js runtime or some change with a newer version of node breaking packages. Unfortunately the changes to the client and security issues tend to force node+package updates. There's a lot of underappreciated value in long term stability

pc86 10y ago
> Unfortunately the changes to the client and security issues tend to force node+package updates. Are you sure that shouldn't be "fortunately?" I write 90% C# and 10% JS and I would be so happy if there was some structural reason requiring .NET apps to be updated regularly. The number of apps I've run into that are several years past EOL but the client refuses to update them because "well it works and we haven't been hacked yet" is indeed soul crushing after a while.
- jsudhams 10y ago
  I am not sure why, i started VB.Net and somehow i dont like any other language i can write an app (CRUD) in a week. Never had an issue , help is available code is like english to me most of the time.
- inetknght 10y ago
  The bigger problem isn't that people don't update. The bigger problem is why people don't update. Updates often cause things to break. If you want structural changes to force updates, you'd better also have structural changes to force stability of those updates. Otherwise you'll find that you've locked out certain types of customers.
  - zip1234 10y ago
    This isn't a .net problem. This is an almost every software product known to man problem.
- 10y ago

teh_klev 10y ago

> Something I've written 4 years ago will still run and compile like yesterday even if I've abandoned it in the mean while. This. I wrote a bunch of our (internal, non-internet facing) billing and automation code back in 2003 in C#1(.1?)/.NET 1.1. As we've gradually moved to .NET 4 the code still just works and when we need to it recompiles against newer framework versions with no errors. Even the assembly of the Data Access Application Block [0] used back then for some of this stuff still works fine, the last time it was recompiled was for .NET 2.0 around 2006, but the IL runs without any trouble on .NET 4.6. This is a mission critical codebase that doesn't change very often, but when it does it's imperative that it can when necessary rebuild against each major .NET framework update with no dramas. Stability and confidence is key for us and MS have been very good at that, even when older features are deprecated/obsoleted. Finally.... ...just over two years ago when we were pushing the last of our hosted dedicated server customers to upgrade from Windows 2003 to Windows 2012R2 there were a few folks that were still running websites written in ASP.NET 1.1/.NET 1.1 on 2003. There were probably 40-50 sites and a sprinkling of Classic ASP just to make life interesting. Most customers didn't want to go through the hassle of recompiling and redeploying. Now whilst there is a .NET 1.1 release you can run on Windows 2012, I really didn't want to be supporting three framework versions (1.1, 2.0/3.5 and 4.x) and CLRs. Having successfully migrated bucket loads of ASP.NET 1.1 sites to 2.0 in the past, from experience, I was fairly confident the 1.1 binaries would run just fine on .NET 2.0 which is the minimum version of .NET that ships in Windows 2012 and the IIS admin bits know about. After a week or so all of these old 1.1 sites were up and running on .NET 2.0 in IIS Classic Pipeline app pools, no recompilation needed and except for one site that used an ancient third party PDF component, all was well in the world. Now whilst .NET may seem unexciting enterprisey stuff, it's a testament to how much the .NET folks care about stability and backwards compatibility. I'm fairly sure, and I know for sure, I couldn't do these seamless transitions if these codebases were written in PHP (for example). [0]: https://msdn.microsoft.com/en-us/library/ff649538.aspx https://msdn.microsoft.com/en-us/library/ff649538.aspx