It's great to see the HN community responding positively to news about .NET/Mono and related tech. I've been working with C#/.NET since 2008 and always felt it's a vastly superior platform to Java in every way. It's a shame it is taking so long for the wider tech community to realise this.
As an outsider (largely worked with PHP/Java codebases, recently started C#/.NET Core), the naming conventions are awful. I'm still not sure what the differences are between:
* ASP.NET
* .NET MVC
* .NET 4.5
* .NET WCF
* WPF
It's a nebula of names, but I've been ridiculously productive while trying to grasp .NET core. I'm currently trying to make a job to take DB data and dump it on Elasticsearch. It honestly feels like PHP7 with async, it's great
It basically comes down to named groupings of assemblies. They are really just marketing terms. I consider the .NET Framework to encompass all .NET assemblies shipped by Microsoft in the System and sometimes Microsoft namespaces. The ones you listed are simply groupings that Microsoft considers important enough to create project templates for, have forums dedicated to each, produce examples for, etc.
Interesting that you miss checked exceptions. Is one of the most criticized feature of the language, see Does Java need Checked Exceptions? [0]. Also in this discussion between Anders Hejlsberg and Bruce Eckel they are discussing why C# did not adopt them: The Trouble with Checked Exceptions [1]. Also Java theory and practice: The exceptions debate [2] discusses the more on the topic.
I've spent the two halves of my career thus far working on each stack, and I really can't see where those sorts of claims come from, honestly. C# as a language is a win over Java, but from an operational perspective, it's a disaster--IIS is an absolute nightmare. Beyond that, I tend to think that because of the niceties that C# has over Java, that has somewhat held back .NET community adoption of some better practices (specifically immutability).
All that said, .NET Core is a huge win on the operational side of things, so it's definitely moving in the right direction.
Curious to know why you think WebSphere is a pain - I find it about as good as any complicated piece of software can get - it's reasonably documented, works most of the time and performance is good.
Ah older versions. I started extensively working on WebSphere 7.5 onwards - in a course reversal with 8.5 one of our deployment which works fine with Oracle JVM spins the CPU 100% when ws uses J9 and that one ships with broken jconsole and missing jstack that does not want to connect to the spinning process! Joys of enterprise software..
I've also spent two halves of my career on each and I recently had to do a project that involved building a data pipeline on Azure. All of the C# pieces (HTTP endpoint, event consumer) were written in C# and deployed at Azure App Service/Cloud Services. I could have easily deployed the code in Docker containers running Linux, but the App/Cloud service deployment is very nice and abstracts the entire web server (Kestrel) away.
Anyway, I agree that operationally .NET has struggled, and of course the community was much different than other open source solutions, but it both have gotten much, much better in just the last few years.
IIS was really bad (has gotten better), but I don't see most Java EE stacks being much better.
At my last job we had two teams, one had a .NET stack, and the other had a Java EE stack, it was almost like someone had set up a lab to test which one was better (both were required to deliver very similar style LOB applications, one for one department and the other for another).
The .NET team consistently delivered a lot more value faster, and the Java deliverables always had reliability problems which they attributed to the JBoss setup. To be fair, the Java side was hampered by an "old-school" architect who refused to use the right tools for the job (even on the Java side, there are pretty decent frameworks and IDEs).
Can you elaborate on what makes IIS a nightmare? What version(s) are you referring to? What other HTTP servers are you using as your basis for comparison?
Java don't have async/await, but .NET already has it for years. Lambda expressions for Java were also released many years after C#. I prefer properties in .NET comparing to getter/setter functions in Java. There are other advantages of C#, just check tread about this on stackoverflow.
I’m sad about the name of applyPatches. If it’s something that should never be needed and is a security risk, it should have a dangerous name and/or value. e.g. make it a string value that needs to be exactly "No, even though I know that this is a bad idea and promotes insecurity; I have read http://example.com/ and really need this." to turn off patches.
It's a good start, lot of things work, lots doesnt.
Is for early adopters but it's not bleeding edge anymore i think. Not ready for production
F# using .net core sdk from command line works (new, restore, build, run, test, publish) like c#.
xplat is ok where .net core is supported, so osx/ubuntu/win/docker.
Docs need some improvements, but lots are language agnostic, or c# examples help (docs are open source, if someone want to help).
Important wip or not implemented yet feature of compiler/language:
- type providers
- portablepdb for enable debugging
- f# repl
The f# libraries in ecosystem are starting to support .net core (netstandard), like FSharp.Compiler.Services (the compiler as library), Suave ( github.com/SuaveIO/Suave-CoreCLR-sample ), Argu, Fable. These are not hello world examples, so it works. Some are in prerelease, but it's expected because it's a new framework/tooling and need testing.
There are only few libraries of the f# ecosystem who support .net core, but it's expected because is a bootstrapping issue in lot of cases (i need to wait .net core support for my dependencies add support..)
Obv it's possibile to use all others .net libraries who support .net core (netstandard) like the BCL, Kestrel, etc.
As editor, vscode has the best support using usual the amazing Ionide plugin for f# (who already give f# support for .net and mono). Intellisense, build, run is ok but not debugging.
Using Visual studio, only build/run works (xproj and project.json), but not intellisense or debugging.
If you want to chat there are two good f# slack groups
- #dotnetcore in fsharp.org slack (other chan too)
Not yet, there's been a lot of progress in the past 6 months but unless more people get involved with the port work it's probably going to be another year at least before it's actually usable.
30 comments
[ 3.3 ms ] story [ 79.3 ms ] threadEven now when I tell some people that .NET is very simple, fast and runs on osx/linux they are like "Really!? No way bla bla."
* ASP.NET
* .NET MVC
* .NET 4.5
* .NET WCF
* WPF
It's a nebula of names, but I've been ridiculously productive while trying to grasp .NET core. I'm currently trying to make a job to take DB data and dump it on Elasticsearch. It honestly feels like PHP7 with async, it's great
* ASP.NET = Web subsystem of the .NET framework.
* ASP.NET MVC = MVC framework that is part of ASP.NET (not ".NET MVC")
* WCF = Communications subsystem of the .NET framework (not ".NET WCF")
* WPF = Presentation layer subsystem of the .NET framework
1. The compiler checks for exceptions being thrown and and makes you write a catch.
2. Anonymous inner classes.I prefer even handlers, but would still like this feature.
I think c# does a good job of always adding features that make it easier to write code.
[0] http://www.mindview.net/Etc/Discussions/CheckedExceptions/
[1] http://www.artima.com/intv/handcuffs.html
[2] https://www.ibm.com/developerworks/library/j-jtp05254/
All that said, .NET Core is a huge win on the operational side of things, so it's definitely moving in the right direction.
Websphere is such a pain to use, yet it still is everywhere on enterprise projects.
It is the typical enterprise software suitable to sell consulting experience in what concerns configuration and management.
Endless list of configuration options, some of them only available via scripting and best of all IBM J9 specific features.
One of the issues we once had around 2006 was that our entity beans stubs would only work properly if compiled via J9.
Anyway, I agree that operationally .NET has struggled, and of course the community was much different than other open source solutions, but it both have gotten much, much better in just the last few years.
At my last job we had two teams, one had a .NET stack, and the other had a Java EE stack, it was almost like someone had set up a lab to test which one was better (both were required to deliver very similar style LOB applications, one for one department and the other for another).
The .NET team consistently delivered a lot more value faster, and the Java deliverables always had reliability problems which they attributed to the JBoss setup. To be fair, the Java side was hampered by an "old-school" architect who refused to use the right tools for the job (even on the Java side, there are pretty decent frameworks and IDEs).
Is F# support ready for Prime Time?
It's a good start, lot of things work, lots doesnt.
Is for early adopters but it's not bleeding edge anymore i think. Not ready for production
F# using .net core sdk from command line works (new, restore, build, run, test, publish) like c#.
xplat is ok where .net core is supported, so osx/ubuntu/win/docker.
Docs need some improvements, but lots are language agnostic, or c# examples help (docs are open source, if someone want to help).
Important wip or not implemented yet feature of compiler/language:
- type providers
- portablepdb for enable debugging
- f# repl
The f# libraries in ecosystem are starting to support .net core (netstandard), like FSharp.Compiler.Services (the compiler as library), Suave ( github.com/SuaveIO/Suave-CoreCLR-sample ), Argu, Fable. These are not hello world examples, so it works. Some are in prerelease, but it's expected because it's a new framework/tooling and need testing.
There are only few libraries of the f# ecosystem who support .net core, but it's expected because is a bootstrapping issue in lot of cases (i need to wait .net core support for my dependencies add support..)
Obv it's possibile to use all others .net libraries who support .net core (netstandard) like the BCL, Kestrel, etc.
As editor, vscode has the best support using usual the amazing Ionide plugin for f# (who already give f# support for .net and mono). Intellisense, build, run is ok but not debugging.
Using Visual studio, only build/run works (xproj and project.json), but not intellisense or debugging.
If you want to chat there are two good f# slack groups
- #dotnetcore in fsharp.org slack (other chan too)
- #fsharp in fpchat.com