Milestone: Half a million downloads for VideoLAN packages in the .NET ecosystem(mfkl.github.io)
mfkl.github.io
Milestone: Half a million downloads for VideoLAN packages in the .NET ecosystem
https://mfkl.github.io/2021/01/13/half-a-million-downloads.html
71 comments
It’s nice to see .NET get some coverage now and again. It’s not regarded as the cool kid on the block but it just continues its quiet steady climb in ergonomics and performance year on year. I find c# to be a great language to build very large corporate applications in. I’ve never spotted an instance where something has been rewritten in a different language because c# was lacking in some way. Maybe it’s because the applications were too big to rewrite but maybe because it is very forgiving to change.
For whatever it's worth, I've been a .NET developer since 2001 when I was finishing up college. I've also dabbled in Java, and some other languages here and there for one-off work and side-work projects. I haven't found anything to match C# & .NET's productivity. I gravitate towards strongly-typed languages which I know excludes a large swath of productive languages.
.NET Core is fantastic. I recently bought an M1 Macbook Air (which I really hadn't wanted to do but my Intel Macbook died and I wasn't about to buy another Intel Mac given they are being phased out.) There's one issue in that debugging is broken at the moment, but it's being addressed by Apple/MS. Docker (M1 Preview) works great.
If you've never given .NET a shot because you weren't/aren't a fan of Microsoft/Windows - I recommend you give it try, you might be pleasantly surprised.
.NET Core is fantastic. I recently bought an M1 Macbook Air (which I really hadn't wanted to do but my Intel Macbook died and I wasn't about to buy another Intel Mac given they are being phased out.) There's one issue in that debugging is broken at the moment, but it's being addressed by Apple/MS. Docker (M1 Preview) works great.
If you've never given .NET a shot because you weren't/aren't a fan of Microsoft/Windows - I recommend you give it try, you might be pleasantly surprised.
I was a Linux/Mac only power user until my first role as a software engineer, where my employer was a Windows and .NET shop (the .NET 1.1/2.0/3.5 days).
Hadn’t used Windows in years and that was my first exposure to PowerShell, which made me feel a little better about Windows.
Grew to greatly appreciate C# and .NET over the years and am now fairly optimistic that Microsoft has made a lasting change after seeing the steady, dramatic improvements that they’ve been making technologically and sociologically (embracing open source, cross-platform support, and putting their money where their mouth is).
Highly recommend that curious people install Windows 10 on an external HDD to try out WSL, Windows Terminal, and PowerToys Fancy Zones. I use Linux for my personal machines, still, but Fancy Zones has honestly had me missing the ease of desktop layout when I switch off my work machine.
Or, if you are just looking to explore C# and the dotnet ecosystem, then you can do that from the command line on most non-BSD operating systems.
Hadn’t used Windows in years and that was my first exposure to PowerShell, which made me feel a little better about Windows.
Grew to greatly appreciate C# and .NET over the years and am now fairly optimistic that Microsoft has made a lasting change after seeing the steady, dramatic improvements that they’ve been making technologically and sociologically (embracing open source, cross-platform support, and putting their money where their mouth is).
Highly recommend that curious people install Windows 10 on an external HDD to try out WSL, Windows Terminal, and PowerToys Fancy Zones. I use Linux for my personal machines, still, but Fancy Zones has honestly had me missing the ease of desktop layout when I switch off my work machine.
Or, if you are just looking to explore C# and the dotnet ecosystem, then you can do that from the command line on most non-BSD operating systems.
I was impressed with wsl recently. I had to compile a distribution for an embedded linux board we're going to use. And under wsl it just worked.
I actually just picked up .NET when 5 came out and have been working on a project and have been blown away how great not only is the ASP.NET Core framework but also the C# language.
Powerful, consistent, feature-rich. Coming from a python, java, web background, was really blown away. Wish more people would give .NET a chance. It isn't like it used to be when I first tried it in College and hated it.
Powerful, consistent, feature-rich. Coming from a python, java, web background, was really blown away. Wish more people would give .NET a chance. It isn't like it used to be when I first tried it in College and hated it.
I don't think there's hatred for the ecosystem, it's just one that you don't get to see unless you're exposed to it by chance or pushed into it for a specific reason.
.NET is in the corporate world but you'll have a harder time finding a .NET-related job if you don't already know stuff about it.
Since I don't currently use windows and I don't casually want to build a corporate type of software on another system in my free time (I'd much rather fold some origami, I'm likely one of the people that aren't called "passionate" about dev), I didn't get to be exposed to it easily - unlike "typical" web and mobile-related languages for example (Java, Obj-C/Swift, JS). Some of it might have been shown when I was a student (Java), and other things are just requirements of the times (I want to try making a mobile app -> either web or native languages). Didn't see .NET at university, and early jobs didn't involve that, so now it feels like a missed train somehow.
Is it worth focusing on when you're not already living in that ecosystem and you're on your own?
.NET is in the corporate world but you'll have a harder time finding a .NET-related job if you don't already know stuff about it.
Since I don't currently use windows and I don't casually want to build a corporate type of software on another system in my free time (I'd much rather fold some origami, I'm likely one of the people that aren't called "passionate" about dev), I didn't get to be exposed to it easily - unlike "typical" web and mobile-related languages for example (Java, Obj-C/Swift, JS). Some of it might have been shown when I was a student (Java), and other things are just requirements of the times (I want to try making a mobile app -> either web or native languages). Didn't see .NET at university, and early jobs didn't involve that, so now it feels like a missed train somehow.
Is it worth focusing on when you're not already living in that ecosystem and you're on your own?
I think you're right about the separation of ecosystems into .NET vs. everything else. I often idly run a find-in-page for .NET/C# on the Who's Hiring threads just to monitor uptake in the start-up world and rarely get more than about 6 hits in 100s of posts.
I ended up in a C# role by chance coming from a non-software background and it can often feel like a separate world; so many discussions in the other ecosystems just feel less relevant since C# is so batteries included you rarely have to venture outside the confines of the officially mandated environment.
While there's a lot of stuff in the corporate environment on Windows servers and old full-framework code there's also a healthy and growing Linux first community using .NET.
I don't know that I'd recommend it particularly from outside if not trying to start a .NET role specifically, I don't think (based on the languages you list having experience with) it will help you learn anything particularly new, in the way that learning a functional language does for someone with an OOP background. Though LINQ is quite a nice way for people unfamiliar with functional programming to ease into it from an OOP environment.
With .NET 5 / dotnet core the getting started is easier than it used to be (thanks to dotnet new https://dotnet.microsoft.com/learn/dotnet/hello-world-tutori...) and a lot more like other languages/frameworks, but without a specific aim I think it's going to be hard to be motivated to get in-depth with the environment.
To be clear I wouldn't want to work in any other language or framework (though React with functional components and TypeScript comes pretty close to the developer experience quality of C#/.NET) but I'm just not sure how porous the ecosystem boundary is and how transferable the skills are.
I ended up in a C# role by chance coming from a non-software background and it can often feel like a separate world; so many discussions in the other ecosystems just feel less relevant since C# is so batteries included you rarely have to venture outside the confines of the officially mandated environment.
While there's a lot of stuff in the corporate environment on Windows servers and old full-framework code there's also a healthy and growing Linux first community using .NET.
I don't know that I'd recommend it particularly from outside if not trying to start a .NET role specifically, I don't think (based on the languages you list having experience with) it will help you learn anything particularly new, in the way that learning a functional language does for someone with an OOP background. Though LINQ is quite a nice way for people unfamiliar with functional programming to ease into it from an OOP environment.
With .NET 5 / dotnet core the getting started is easier than it used to be (thanks to dotnet new https://dotnet.microsoft.com/learn/dotnet/hello-world-tutori...) and a lot more like other languages/frameworks, but without a specific aim I think it's going to be hard to be motivated to get in-depth with the environment.
To be clear I wouldn't want to work in any other language or framework (though React with functional components and TypeScript comes pretty close to the developer experience quality of C#/.NET) but I'm just not sure how porous the ecosystem boundary is and how transferable the skills are.
I have a rather dumb question about C#.
A skillion years ago I had to do a .NET project and somewhat randomly chose VB.NET as the language over C#. However, I did buy some C# books which I never looked at. Given that the books are now about a decade old, is there any point in keeping them? Has C# changed enough in the years that the language is sufficiently different from what was created in the book that I might as well pick up a newer volume?
I tend to gravitate toward stability in languages. Something of a flaw of mine.
A skillion years ago I had to do a .NET project and somewhat randomly chose VB.NET as the language over C#. However, I did buy some C# books which I never looked at. Given that the books are now about a decade old, is there any point in keeping them? Has C# changed enough in the years that the language is sufficiently different from what was created in the book that I might as well pick up a newer volume?
I tend to gravitate toward stability in languages. Something of a flaw of mine.
A lot of language features have been added over the years so you'll be missing out on some great stuff.
Also some libraries changed around a bit during the transition to .net core, so some the code in your book may not compile.
Finally, if it's a book about web dev (asp.net) or something similar (mobile dev, game dev), that stuff has changed a lot over the past ten years.
You're probably best of ditching the books and hitting up some tutorials or checking with your local library. My public library gives us access to safari books online which has a large selection of technical books.
Also some libraries changed around a bit during the transition to .net core, so some the code in your book may not compile.
Finally, if it's a book about web dev (asp.net) or something similar (mobile dev, game dev), that stuff has changed a lot over the past ten years.
You're probably best of ditching the books and hitting up some tutorials or checking with your local library. My public library gives us access to safari books online which has a large selection of technical books.
A decade ago puts you at .NET Framework 4.0 or so, and C# version 4. A lot has changed since then. While your old books would still be somewhat relevant, you are missing out on a lot of new features in both C# and .NET. Especially since depreciation of .NET Framework and the transition to .NET 5.
To add to this, C# added async/await in 2012. Depending on what frameworks you use it may be hard to avoid interacting with it (for example, many APIs in UWP are async without a sync version). I feel like other language features added since then you can get away without knowing while writing code, but of course you may encounter them when reading other’s code.
That being said, C# 5 code can be retrofitted with most new features simply by listening to the IDE which suggests refactorings to make use of them.
Similar experience here. I switched OSes a few times but I never let go C# even when the multiplatform story was subpar. Now with dotnet core (.net 5) it’s really a joy to work with everywhere (even of VS Code is no match to the real thing).
Agree, when it comes to desktop development (WinForms, WPF). But once I saw some Web API stuff, there is just too much of a ceremony and boilerplate, no?
When compared to Python or Elixir web frameworks? Yeah, there's more ceremony. To anything else? Not really. Some people don't like heavy and pretty much required usage of dependency injection in .NET world but I never really understood those arguments.
The ceremony and boilerplate got reduced a bit with the newer versions of ASP.NET - you can definitely write clean looking WebAPI code without much ceremony.
The newer idea of middleware pipelines in ASP.NET do a good job of hiding some boilerplate and there are even libraries like Flurl or Polly (which is now officially a part of .NET, itself) that reduce the code you have to write for things like http requests and resilience policies.
The newer idea of middleware pipelines in ASP.NET do a good job of hiding some boilerplate and there are even libraries like Flurl or Polly (which is now officially a part of .NET, itself) that reduce the code you have to write for things like http requests and resilience policies.
At the risk of starting a language flame-war: if I were starting a new company or effort, my default choice would be .NET Core.
Performance is generally great and if you need to, there are lots of features in the language to allow you to further squeeze performance. C# is easy to pick up and has best-of-breed IDE support- you will get productive quickly. Also, you have an extremely large standard library at your disposal that is supported and dogfooded by Microsoft. Which is great because generally you do not need to install third party packages, but if you do NuGet is really easy to use.
Edit: Forgot to mention the stellar documentation provided by Microsoft.
Performance is generally great and if you need to, there are lots of features in the language to allow you to further squeeze performance. C# is easy to pick up and has best-of-breed IDE support- you will get productive quickly. Also, you have an extremely large standard library at your disposal that is supported and dogfooded by Microsoft. Which is great because generally you do not need to install third party packages, but if you do NuGet is really easy to use.
Edit: Forgot to mention the stellar documentation provided by Microsoft.
The documentation is the best feature of the entire platform. If Microsoft hadn't published that deep-dive document regarding Blazor hosting models [1], I probably would have not given the technology a deeper look. But, after reading through and comparing the pros/cons of server-side vs client-side, it made it very clear to me that this was an approach that would be a really good fit for us (we went with the server-side model).
My 2nd favorite feature is Self-Contained Deployments [2]. We skipped the whole containerization party because this approach completely obviated our need for such things.
Beyond that, being able to seamlessly transition between imperative & functional members within the same type, pattern matching in switch statements [3], on-going awesomeness of LINQ, etc. Really great stuff to work with.
[1] https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
[2] https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
[3] https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match...
My 2nd favorite feature is Self-Contained Deployments [2]. We skipped the whole containerization party because this approach completely obviated our need for such things.
Beyond that, being able to seamlessly transition between imperative & functional members within the same type, pattern matching in switch statements [3], on-going awesomeness of LINQ, etc. Really great stuff to work with.
[1] https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
[2] https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
[3] https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match...
Not a new company but rebooting an existing and am using .net. Being able to run on Google Cloud Run is awesome.
FYI it's simply called .NET now, as of the release of .NET 5. Which is the successor to .NET Core 3.1.
With the existing volume of .NET Framework applications floating around, many of us find the need to be more precise in the specific framework we are talking about. Our shop still has a few tools that we haven't ported over yet.
[deleted]
Agreed, and after a shakey start .NET Core is really delivering. It's trivial now to use any CI to build docker images of .NET core apps and deploy like any other docker container. Performance is great and I'm a huge fan of the big stdlib, which means less fragmentation and churn relying on packages for quite basic behaviour.
The only thing I'm not entirely sure about is the recent direction of C# to add loads and loads of syntactic sugar, which reduces the amount of code you have to write but I find the code becomes so terse it's hard to glance and reason with, but that may be just because it's quite new.
The only thing I'm not entirely sure about is the recent direction of C# to add loads and loads of syntactic sugar, which reduces the amount of code you have to write but I find the code becomes so terse it's hard to glance and reason with, but that may be just because it's quite new.
Yes the big stdlib is the secret sauce. c# is great but the framework offers so much. Imagine taking a non trivial 5 year old javascript project and upgrading it .. but with .NET that is well written to use the framework features it's often quite achievable. I've upgraded a number recently and mostly it's been quick and successful. Because of the sensible stdlib!
I’m excited about Blazor and compiling dotnet to WebAssembly. There are some newer Blazor libraries built with the goal of having {no|minimal} JavaScript being written by application and web developers.
Of course, there’s lots of room to grow towards that goal.
Of course, there’s lots of room to grow towards that goal.
To the contrary, I think it makes the code easier to understand. The syntactic sugar that gets added to C# is almost universally driven through studying extant usage and codifying common patterns. Instead of jumping through flaming hoops of boilerplate code to make, say, asynchronous network requests work, there is now a specific syntax for sequencing asynchronous calls that keeps related code more closely related in the source.
Specific syntax for patterns makes intention more clear, and shifts responsibility for getting it right from the developer to the compiler.
Specific syntax for patterns makes intention more clear, and shifts responsibility for getting it right from the developer to the compiler.
I'm with you on the terseness. I've been finding myself asking people to be "clear, not clever" with usage of some of the sugar, whereas previously adopting new syntax hasn't been so much of a challenge. It's definitely a balancing act between being easy to read and causing the reader to have to context switch while reading. Most of the sugar in C# hits all the right spots though.
I have no doubt that some of this newer syntax is clever, and very welcome to many, but not everyone will realize that it's far more beneficial in the long term to cater to the common denominator.
I have no doubt that some of this newer syntax is clever, and very welcome to many, but not everyone will realize that it's far more beneficial in the long term to cater to the common denominator.
I think everyone just has to accept that
if (expression is {} val)
Is the right way to code, even if it looks ugly.
if (expression is {} val)
Is the right way to code, even if it looks ugly.
> C# to add loads and loads of syntactic sugar
well some is necessary. example: init-only-Setter, was impossible to do before. You could not write the same Code, without it. No matter what you did.
using declarations where also necessary to increase readability.
and nullable reference types also were important!
well some is necessary. example: init-only-Setter, was impossible to do before. You could not write the same Code, without it. No matter what you did.
using declarations where also necessary to increase readability.
and nullable reference types also were important!
You could use an explicit private readonly field and a property getter, or even just a public readonly field. I would argue its only sugar.
Are you referring to the init only setters?
If so, it isn’t just sugar, they added a new hook for it in the internals, rather than just relabelling a technique to accomplish a similar (but not equal) end.
If so, it isn’t just sugar, they added a new hook for it in the internals, rather than just relabelling a technique to accomplish a similar (but not equal) end.
It doesn't scale that well, as you need ctor parameters for every property, so API additions may also be breaking changes.
well that would be different to instantiate tough.
it would be Class(1, 2, 3) instead of
Class {
Value1=1,
Value2=2,
Value3=3,
}
actually record types are more syntactic sugar around what you said than initonly, which opens up a new way of writing code
actually record types are more syntactic sugar around what you said than initonly, which opens up a new way of writing code
A great deal of the “loads and loads of syntactic sugar” serves the purposes of making C# more functional-friendly. You might explore the new features from that paradigm, to help you reason about it.
Do you have any pointers on a gentle introduction to docker and kubernetes in the .net world? Most of the docs seem to be tuned to Linux ecosystems... which makes sense given the heritage.
I’d recommend embracing it: the Microsoft Linux .NET containers are solid. It’s not that hard writing .NET code on Windows and deploying to Linux containers.
I work for a large Unnamed Parcel Service, we've got a ton of legacy applications on pretty much every platform you could name from the last 50 years. But all our new application are .Net Core in Linux containers running on Azure Kubernetes Service.
I'm really only using it on Linux. VS and VSCode (with the Docker and .NET plugins) can generate docker files with one click/command for .NET projects, which also use the right dlls from your project as entrypoints, etc.
From that it's just standard Docker - it doesn't matter that you are running .NET core in it really. You can do anything you could normally in Docker and K8S.
From that it's just standard Docker - it doesn't matter that you are running .NET core in it really. You can do anything you could normally in Docker and K8S.
> but it just continues its quiet steady climb in ergonomics and performance year on year
I've seen people say one of Java's biggest benefits is being boring and staying consistent. I disagree. C# (sometimes all of .Net) consistently adds new features that keep the language feeling modern. Properties are a great example.
The big thing I'd love to see in C# now is sum types, but I'm not holding my breath.
I've seen people say one of Java's biggest benefits is being boring and staying consistent. I disagree. C# (sometimes all of .Net) consistently adds new features that keep the language feeling modern. Properties are a great example.
The big thing I'd love to see in C# now is sum types, but I'm not holding my breath.
Their adding of the functional-friendly “record” type in C# 9, along with the “with” statement, was huge for me.
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/exp...
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/exp...
It's a very productive ecosystem. It doesn't have the same level of enterprise factory wartiness that Java does; its Windows IDE is extremely integrated; it lets you write functional-ish code in an imperative environment; and it has LINQ, which is fantastic.
Having cut my teeth on C++ and being reasonably familiar with Python, I'll choose C# for anything larger than a script that doesn't need direct memory layout control.
Deployment story is still a bit of a pain sometimes.
Having cut my teeth on C++ and being reasonably familiar with Python, I'll choose C# for anything larger than a script that doesn't need direct memory layout control.
Deployment story is still a bit of a pain sometimes.
> I’ve never spotted an instance where something has been rewritten in a different language because c# was lacking in some way.
The truth is, languages rarely have an impact on the success or failure of a project. The reason some companies blame failure on language is because the organization fails to adequately adapt its procedure to the tools it uses.
Starting on a fresh language and not getting involved in the community because a dozen pizza to host a meetup every 3-4 months is too expensive? You're headed for trouble.
Going for a new stack and letting poor management drive away the team? Even with a mainstream language, the hit you're going to take is going to be huge.
Willing to rewrite old code but not interested in giving people time to adapt and learn? Good luck.
The only difference between languages like Java or C# and Clojure or F# is that it's much harder to blame the former for organization/process issues.
I'm not saying that languages don't have an effect on productivity or dev experience, I'm saying that effect is way less important than other factors, and as a consequence, it's rarely the factor that tips the scale.
The truth is, languages rarely have an impact on the success or failure of a project. The reason some companies blame failure on language is because the organization fails to adequately adapt its procedure to the tools it uses.
Starting on a fresh language and not getting involved in the community because a dozen pizza to host a meetup every 3-4 months is too expensive? You're headed for trouble.
Going for a new stack and letting poor management drive away the team? Even with a mainstream language, the hit you're going to take is going to be huge.
Willing to rewrite old code but not interested in giving people time to adapt and learn? Good luck.
The only difference between languages like Java or C# and Clojure or F# is that it's much harder to blame the former for organization/process issues.
I'm not saying that languages don't have an effect on productivity or dev experience, I'm saying that effect is way less important than other factors, and as a consequence, it's rarely the factor that tips the scale.
> I’ve never spotted an instance where something has been rewritten in a different language because c# was lacking in some way.
Yes, that is what killed F# effectively - on top of not having any killer frameworks. Though to be fair even Scala is dead. Making a language popular is tough.
Yes, that is what killed F# effectively - on top of not having any killer frameworks. Though to be fair even Scala is dead. Making a language popular is tough.
> that is what killed F# effectively
F# has been an unwanted child of Microsoft, it actually adopted the language from Microsoft Research. As a language, F# is _very_ good (although not as good as the original OCaml, whose features had to be cut to be able to run on CLR). It's just not first-class citizen, so not everything may work with F#. And F#'s own development and features are blocked on CLR -- instead of F# charting its own path, each feature first has to be available for C#/CLR and only then will F# developers implement it (higher-kinded types are just one example).
But it's still much more pleasant "syntactic sugar to write the CIL bytecode" than C# can ever be.
> even Scala is dead
I beg to differ! Thankfully, Scala is very much not dead. Scala 3 is around the corner, with many more features and, even more importantly, several simplifications. And the community is also much larger compared to F# (or any other ML language, like Haskell). Innovation also takes place in the realm of libraries, like ZIO for example.
F# has been an unwanted child of Microsoft, it actually adopted the language from Microsoft Research. As a language, F# is _very_ good (although not as good as the original OCaml, whose features had to be cut to be able to run on CLR). It's just not first-class citizen, so not everything may work with F#. And F#'s own development and features are blocked on CLR -- instead of F# charting its own path, each feature first has to be available for C#/CLR and only then will F# developers implement it (higher-kinded types are just one example).
But it's still much more pleasant "syntactic sugar to write the CIL bytecode" than C# can ever be.
> even Scala is dead
I beg to differ! Thankfully, Scala is very much not dead. Scala 3 is around the corner, with many more features and, even more importantly, several simplifications. And the community is also much larger compared to F# (or any other ML language, like Haskell). Innovation also takes place in the realm of libraries, like ZIO for example.
F# died?
And here I am happily using it for greenfield projects, interfacing with popular ecosystems and just generally getting things done!
Right now it really feels like F# is taking off. It is bundled with .NET Core, fully open-source, has a better REPL experience with Nuget integration, Ionide and Fable just had a new releases...
And here I am happily using it for greenfield projects, interfacing with popular ecosystems and just generally getting things done!
Right now it really feels like F# is taking off. It is bundled with .NET Core, fully open-source, has a better REPL experience with Nuget integration, Ionide and Fable just had a new releases...
What killed F# was Microsoft never putting enough internal resources on it. It's been consistently an afterthought in various releases of VS, initial .NET Core support, etc. As a C#/.NET Dev for 20 years, I've tried several a few times to use F# only to find broken tooling, lousy IDE support in VS (compared to C#, etc.) Jetbrains Rider supposedly has better F# support, but given Microsoft's lack of interest and a tiny community, I still can't be bothered to pick it up. I'm more likely to learn/use Elixir than F# at this point.
FWIW I keep hearing about F# all the time. From where I sit, there is still a lot of enthusiasm around it. It does not seem dead at all. Is there not a lot of interop between F# and C#/dotnet?
Usage of C# packages from F# is simple and without issues. The other way is a bit more clunky, but frankly, you will not want to write any C# once you are on the F# side.
I have been programming in F# full time for the past 7 years and I hope that rumours of its death are greatly exaggerated. Perhaps this comes from a point of view that if something is not growing 10x each year is dead?
It's not a JavaScript framework that has an average lifespan of a couple of years. It's a fully featured, complete, very productive language that makes programmers life easier and more enjoyable.
I have been programming in F# full time for the past 7 years and I hope that rumours of its death are greatly exaggerated. Perhaps this comes from a point of view that if something is not growing 10x each year is dead?
It's not a JavaScript framework that has an average lifespan of a couple of years. It's a fully featured, complete, very productive language that makes programmers life easier and more enjoyable.
I wonder how much of the "death reports" are also just that F# is one of Microsoft's original successful invites for open source community contribution. It was so successful that some months the majority of Github contributions to F# come from outside of Microsoft and that can appear "dead" for "Microsoft officially supports this" rather than a sign that the project is healthy and seeing a lot of community love.
F# and C# packages are compatible.
F# is alive and well and is a historical and contemporary source of new C# language features.
I stopped using it recently, as I found out Microsoft still isnt serious when it comes to privacy. The DotNet tool currently silently checks for updates, without any way to opt out:
https://github.com/dotnet/templating/issues/2739
https://github.com/dotnet/templating/issues/2739
And some of those was my team and our CI. We were capable of replacing old hand-written video player based off DirectX.net in an enterprise app - mainly due to new requirements for supported codecs and video formats. No more list of codecs and installation order on target machines.
It was very easy to integrate - I've finished a POC with a lot of functionality rebuilt in just around 2 hours.
We had two issues that we spent quite some time on, though: 1. When jumping a lot from video part to video part, especially if reading movie files from NAS, we've seen the component hanging - the only way to automatically recognize it hanged was to parse warning logs and restart the component forcibly. 2. Lack of native per-frame backwards movement. It is video player, not video editing component, and there is only a way to move backwards a few frames at a time by slowly changing current position.
It was very easy to integrate - I've finished a POC with a lot of functionality rebuilt in just around 2 hours.
We had two issues that we spent quite some time on, though: 1. When jumping a lot from video part to video part, especially if reading movie files from NAS, we've seen the component hanging - the only way to automatically recognize it hanged was to parse warning logs and restart the component forcibly. 2. Lack of native per-frame backwards movement. It is video player, not video editing component, and there is only a way to move backwards a few frames at a time by slowly changing current position.
2 is a problem in their app as well. They explain that due to how they decode the file it’s not possible. I’m assuming it’s got to due with a decision that was made years ago in the architecture and would just be too costly to change today.
For an outsider going on .NET's website is confusing. For one is .NET 5 the same as dotnet? Let's check out the desktop side: https://dotnet.microsoft.com/apps/desktop
I have 4 options, Xamarin, UWP, Winforms, WPF. As non-Windows dev, which option is going to be my best options with the best support in the future? How do these relate to WinUI? Also, what's project Reunion https://docs.microsoft.com/en-us/windows/apps/project-reunio... ?
Let's not forget react-native-for-windows. Where does this fit into the above scheme?
I have 4 options, Xamarin, UWP, Winforms, WPF. As non-Windows dev, which option is going to be my best options with the best support in the future? How do these relate to WinUI? Also, what's project Reunion https://docs.microsoft.com/en-us/windows/apps/project-reunio... ?
Let's not forget react-native-for-windows. Where does this fit into the above scheme?
.NET 5 or what's now called .NET is the final result of the .NET Core/dotnet project which is the "open-sourcification" of the .NET ecosystem and the effective replacement of .NET Framework which could not have been made open-source due to licensing.
As for UI, on Windows, all but WinForms/Xamarin Forms use the same "layout language" called XAML - it's just different ways of distribution/platform compatibility tied to more or less different APIs.
For traditional Windows apps, you would be using WPF and that's what a lot of modern Windows apps are built on. That's probably what you want to use and the Windows apps I've made have been a pleasure to work with, especially due to their hot reloading and design tools.
For "Store" apps, you would be using UWP, which are the "modern UI" apps you see when you use Windows 10. These can run on any Windows 10 version and Xbox One+. You can also make that style of app with WPF by theming it though.
Xamarin is now mostly used for mobile .NET development, but I really can't recommend it nowadays as there's a lot of cruft and documentation, in comparison to the stellar work MS has been doing, is quite lacking. If you need to reuse .NET code in your mobile apps, it's there as a way for you to do that.
As for UI, on Windows, all but WinForms/Xamarin Forms use the same "layout language" called XAML - it's just different ways of distribution/platform compatibility tied to more or less different APIs.
For traditional Windows apps, you would be using WPF and that's what a lot of modern Windows apps are built on. That's probably what you want to use and the Windows apps I've made have been a pleasure to work with, especially due to their hot reloading and design tools.
For "Store" apps, you would be using UWP, which are the "modern UI" apps you see when you use Windows 10. These can run on any Windows 10 version and Xbox One+. You can also make that style of app with WPF by theming it though.
Xamarin is now mostly used for mobile .NET development, but I really can't recommend it nowadays as there's a lot of cruft and documentation, in comparison to the stellar work MS has been doing, is quite lacking. If you need to reuse .NET code in your mobile apps, it's there as a way for you to do that.
> For "Store" apps, you would be using UWP, which are the "modern UI" apps you see when you use Windows 10. These can run on any Windows 10 version and Xbox One+. You can also make that style of app with WPF by theming it though.
"Project Reunion" which has key pieces in .NET 5 (including and especially the new C#/WinRT projection system, which replaces dark/magic .NET internals with NuGet packages) is entirely blurring the line between WPF and UWP. With WinUI 3 you can use all of the modern UI controls in WPF apps (and in WinForms if you're nasty). You can also package WPF apps for the Store, including opting into UWP sandboxing and security models (though not yet far enough that you can run WPF on the Xbox yet). (The ability to package WPF, WinForms, and other Win32 applications has been around for some time, in fact, that's not specifically new. Project Reunion has roadmap features to keep making it a better experience, though.)
> Xamarin is now mostly used for mobile .NET development, but I really can't recommend it nowadays as there's a lot of cruft and documentation, in comparison to the stellar work MS has been doing, is quite lacking. If you need to reuse .NET code in your mobile apps, it's there as a way for you to do that.
Upcoming .NET 6 will see Xamarin merged closer/deeper inside and the cross-platform pieces (currently named Xamarin.Forms and Xamarin.Devices) rebranded MAUI. Presumably that will also involve a lot of spring cleaning out of cruft and upgrades to the documentation. There's also roadmap talk of much more desktop support beyond just mobile (people wanting to share code not just between Android and iOS, but also Windows, macOS, and Linux).
"Project Reunion" which has key pieces in .NET 5 (including and especially the new C#/WinRT projection system, which replaces dark/magic .NET internals with NuGet packages) is entirely blurring the line between WPF and UWP. With WinUI 3 you can use all of the modern UI controls in WPF apps (and in WinForms if you're nasty). You can also package WPF apps for the Store, including opting into UWP sandboxing and security models (though not yet far enough that you can run WPF on the Xbox yet). (The ability to package WPF, WinForms, and other Win32 applications has been around for some time, in fact, that's not specifically new. Project Reunion has roadmap features to keep making it a better experience, though.)
> Xamarin is now mostly used for mobile .NET development, but I really can't recommend it nowadays as there's a lot of cruft and documentation, in comparison to the stellar work MS has been doing, is quite lacking. If you need to reuse .NET code in your mobile apps, it's there as a way for you to do that.
Upcoming .NET 6 will see Xamarin merged closer/deeper inside and the cross-platform pieces (currently named Xamarin.Forms and Xamarin.Devices) rebranded MAUI. Presumably that will also involve a lot of spring cleaning out of cruft and upgrades to the documentation. There's also roadmap talk of much more desktop support beyond just mobile (people wanting to share code not just between Android and iOS, but also Windows, macOS, and Linux).
I have been asking the same question for many years now and there isn't a simple answer. Until now Winforms and WPF seemed reasonable choices for desktop applications. Now that ARM on Windows is becoming a reality maybe Xamarin or UWP (this one is being replaced by Windows UI, or so it seems) are better options. Developing for the Windows desktop has been a guessing game for many years now.
Winforms works with ARM on Windows - as long as you doing it in the context of .NET 5. WPF is coming later this year afaik.
I work at a Windows shop, and every time they roll their eyes at the plethora of Javascript frameworks I just bite my tongue and say "mm hmm". We're looking at tech choices for our future UI development, and we have a large .NET codebase pieces of which we would like to share between desktop and mobile. It is so not a straightforward obvious choice.
Is there a decent Modern C# tutorial or book? I learned it in early 2000's, which was lacking many the new features and syntax improvements.
C# in Depth does exactly what you need, starts from C# 2.0 and cover all new features added in newer versions.
https://www.manning.com/books/c-sharp-in-depth-fourth-editio...
Seconded. Any book I've ever gotten in the "in Depth" series from Manning has been excellent, and this one is no different.
https://docs.microsoft.com/en-us/dotnet/csharp/tutorials/
Has a pretty decent set of tutorials and docs, from basics of the language to nice descriptions of new features like record types or new nullable reference type approach.
Not sure about any books, I strongly prefer to just read through 'What's new in C# X' articles every time a new version comes out.
Essential C# 8.0 - hands down. It is awesome both for beginners and experts. I've read it once, and keep it handy for reference. It's written by some of the most knowledgeable people there are on C#/.NET. I have also read one of the Head First C# books, and found it lacking once I got past the basics.
There's plenty of online resources to learn C#, starting with https://docs.microsoft.com/en-us/learn/dotnet/
If you'd rather have a book, and enjoy the Head First series, the 4th edition of Head First C# will be released on the 26th: https://www.amazon.com/Head-First-Learners-Real-World-Progra...
If you'd rather have a book, and enjoy the Head First series, the 4th edition of Head First C# will be released on the 26th: https://www.amazon.com/Head-First-Learners-Real-World-Progra...
The official "Programming Guide" is very nice: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g.... The docs in general are quite good.
I’d recommend “Functional Programming in C#” to supplement your main reference material.
I regularly use this and love it. The guys did a great job and a great job supporting it too!