6 ms·

The tools and libraries from Microsoft are so solid that frankly you don't need an entire class of open source projects. I don't need to "contribute" and "soci

by tacos 11y ago

The tools and libraries from Microsoft are so solid that frankly you don't need an entire class of open source projects. I don't need to "contribute" and "socialize" with some Python craziness named after a dolphin (though I did!) because Amazon provides a real .NET SDK for talking to AWS. I don't need to wrestle with three different constantly-patched Ruby image libraries because .NET has been able to load and save six kinds of bitmaps via everything from C# to F# to Excel macros since the 90s. The community around node.js in many ways is an attempt to re-write .NET from the ground up. And they're doing an amazing job. But so am I, when I can write three lines of code in a version of F# that shipped six years ago and issue SQL-like data gathering queries over everything from Wikipedia to the Department of Labor. That said -- Microsoft's idiotic forges and weirdo repositories were total incompetent nonsense. And the stupidity with their C compilers -- from strategy to implementation -- presented a brick wall to anything resembling clean cross-platform development, which DAMMIT, is a must. There is a lot more open-source .NET code out there than you'd think. But it tends to be very narrow and very vertical (and often, very high quality) because the core libraries are so broad and so great.

WorldWideWayne 11y ago
You're not wrong. People who don't work in "enterprise" or even in small/medium business IT shops will never know it though. However, I think the downvotes are probably a reaction to the hint of attitude which suggests that you're not overzealous about OSS.
- eropple 11y ago
  I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows to a polyglot microservice architecture on Linux. Surely it isn't the severe drag of dealing with C# and the incredible mess of .NET deployment in a rapidly iterating environment (and, to be fair, this is also in part Windows's fault, there's no good disposable-server model for Windows in a cloud environment because the provisioning stuff is not great, so you make bad decisions like persistent servers and Octopus). As it happens, I like C#, as a mostly-portable language for writing video games because the runtime has been ported almost anywhere I care about. I have a lot of open-source C# stuff in my Github and have been doing open-source C# since about 2007. But as an ecosystem for high-velocity, agile work, it's got problems. Maybe CoreCLR on Linux, once the bugs are well and truly killed, will be an answer, but it's not there yet.
  - tacos 11y ago
    "polyglot microservice architectures" eh? Hey Bill! We've got 20 years of legacy code that handles everything from Arrivals Boards to seat assignments in 1627 different aircraft configurations. We got a room full of .NET devs downstairs. How about we re-write everything in multiple languages! Remember that time we went down for two days because we muffed up our NET 2.0 to 4.0 migration? Imagine how much fun we'll have when we're doing it with Python, Ruby, Rust, Swift, Javascript and Go! We'll break out the seat assignments in Go. Do the signboards in Python. Web app for refunds in Ruby. I don't know what Rust is but one of the guys downstairs has a book on it with a woodcut of a beaver on the front. Think of all the time we'll save! Plus our consultant says it's so much easier to spin up Linux VMs! "Bill, it's the same damn button to spin up a Linux server anywhere. Even on Azure. You just check the Penguin instead of the four squares first. And our deploy scripts work just fine. Even our stupidest apps from the 1990s are one binary file and one text file now. And nobody but Tim is allowed to change the text file."
    - eropple 11y ago
      Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it! - Almost every developer was converted to .NET to work there, because Microsoft's credibility among startup-focused developers is not great outside of a few specific tools like SQL Server. It's a lot easier to get enough hands to get the job done when you let them use Node (which, I'll be honest, I don't even really like, I'd personally rather write C# but I don't write application code here so it doesn't matter) instead of making them write C#. - The legacy stuff isn't being rewritten. It's going to be ported to Linux, using Microsoft's own CoreCLR. Parts will be broken out into their own services in order to directly scale them and make it easier to provide separation of concerns; whether it gets rewritten or just parted out is an engineering decision, but so far they seem content to part out legacy code instead of rewrite. - I'm a DevOps guy. I automate. And you can automate a lot more, to go a lot faster, in a Linux environment. Chef's made strides in Windows, and that's honestly and truly cool, but it's only a first step. There's a reason that most devops folks I know have settled on disposable architectures, where a config change means that the machine should be canned: it reduces ambiguity by removing convergence in favor of guaranteed state. This is extremely difficult in Windows because of the amount of drag induced by the tooling. It takes literally-literally twice as long to bake a Windows Vagrant box as it does a Linux one--I've timed it. It takes longer to build a Windows AMI. It takes longer to deploy one, making your auto-scaling groups less responsive. -This company's load patterns are unpredictable enough and spiky enough that there is an actual, no-bullshit need for scaling on the order of seconds, not 5-10 minutes, and you literally can't do that in AWS with Windows (and I don't think you can with Azure, either); containerization technology (ECS, Mesos, whatever) is making it very practical to meet these sorts of response requirements. - Languages must be approved; right now it's just Node and Mono (soon to be CoreCLR), but the build environments (both through Chef and, later, through Docker) support multiple languages. To use something else, one will have to make their case. But instead of assuming a certain level of professional rigor, you started frothing and assuming everything would be written in whatever struck somebody's fancy. Seriously: fanboy harder. It's clearly working.
fr0styMatt2 11y ago
Why oh why oh why did I have to think about Visual SourceSafe ever again? :P
verinus 11y ago
funny thing is I don't think that the tools or libs are still far from perfect: - WPF tooling is severely lacking in regard to databindings. - libs such as collection classes were far from java standards when release- there is even a pretty good OSS alternative: C5 - there is no standard for filepaths in .Net but even there a good OSS alternative exists: NDepend Path but I see a lot of improvement in the last years: Rx, ReactiveUI, NuGet, FAKE and much more high quality OSS is beeing created.
mistermann 11y ago
> when I can write three lines of code in a version of F# that shipped six years ago and issue SQL-like data gathering queries over everything from Wikipedia to the Department of Labor. What's the name this technology goes by, and is it possible in C# (regardless of if it's extra lines of code)?
- tacos 11y ago
  F# type providers. Quick entry point: http://tomasp.net/blog/fsharp-data.aspx/ http://tomasp.net/blog/fsharp-data.aspx/ It's kinda awesome. C# provides similar (but somehow less fun) stuff via LINQ providers. Search "LINQ to [noun]" and you'll find plenty of open source code.

by tacos 11y ago

WorldWideWayne 11y ago

You're not wrong. People who don't work in "enterprise" or even in small/medium business IT shops will never know it though. However, I think the downvotes are probably a reaction to the hint of attitude which suggests that you're not overzealous about OSS.

eropple 11y ago
I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows to a polyglot microservice architecture on Linux. Surely it isn't the severe drag of dealing with C# and the incredible mess of .NET deployment in a rapidly iterating environment (and, to be fair, this is also in part Windows's fault, there's no good disposable-server model for Windows in a cloud environment because the provisioning stuff is not great, so you make bad decisions like persistent servers and Octopus). As it happens, I like C#, as a mostly-portable language for writing video games because the runtime has been ported almost anywhere I care about. I have a lot of open-source C# stuff in my Github and have been doing open-source C# since about 2007. But as an ecosystem for high-velocity, agile work, it's got problems. Maybe CoreCLR on Linux, once the bugs are well and truly killed, will be an answer, but it's not there yet.
- tacos 11y ago
  "polyglot microservice architectures" eh? Hey Bill! We've got 20 years of legacy code that handles everything from Arrivals Boards to seat assignments in 1627 different aircraft configurations. We got a room full of .NET devs downstairs. How about we re-write everything in multiple languages! Remember that time we went down for two days because we muffed up our NET 2.0 to 4.0 migration? Imagine how much fun we'll have when we're doing it with Python, Ruby, Rust, Swift, Javascript and Go! We'll break out the seat assignments in Go. Do the signboards in Python. Web app for refunds in Ruby. I don't know what Rust is but one of the guys downstairs has a book on it with a woodcut of a beaver on the front. Think of all the time we'll save! Plus our consultant says it's so much easier to spin up Linux VMs! "Bill, it's the same damn button to spin up a Linux server anywhere. Even on Azure. You just check the Penguin instead of the four squares first. And our deploy scripts work just fine. Even our stupidest apps from the 1990s are one binary file and one text file now. And nobody but Tim is allowed to change the text file."
  - eropple 11y ago
    Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it! - Almost every developer was converted to .NET to work there, because Microsoft's credibility among startup-focused developers is not great outside of a few specific tools like SQL Server. It's a lot easier to get enough hands to get the job done when you let them use Node (which, I'll be honest, I don't even really like, I'd personally rather write C# but I don't write application code here so it doesn't matter) instead of making them write C#. - The legacy stuff isn't being rewritten. It's going to be ported to Linux, using Microsoft's own CoreCLR. Parts will be broken out into their own services in order to directly scale them and make it easier to provide separation of concerns; whether it gets rewritten or just parted out is an engineering decision, but so far they seem content to part out legacy code instead of rewrite. - I'm a DevOps guy. I automate. And you can automate a lot more, to go a lot faster, in a Linux environment. Chef's made strides in Windows, and that's honestly and truly cool, but it's only a first step. There's a reason that most devops folks I know have settled on disposable architectures, where a config change means that the machine should be canned: it reduces ambiguity by removing convergence in favor of guaranteed state. This is extremely difficult in Windows because of the amount of drag induced by the tooling. It takes literally-literally twice as long to bake a Windows Vagrant box as it does a Linux one--I've timed it. It takes longer to build a Windows AMI. It takes longer to deploy one, making your auto-scaling groups less responsive. -This company's load patterns are unpredictable enough and spiky enough that there is an actual, no-bullshit need for scaling on the order of seconds, not 5-10 minutes, and you literally can't do that in AWS with Windows (and I don't think you can with Azure, either); containerization technology (ECS, Mesos, whatever) is making it very practical to meet these sorts of response requirements. - Languages must be approved; right now it's just Node and Mono (soon to be CoreCLR), but the build environments (both through Chef and, later, through Docker) support multiple languages. To use something else, one will have to make their case. But instead of assuming a certain level of professional rigor, you started frothing and assuming everything would be written in whatever struck somebody's fancy. Seriously: fanboy harder. It's clearly working.

fr0styMatt2 11y ago

Why oh why oh why did I have to think about Visual SourceSafe ever again? :P

verinus 11y ago

funny thing is I don't think that the tools or libs are still far from perfect: - WPF tooling is severely lacking in regard to databindings. - libs such as collection classes were far from java standards when release- there is even a pretty good OSS alternative: C5 - there is no standard for filepaths in .Net but even there a good OSS alternative exists: NDepend Path but I see a lot of improvement in the last years: Rx, ReactiveUI, NuGet, FAKE and much more high quality OSS is beeing created.

mistermann 11y ago

> when I can write three lines of code in a version of F# that shipped six years ago and issue SQL-like data gathering queries over everything from Wikipedia to the Department of Labor. What's the name this technology goes by, and is it possible in C# (regardless of if it's extra lines of code)?

tacos 11y ago
F# type providers. Quick entry point: http://tomasp.net/blog/fsharp-data.aspx/ http://tomasp.net/blog/fsharp-data.aspx/ It's kinda awesome. C# provides similar (but somehow less fun) stuff via LINQ providers. Search "LINQ to [noun]" and you'll find plenty of open source code.