.NET Core: Still a Microsoft platform thing despite more than five years open source Key people working on the .NET platform at Microsoft are concerned about the continuing perception that it is tied to one company. "Tell your friends that C# and F# are free, open source and run on Linux and Mac," said Microsoft software architect David Fowler, who works on the design of .NET Core and ASP.NET and is also the …
you're "not wrong".
According to the TIOBE index, which confirms the "5th pace" ranking for July 2020's lingo popularity, C-pound is statistically tied with VB in lingo popularity at 5.25%. C is at 16.1%, having swapped places with Java again (15.1%) as the #1 and #2 lingos, holding steady with this throughout the 21st century.
Here's the thing: when you look at TIOBE's index, you see the top 3 lingos C, Java, Python. C++ is in 4th place and is really just C on steroids, for the most part. And so you say "where do I focus my efforts on mastering programming lingos" and it seems to ME you spend it on the TOP 4 and ignore C-pound.
So, do I spend ALL of my time "learning" and NOT get paid to do work? Do I spend all of my 'at work' time NOT being productive with things that make/save money for the company? How much spare time must I devote to "learn new/shiny lingo of the week"?
When C-pound first came out I used the wizards to generate a 'hello world' type of project. I was so horrified with the results I never looked at it again unless I had no other choice... THAT and being aware it didn't even compile to NATIVE CODE (back then; I think it does, now). The whole idea that it should be like Java and create a P-code [and ALSO require that monolithic umbrella-lib known as ".Net" to run, with shades of VB incompatibilities and installer nightmares from the 90's rapidly running through my head] I made the sign of a cross with my fingers, and commanded it to go straight back to the fiery depths from whence it came...
and even with mono, which evolved (sorta) into ".Not Core", I'm not convinced.
C-pound is like an undead horse, that's been beaten so hard it's no longer dead, it's undead. And therefore it will NEVER DIE... in a creepy not-very-nice kind of way.
@ bombastic bob
Downvoted you because I haven't a clue what you are going on about and life is too short to try to fathom what you mean.
As you always know everything about everything, because you have done everything, I shall just say,
Cheers… Ishy
My first C# (C-sharp) project was a mini ASN.1 DER decoder which i wrote using Mono in the Mono Develop IDE on Linux. It worked fine and also ran on Windows without any need to modify or recompile.
To write in C# was actually fairly pleasant on the whole and I later wrote a whole load of stuff using Visual Studio on Windows including a wrapper around an antique C API with large, complex positional fixed-length strings (well char[] - you know... No 'strings' in C), a reasonably complex interaction with LDAP, and an implementation of a propriety binary display protocol...
The async...await pattern worked really well and allowed me to produce what was, in essence, a highly scalable and very quick search engine of sorts.
Sadly the LDAP class I was using hadn't been implemented in Mono else I think it would have happily run on Linux under Mono.
When I moved on to a Java project I suddenly realised that C# can be summarised as 'like Java but generally nicer'.
These days I work in a Java shop and there's no interest in doing anything with .NET - I'd happily use it again and it is pretty much the only Microsoft branded thing I've ever been known to say is 'good' Vs my normal expletive-ridden rants about how terrible I find just about everything else from MS.
I'd be interested to see how things have progressed since I used it about 5 years ago. A lot has happened: for starters .NET core became a thing.
Personally I felt the one thing that was really missing back then was any kind of cross platform GUI toolkit.
Of course C# is Java only nicer.. they could not get Microsoft Java, so instead they did C#.
The problem is the use case.. Java has its own inertia and just runs almost anywhere.. so it keeps being used.
Oracle ownership is quite bad for Java, so maybe, maybe C# might get some prominence.. by pyton, javascript etc also have their own inertia and use cases.
As for me.. well, I like it, but "uups, thaty is not implemented in mono" etc, just kills it.
Mono and .NET are converging much more, especially now that the .NET versioning nightmare on Windows is finally ending (.NET 5 will be one single API set, regardless of what it runs on. Hurrah! It only took 20 years...). Mono now supports "everything in .NET 4.7 except WPF, WWF, and with limited WCF and limited ASP.NET async stack" according to their own documentation. (https://www.mono-project.com/docs/about-mono/compatibility/)
One good move is that now Microsoft are steering devs away from using the "Windows" flavours of .NET in favour of the ".NET Standard" APIs, the cross-platform API set that Mono implements.
Both .NET and Mono run on Linux, so it's a question of where your priorities are. Mono has better performance compiled down to native binary, while Microsoft's own .NET has a faster JIT runtime. Both support WebAssembly.
Mono did not evolve into .Net Core. Mono is a completely different code base and never shall the two meet. I know this because I was helping port .Net Core 2 over to FreeBSD. They are not the same and share very little (if any) code. From what I could tell at the time, the teams don't even talk to each other.
The irony of saying you saw the hello world C# program, then go to say stick to the top 4, which includes Java - the most bloated, verbose, out of date, overly complex, Frankenstein (in it's current form with all the updates added since 6) language ever created.
> What's up with non-.NET developers thinking C# is a Windows only, corporate bloatware language?
Ahahahaha.. Good one.
Maybe because it's a windows-only corporate bloatware language? :@
The whole of .NET needs to die in a fire. Why the hell would anyone want to include a proprietary binary dependency in their code, never mind one controlled by Microsoft, of all evil corporations..!
It doesn't even work in WINE. (deliberately?) Normal win32 apps do.
So-called ".NET core" is as useless as Java without a JVM. (that is, useless squared). Doesn't even have a UI toolkit. No WPF without the W.
The only point of ".NET Core" is to lure unsuspecting developers towards Azure Cloud Services, whereupon they submit to the whims of Microsoft.
Basically I think the problem is perception, and certainly it is for me.
People think of the .Net Framework - that's what all the marketing hype has been around for years, and it's the proven, tried-and-tested, used in production, well known, considered stable and usable part of .Net. It's also considered tied to Windows and Visual Studio.
While .Net Core isn't as well known, and if anyone has heard of it then they think of it like "oh cute an open source version of .Net, how experimental. Come back in a few years when it's actually been used in production"
It isn't 2005 any more, yes. But Microsoft doesn't do marketing as well as other people - isn't Swift newer? And I'd imagine it already has a better takeup than .Net Core.
While .Net Core isn't as well known, and if anyone has heard of it then they think of it like "oh cute an open source version of .Net, how experimental. Come back in a few years when it's actually been used in production"
Core has been stable enough for production use for a number of years now. My bank uses .NET Core on linux for all cloud based development. There are no new development projects in Java, some in C++ (front office), and Python is used for ML projects and automation scripts. That's pretty much our technology stack (with js for the browser components). Some of the Java guys are moving to Kotlin, some are moving to Go, but one side of that group will have to give way to the other in the short term.
Fringe languages such as Go, F# etc are being phased out as the cost implications of supporting them all into the future eliminates the use case. Too many languages have been borne of Java's failure to modernize and lack of what people can see to be a stable future (thanks Oracle!), and there's no way more than one of them will make the grade.
If I were learning to program as an undergrad today, the only languages I'd consider would be C# on .NET Core, C++, JavaScript (including TypeScript, React, Angular etc), a bit of Python (one flavour of this language will be around for a while), and some Kotlin (I could be persuaded by Go but its a coin toss which one makes it really). The rest don't have the gas to go the distance.
I think you might want to look at The TIOBE Index before making decisions on what programming lingos to master... most reliable source In My Bombastic Opinion.
The TIOBE Index is *descriptive* not prescriptive.
Certain languages are *unsuitable* for a beginner actually wanting a job, as most of the the jobs are for senior/experienced devs only (e.g COBOL, perl, assembly)
Rhetorical questions:
Where was swift a few years ago? How did it get on the index if folks only learned what was already there?
C# has all those advantages, plus more features and a mature, fully featured standard library rather than an "ongoing project to implement" one.
Swift is an okay language, and it's the least bad way to write native iOS code, but you really have to be in love with Apple to consider using it outside of the Apple ecosystem.
I was always rather skeptical about the whole idea of cross platform .NET.
I just didn't see people on non-MS platforms enthusiastically adopting it. Most developers on those platforms would have a natural reluctance to invest time and effort in a Microsoft technology.
I kind of expected that all MS would achieve was to gut .NET features for compatibility and as a result lose some of the advantage of having a Windows specific framework, while achieving hardly any market outside of Microsoft devices regardless. And even if they were successful, they would be doing so at the expense of Windows and Azure, so at some point the suits would say "why are we pushing technologies that take users away from our server platform"?
"I just didn't see people on non-MS platforms enthusiastically adopting it. Most developers on those platforms would have a natural reluctance to invest time and effort in a Microsoft technology."
This, but I'd add "especially when there is no advantage and a bunch of big potential disadvantages in doing so"
"I kind of expected that all MS would achieve was to gut .NET features for compatibility and as a result lose some of the advantage of having a Windows specific framework, while achieving hardly any market outside of Microsoft devices"
And that's exactly what happened. Fun fact: did you know that .net core doesn't include a cross-platform GUI library? Yeah.
Another factor might be that we know how Microsoft operates and we're all just waiting for the other shoe to drop and for the "extend, extinguish" phases to kick in. Personally, given their track record, they'll need to keep up this whole "we love open source" act for another 20 years or so before I start considering their tech on any merits it might have (not that I've seen any).
For better or worse, the thing that drove C# adoption for many back in the day (C# 2.0-ish) was the temptation of making nice GUIs. Which other language can do that with the same amount of ease? Not Java, not Python, not C. Why not play to your strengths? Because for C#, it sure isn't the ecosystem.
>You might want to ask the mac os team what they think of this novel philosophy you've come up with.
Most developers outside of Apple's walled garden couldn't care less about a framework that limits you to developing for iPhones, iPads, and Macs.
.NET Core is designed so that it can be used on targets where there will never, ever be a UI. There's no need for a UI toolkit on server or IoT device. ASP.NET Core is cross-platform web application toolkit built on top of .NET Core, but it isn't part of .NET Core because not all targets need to support web applications.
Anybody is free to add a UI toolkit on top .NET Core, and have it support Linux desktop. Not only would the .NET Foundation not object, I'm sure they'd sponsor it. But a UI toolkit no more belongs in .NET Core than GNOME belongs in the Linux kernel.
Most developers outside of Apple's walled garden couldn't care less about a framework that limits you to developing for iPhones, iPads, and Macs.
I literally laughed out loud for five minutes at the hypocrisy and lack of self-awareness required for a .net guy to say this.
I'm being 100% sincere when I say thanks so much for that. Laughter is good for the soul and you brightened my day by adding a dash of the truly absurd.
So, just to recap:
!. We've established that you don't know what "multi-platform" means (I'm still chuckling at "multi-platform linux kernel").
2. We've clearly demonstrated that you don't know anything about embedded devices.
3. We've just now established that you don't know what a derivative work is, and/or just don't care about copyright (at least, those belonging to other people).
At this point a paranoid person might accuse you of working on microsoft's marketing team.
Not me, though. Instead, I'm reminded of a man named Hanlon. He used to talk about a razor, or something.
"Fun fact: did you know that .net core doesn't include a cross-platform GUI library? Yeah."
And no interface to C/C++ other than COM. How on earth did they suppose that would work? Thousands of fantastic FOSS libraries available and you can't use any of them.
>Too many, in Microsoft's opinion, and that's why they neutered .NET 5 by making some targets only available on Windows, which more or less kills the entire multi-platform idea.
You must be referring to WPF. WFP is not part of .NET. When .NET 5.0 comes out, WPF applications will run top of a multi-platform .NET 5.0 but only in Windows, just as Android applications run on top of a multi-platform Linux kernel but only on devices running Android.
The restriction on where WPF applications won't make .NET 5.0 any more "neutered" than the restriction for where Android application can run makes the Linux kernel neutered.
run top of a multi-platform .NET 5.0 but only in Windows
Hahahahahaha.
Wow, you must be tired from those gymnastics. I'm seriously going to print out a banner with that sentence and hang it up on my office wall. That's gold.
multi-platform Linux kernel
Ooooooh I see: You don't know what "multi platform" means. Maybe you should leave this discussion to the big kids.
Also you might be interested in https://github.com/thp/apkenv
>Wow, you must be tired from those gymnastics. I'm seriously going to print out a banner with that sentence and hang it up on my office wall. That's gold.
It seems that you're too dense to understand if you use a toolkit that is multi-platform it doesn't automatically make your application multiplatform.
Square this circle, dawg:
"just as Android applications run on top of a multi-platform Linux kernel but only on devices running Android."
I'm just about done here, but allow me to leave you with something to think about as you wallow in your 4% market share and dearth of applications for the OS of your choice:
Maybe software developers aren't targeting your OS not because of the rounding error for a market share, but because they just don't want you as a customer. The nerdrage schtick that's prevalent in this community is becoming a bore.
Would you want somebody as pedantic as you are for a customer? Think about it.
I only just spotted this old ad-hom and felt compelled to address two points:
dearth of applications
Someone has never see the list of software available in apt.
Would you want somebody as pedantic as you are for a customer? Think about it.
I sure would. But then I'm confident in my abilities and I actually take pride in my work, so I view it as a good thing that that customer would push me to provide the best product I could and would hold me accountable to my word.
I just didn't see people on non-MS platforms enthusiastically adopting it.Not the target audience. The target audience is .Net backend developers who want to pay less for their servers by using Linux hosts rather than Windows ones. It's at the expense of Windows, but not of Azure, which is the real money-maker nowadays.
The only cross-platform adoption I've seen of .NET is in the middle of Unity which uses a fork of Mono that calls mostly to a proprietary gaming framework.
For general purpose programming I honestly don't see .NET having any attraction because most real world software would be tainted by Windows in some way. And any software that is intended to be cross-platform from the beginning would have chosen a portable language / framework.
For general purpose programming I honestly don't see .NET having any attraction because most real world software would be tainted by Windows in some way.
And yet I only write cross platform software in C# for .NET Core and I usually only build it for Linux. I've never actually deployed it on Windows, but I've no specific reason to think it wouldn't work, after all it's written on a Windows laptop and it works there first.
Java is too EOL and Oracle no longer invests in the language, rather its sweaty asset time with charges for their JVM. I know there are alternatives such as Open JVM etc, and while that may be a good choice to keep legacy Java apps running, it isn't a sensible farm bet for the future.
"... build it for Linux."
Like it or not, .NET core really is tainted by the word "Microsoft" and I think Microsoft knows that. Microsoft now has a huge financial interest in bringing Linux to them and to make that work .NET has to be nowhere near it, not even in a small print blurb, so expect .NET neglect from Microsoft .
Rust has proven you don't need languages like C# or Java to have convenient syntax and of course better performance while still being portable. So much so, I expect Microsoft to wane development towards it, particularly future .NET developers.
>Like it or not, .NET core really is tainted by the word "Microsoft" and I think Microsoft knows that. Microsoft now has a huge financial interest in bringing Linux to them and to make that work .NET has to be nowhere near it, not even in a small print blurb, so expect .NET neglect from Microsoft .
Azure is growing like gangbusters, and now 50% of its customers' VMs are running Linux. The taint of the name "Microsoft" hasn't seemed to have turned off people interested in running Linux applications.
It's all about perception
Don Syme, inventor of F#, said: "[This] is the perception we much change, isn't it? Why not bring more companies visibly on board in .NET leadership? Make .NET a proper DMZ consortium, to reflect the huge range of economic interests involved in it."
This is just the wrong way round. It's not a perception; it's reality. Change reality, don't just pressure people to help you change perception.
If you look at C (and even C++), you see hundreds of compilers from different vendors.
C-sharp has two or three. I think all owned / run via Microsoft or Microsoft subsidiaries.
This is the big issue I believe. Lack of diverse vendors.
Also, .NET is "big"! If your vendor drops support, you will barely be able to maintain it for a few years. Certainly not be able to port it yourself to alternative architectures or even newer OS versions. A C or C++ compiler for a specific architecture, yeah, much more feasible.
I.e, I am fairly confident I could port GCC from Windows 10 to "Windows 11". I am not confident that I could port Java's JVM or .NET's VM and CLR.
I.e, I am fairly confident I could port GCC from Windows 10 to "Windows 11". I am not confident that I could port Java's JVM or .NET's VM and CLR.
And how long would the open source versions of .NET Core, C# or F# last if Microsoft decided to drop .NET, as they have for so many other developer products - J++, J#, Visual FoxPro, Silverlight, Direct X etc. etc.
"And how long would the open source versions of .NET Core, C# or F# last if Microsoft decided to drop .NET, as they have for so many other developer products - J++, J#, Visual FoxPro, Silverlight, Direct X etc. etc."
How is DirectX on there? As for the others, most of them should never have existed, so killing support quickly isn't such a bad thing. I'd be looking at the people that thought creating anything using those products, was a good idea in the first place ;)
If you look at C (and even C++), you see hundreds of compilers from different vendors.
C is a great language, you'll get no argument from me there. A junior dev could build a great career on this one language choice and expect to work through to retirement. It's not what I chose but I still see real value in that option.
Also, .NET is "big"! If your vendor drops support, you will barely be able to maintain it for a few years.
.NET is 20 years old. 20. That most of my 20 year old .NET code is no longer executed isn't down to the platform or language choice its due to business changes requiring systems of a different scale, business failures, and rewrites to make things cloud native due to the opportunity there.
Microsoft aren't dropping support for it in our lifetimes - its baked into everything they do and most of what they've produced for the last two decades.
I am fairly confident I could port GCC from Windows 10 to "Windows 11". I am not confident that I could port Java's JVM or .NET's VM and CLR.
I'd probably not bother - I mean, the CLR runs just fine on linux, which is where I deploy most of my code and its open source so readily maintainable. If, and it is a ludicrously large sized if, but if there is a future version of windows in my lifetime that does not support the CLR, then I'll just leave the code hosted on linux, and worst case, switch to a linux desktop or virtual Win 10 machine for development on what would by then be my legacy products. I'd likely have adopted C#'s replacement, whatever that was and from whichever vendor it comes from for my new projects. Hell, I may just give up then and join you folks writing C and C++!
.NET is 20 years old. 20.
.net core is not the same thing as .net. It's ~5 years old. 5. It's supposed to supersede .net and is not completely compatible, meaning that .net has effectively already been dropped.
That most of my 20 year old .NET code is no longer executed isn't down to the platform or language choice
Hasn't .net changed hugely over the years? is your 20 year old code even compatible with the current versions? I seem to recall hearing from a few people about huge pain migrating from .net version X to version X+1. You can assert that you don't run it for business reasons all you like, but you also can't just run it as-is on the current version for technical reasons.
rewrites to make things cloud native
...you rewrote, rather than refactoring? I mean I guess that's cool if you're billing by the hour.
Microsoft aren't dropping support for it in our lifetimes
1. I presume you have this in writing from microsoft? I mean surely nobody would make such a bold statement like this without having it in writing, right?
2. They already effectively dropped .net by switching to ,net core. see my first point above
I'd probably not bother - I mean, th...(blah blah blah)
...way to miss the OP's point. Was that intentional?
what would by then be my legacy products
Oh, maybe not intentional: I see now: you're not building your stuff to actually last. You see it as a feature that you have to rewrite the same thing every 5 years (billable hours amirite?).
virtual Win 10 machine for development
"I'll just keep using VB6. It'll be fine."
.net core is not the same thing as .net. It's ~5 years old. 5. It's supposed to supersede .net and is not completely compatible, meaning that .net has effectively already been dropped.
On paper you might be right, but in the really real world, you're a mile away from that. The upgrade path from .NET framework to .NET Core is trivial at best for many apps unless you're doing desktop apps in which case you want to stick to .NET Framework.
My average migration across frameworks has involved approximately 2 minutes effort per application, so its not spectacularly different to a version upgrade for most things.
Hasn't .net changed hugely over the years? is your 20 year old code even compatible with the current versions? I seem to recall hearing from a few people about huge pain migrating from .net version X to version X+1.
No, because you can specify backward compatibility in the project settings to target older frameworks for specific projects. Most things should be decoupled behind an API or a queue anyway, so the upgrade path can be a piecemeal as you choose.
You can assert that you don't run it for business reasons all you like, but you also can't just run it as-is on the current version for technical reasons.
In 20 years of working with .NET I've never actually had a problem.
...you rewrote, rather than refactoring? I mean I guess that's cool if you're billing by the hour.
Try working in finance and refactoring 40 year old COBOL mainframe code to work in the cloud - there's lots of rewriting. You can't always refactor from on prem code to cloud code either - well, you can always do it, but its not always cost effective. And example, if I may? I might have a typical 3 tier app - web server, app server, and data server. Rewriting that to use a cloud native datastore eliminates one server and all scalability challenges but may come at a varied run cost (how much activity does the datastore see). I might also rewrite the app layer as serverless functions because I want to scale separate parts of the application to different levels. Its a different architecture to which you won't always want to refactor code designed for a different world.
1. I presume you have this in writing from microsoft? I mean surely nobody would make such a bold statement like this without having it in writing, right?
C++ will be used in anger in production for at least 50 years after Id ie of old age. How's that for a bold prediction? MSFT can't drop .NET because most of their core products are written in it (and C++, see what I did there).
2. They already effectively dropped .net by switching to ,net core. see my first point above
Not really. Its the same thing. Its literally mostly the same thing. The main diffs are around WPF GUI's for the desktop. I've spent almost no time relearning this "new" language or framework and almost no time "porting" our code to use it.
h, maybe not intentional: I see now: you're not building your stuff to actually last.
Sure I am, and while my 1980s colour telly still would work, I've replace dit with a massive LED back lit monster. Still works, but is no longer useful. There aren't any real businesses these days that don't sufficiently change their processes over 2 decades for you to keep a static codebase, so you have no argument.
Yes, sure, there is finance and the mainframes, but while I work in finance, we don't touch the mainframe stuff because that's how RBS keep knocking out their cashpoints. For the rest of the business, the process the code models changes so often that the code never gets to its 10th birthday.
Building stuff to last is the sort of academic argument you'd find in a university, but out in the real world people already know that everything changes and the pace of change always increases, thus the process you engineered 5 years ago is going to be out of date and eventually a rewrite looms large.
"I'll just keep using VB6. It'll be fine."
Until, I think, this year you'd have been right. C++ makes an even better case.
credit where it's due, that's actually a pretty damn good response :)
target older frameworks for specific projects
You mean "I need to have 5 different versions of the same thing installed at the same time"?
My average migration across frameworks has involved approximately 2 minutes effort per application
What you're actually saying here is that you're not doing desktop apps :P
Try working in finance and refactoring 40 year old COBOL mainframe code
oh OF COURSE you had to be that guy doing that job, the one that nobody can argue should be a refactor. Curse you!
In 20 years of working with .NET I've never actually had a problem.
When was the last time you actually compiled 20 year old .net code?
How's that for a bold prediction?
That's not bold at all, that's pretty mundane. But then C++ isn't under the sole control of a company with a track record of dropping tech and leaving users in the dark with no migration path, is it?
MSFT can't drop .NET because most of their core products are written in it
That's an assumption. In fact it's a whole bunch of assumptions. And I remember hearing similar arguments about how VB would always be around due to the inertia it had and the millions of lines of code written in it. There was I guy I knew back when the whole .net thing happened who was adamant that one day soon someone will release a compatible VB6 replacement. I wonder how that went.
Its literally mostly the same thing.
The main diffs are around WPF GUI's for the desktop
unless you're doing desktop apps in which case you want to stick to .NET Framework.
So it's the same, but it's different. And it's cross-platform, but only if you don't want to make a cross platform desktop app, in which case it's not really cross platform. And it's compatible with itself, except when it isn't. And it's open source, but under Microsoft's control. Sounds like a great environment to be working in. Strange that it isn't being adopted more.
I find it pretty ironic that the one use case where I might have been marginally interested in this tech - for rapid, cross platform, gui app development - is the big thing that it can't do. But if you give it a little bit of thought it's pretty obvious why it's this way - we wouldn't want people releasing their desktop software for Linux, would we?
Building stuff to last is the sort of academic argument you'd find in a university, but out in the real world people already know that everything changes and the pace of change always increases
So I'm guessing you're not a vim or emacs user then?
my 1980s colour telly still would work, I've replace dit with a massive LED back lit monster. Still works, but is no longer useful.
So I'm guessing you haven't tried to play duck hunt (on real hardware) recently then?
(send me your old 1980s telly, they're getting hard to come by, and required for all the old light guns)
There aren't any real businesses these days that don't sufficiently change their processes over 2 decades for you to keep a static codebase, so you have no argument.
I build stuff to last. Granted, this is mostly because I'm lazy and only want to build it once, but that's beside the point. I have 17 year old code still running in production in a couple of businesses. I have no reason to think that this code will be replaced or changed in any way in the next three years. Hell, it's gotta be close to 5 years since they called me to look into whether something was a bug.
I'll grant you that this is the exception rather than the rule but that doesn't mean that planned obsolescence is a good idea. I run code ranging from 10-30+ years old hundreds of times a day.
I'll also grant you that it's not great for the billable hours - I'd have a nicer car if I'd had the foresight to write it in .net so that it needed to be rewritten or upgraded or whatever every 3 years. But on the other hand I'm also never bored out of my skull solving a problem I've already solved 15 times before.
It seems to me that making an assumption that your work won't last is just an excuse to do a half-assed job.
(I admit I have taken this attitude too far in the past - I probably didn't need to write Y10K-compliant stuff early in my career)
I hadn't thought about that code in a while. I might have to have an adulthood birthday party for it in a few months ;)
Yes, sure, there is finance and the mainframes, but while I work in finance, we don't touch the mainframe stuff because that's how RBS keep knocking out their cashpoints.
So, to summarise: Nothing lasts 10 years, except the 40 year old mainframes you're still running. And there's no point in doing good engineering and building stuff to last, it's just an academic argument. But we can't seem to understand these old machines well enough to make changes to them, something that engineers were able to do 40 years ago.
Out of curiosity, what's the DR plan for a hardware failure on the old mainframes?
You mean "I need to have 5 different versions of the same thing installed at the same time"?
No, because most of the framework doesn't change with each version, but I'd assume the more volatile parts do have a few side by side versions to enable this.... nit sure how else it'd work?
What you're actually saying here is that you're not doing desktop apps :P
CTO say's no :)
When was the last time you actually compiled 20 year old .net code?
One of the things I learned from my first boss is that if you move job every 5 or 6 years you never have to do this for any language. So far he's been right.
But then C++ isn't under the sole control of a company with a track record of dropping tech and leaving users in the dark with no migration path, is it?
Seems unfair given your earlier point about VB6, no?
And I remember hearing similar arguments about how VB would always be around due to the inertia it had and the millions of lines of code written in it.
In fairness, they only dropped backward compatibility for the run time last year, so he wasn't completely wrong. They even offered VB.NET as a migration path for VB devs to ease the pain.... not a lot more they could do really.
So I'm guessing you're not a vim or emacs user then?
No, not so much....
I build stuff to last. Granted, this is mostly because I'm lazy and only want to build it once, but that's beside the point.
I build stuff that *could* last rather than will last because the odds are very high that industry and hardware change will obsolete it before then.... I mean, that 17 year old code.... is it multi-threaded to leverage multiple CPU cores? Does it make effective use of the GPU for math intensive stuff? How does it feel about 64 bit OSes? Have any libraries you used been patched? I presume the client hasn't been able to move datastore to something more free? There's lots of problems with long lived systems too - nothing is a panacea.
I'll also grant you that it's not great for the billable hour
I'm an FTE and a fairly senior one - I get paid more to attend meetings than I do for writing code these days :(
I'd have a nicer car if I'd had the foresight to write it in .net so that it needed to be rewritten or upgraded or whatever every 3 years
You just upgrade the installed framework you don't have to touch the code. MSIL FTW.
But on the other hand I'm also never bored out of my skull solving a problem I've already solved 15 times before.
I've been coding for almost 4 decades now - they're all problems I've solved before.
It seems to me that making an assumption that your work won't last is just an excuse to do a half-assed job.
No, I still take pride in my code and make sure it is of a very high standard. My oldest .net code is still running in a bank I left 15 years ago - they just keep moving it and installing the latest framework. Doubt it'd migrate to core without a rebuild due to the package hierarchy but from what I recall of the code it should be a 5 minute job for someone to do.
So, to summarise: Nothing lasts 10 years, except the 40 year old mainframes you're still running.
Louts 3rd Law of Coding: Write it in COBOL and it'll live forever. Cobol McCleod of the Clan McCleod, as they said in Highlander.
And there's no point in doing good engineering and building stuff to last, it's just an academic argument.
No, I never said that. .NET is built to last, you just *might* have to prod it a little every 5 or 10 years. New framework versions don't usually require code changes you just leave it alone because the new versions will run the old code just fine. Just drag a copy to your new hardware and it'll run ok.
20 years is way beyond the lifespan of modern hardware so unless you build it cloud native, you're going to have to do maintained somewhere down the line.
Out of curiosity, what's the DR plan for a hardware failure on the old mainframes?
You won't believe this, but the place you bank with does what my bank does - they buy failed technology museums so they can asset strip the mainframes for parts. I shit you not. They always look for firesales when old companies fail too - Woolworths and others had a few that went for a good price because all the banks were interested and bidding against each other.
nit sure how else it'd work?
Well, I mean, you could just not be shit and lazy and do backwards compatibility.
> When was the last time you actually compiled 20 year old .net code?
One of the things I learned from my first boss is that if you move job every 5 or 6 years you never have to do this for any language. So far he's been right.
So all your arguments about the longevity of .net code are academic. It's easy to avoid responsibility for your earlier work if you make yourself hard to reach. I guess that's an approach that could work for some people :P
Seems unfair given your earlier point about VB6, no?
My earlier point was that sticking with VB6 wasn't really a reasonable path, it was a path that would lead to increasing resistance and hostility and incompatibility from MS, culminating in last year when they finally cut you off and your code stops running (something I didn't know about, thanks for the ammo!). And all this for no reason at all other than to sell the replacement MS product.
Ironically, now that they have dropped the VB runtime the best upgrade path for that guy who stuck his head in the sand and kept using VB6 is to switch to Linux and wine, where it still works just fine and will continue to work for the forseeable future.
So, no, I wouldn't say unfair, I'd say factual.
In fairness, they only dropped backward compatibility for the run time last year,
Yeah, but that was not done for any technical reason. If MS loves open source so much these days, why didn't they open source the VB runtime and let the community maintain it? Did they forget that they love open source on that day? But hey! look! They open sourced their calculator! And Windows 1.0! Wow! Aren't they kind and caring and giving and not at all just releasing useless crap as open source in an attempt to manipulate their public image?
so he wasn't completely wrong. They even offered VB.NET as a migration path for VB devs to ease the pain...
As of last year he is now fucked unless he refuses to upgrade to a modern MS OS, making him vulnerable to all kinds of nastiness. Or he could switch to Linux and wine.
VB.Net was not "a migration path", it was an opportunity to rewrite all your code in an incompatible language inseparably tied to a godawful platform with unknowable future support run by an organisation which had just dropped your tech stack leaving you with no migration path.
not a lot more they could do really.
Well, I mean, they could have just not been shit and lazy and done backwards compatibility. Or they could have offered an actual migration tool. Think "File -> Import VB6 project". But no, that would have cost them a little bit to develop. Instead, let's make it an externality and force every VB6 dev in the world to "just" rewrite all their stuff.
So I'm guessing you're not a vim or emacs user then?
No, not so much....
30 year old code mate. I run it every single day. There's a bunch of it in the FOSS world, where we're not on a forced obsolescence treadmill so that MS's stock price can stay steady, and where things tend to stay compatible with themselves so you're not forced to rewrite your stuff all the time.
An interesting side effect of running this 30 year old code is that because it's 30 years old it's diamond solid - more solid than rock solid. When software reaches this kind of maturity you get to the point where it might even be possible that it has zero bugs in it. I know right, what a thought.
that 17 year old code.... is it multi-threaded to leverage multiple CPU cores?
Yep.
Does it make effective use of the GPU for math intensive stuff?
Doesn't need to. It's just some business logic. But there's no reason why it couldn't if it needed to. Instead, we didn't spend any money buying a GPU.
How does it feel about 64 bit OSes?
You mean like the one it's running on? It doesn't seem to mind. The OS upgrade from 32 to 64 bit was really not even a thing, went really smoothly, no downtime.
Have any libraries you used been patched?
Every single library it uses (and the whole OS) are automatically updated weekly without anybody even bothering to look at the logs. This has caused 0 problems in the time it's been running. Unless you count the couple of times that there were internet problems and it had to try again the next day or whatever, or the time I logged in and manually upgraded stuff when heartbleed happened
I presume the client hasn't been able to move datastore to something more free?
One of the beauties of using free software is that the concept of moving to "something more free" doesn't really apply. It's already free. There are several implications that go with this. One is that the vendors don't make it hard to move to something else. I know right. This means the client can do what they want with it without artificial encumbrances imposed by the bottom line of some company that doesn't care about them at all. If they wanted to switch to a different database engine, for example, that wouldn't be a huge issue. We've switched fileservers and upgraded storage capacity a bunch of times. Fun fact: the first fileserver we used way back in the olden days was a windows server box. As someone stuck on the MS stack, this is a phenomenon you might not be aware of. We call it "interoperability" :P
they're all problems I've solved before.
Damn, I'm sorry. I hope that doesn't happen to me - I'm only at 3 decades and I'm still finding things. Maybe you should think about game dev? I hear you can do that on .net.
Louts 3rd Law of Coding: Write it in COBOL and it'll live forever. Cobol McCleod of the Clan McCleod, as they said in Highlander.
hahaha
.NET is built to last
...exactly as long as the overlords decree it will last, and they haven't announced that they're dropping it yet, and they only drop tech stacks causing hundreds of millions of hours of unnecessary work for millions of devs the world over every decade or so, so let's just assume it's staying around forever!
(I will grant you that open sourcing it does alleviate some of this, but they haven't open sourced the whole thing, so that's not really an argument)
you just *might* have to prod it a little every 5 or 10 years
...assuming it doesn't get deprecated tomorrow, something that the company in charge has only done a couple of times before...
20 years is way beyond the lifespan of modern hardware so unless you build it cloud native, you're going to have to do maintained somewhere down the line.
yes, but that maintenance doesn't tend to be imposed on me by the political whims of some third party who explicitly doesn't care about my use case. Rather, it tends to be for technical reasons. Which means that a) it's more reasonable and b) less frequent.
You won't believe this, but the place you bank with does what my bank does - they buy failed technology museums so they can asset strip the mainframes for parts. I shit you not. They always look for firesales when old companies fail too - Woolworths and others had a few that went for a good price because all the banks were interested and bidding against each other.
Oh I totally do believe it. That's awesome and hilarious. And I want the job of mainframe wrangler, that sounds fun. I heard a story that one of them banks wrote an emulator for the mainframes rather than trying to reimplement the system running on them.
This has been a fun chat. Thanks. :)
> museum mainframes for parts
NASA does the same.
DrAS: most of your points have been at odds with LL's since he's talking about Tier2+ banks, the most dynamically/ fast changing context on the planet in terms of constantly evolving market requirements.
LucreLout; you had 15yo markets code in Production?! I'm impressed! I thought I had some sort of record at 10. (P&L system, handling nearly 10% of EU's M3, plus indefinite complexity right up to eg cancellable reverse dual currency triple currency rollercoaster swap with step-down step-up floor. (The dual+triple is not a typo.)("They're big in Japan." Well, really all of Asia, but I've always wanted to say that :)
Microsoft are on record that the VB6 runtime will be supported for the lifetime of Windows 10:
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy
Given that Windows 10 is supposed to be continually updated, that could be a very long time indeed. Even its IDE (Visual Studio 6) still runs just fine (albeit unspoorted) on Win 10 if you avoid certain (now useless) installer options. I know this because I have it installed myself, as I contribute to an open source project which aims to modernise the Visual Basic editor (originally for VBA, now also supports VB6).
I recently moved a non-trivial WPF app at work from net472 to netcore3.1. It required changing one line in the project file and a recompile. Picked up all the replacement NuGet packages and built without so much as a whimper. It's now in Production.
"When was the last time you actually compiled 20 year old .net code?"
I had a ASP.NET Web Forms web site that was written some time prior to 2006 and was running unaltered until earlier this year. In that time it had two server moves (to newer versions of Windows). It got a re-write this year to ASP.NET Core MVC because the client wanted to massively change the data model, and it was quicker to write it in a modern technology than make the changes (it came from a time prior to there being an ORM, and was using ADO.NET), especially as most of the complex code could just be copy-and-pasted in (took < 2 weeks). Part of the development work involved spinning up a local copy (as in git clone, compile, run), as I hadn't seen the application or codebase in over 10 years.
Not quite 20 years old, but does that count?
Well not 20 years but 15 for sure.
In fact I am compiling at this very moment.
One of the products I work on (windows desktop) has been going since just before .Net 2 and we continue to develop it adding new features. It is build nightly.
But though all the changes of .Net we have not had to go back and rewrite the earlier code. Of course new code is written to take advantage of the current level of .Net.
".net core is not the same thing as .net. It's ~5 years old. 5. It's supposed to supersede .net and is not completely compatible, meaning that .net has effectively already been dropped."
The assembly file names from may have changed from .NET framework to .NET Core, but the namespaces have largely remained the same. Still, even in the oddball case where a class has moved from one namespace to another, it usually takes a simple modification of a using statement.
The assembly file names from may have changed from .NET framework to .NET Core, but the namespaces have largely remained the same. Still, even in the oddball case where a class has moved from one namespace to another, it usually takes a simple modification of a using statement.
So to summarise all that, what you're saying is that they're not compatible with each other.
The two major compilers for C# and two of the three .NET runtimes are open-sourced. Are you unable to clone a repository and execute make?
And does C/C++ really have hundreds of compilers? Based on the various systems I write for today, 90%+ of the market is just three: gcc, msvc and clang.
"Are you unable to clone a repository and execute make?"
- Yes, it gives me an error telling me that BSD make isn't supported and that I should use gmake.
- It then gives me the next error looking for X11 libraries in the wrong place and not being able to find them
- It then gives me another error telling me that my C++11 compiler is too old to provide std::thread atomics.
- So I compile a newer version of GCC... I might as well just stick with that and use C++ directly.
"Based on the various systems I write for today, 90%+ of the market is just three: gcc, msvc and clang."
Yep, but I really prefer to prepare for the future a little more. .NET / Java technology does not make the most of new platforms (I do intend for quantum processors to exist in my lifetime) and I do not want to be the sucker waiting for the .NET framework to catch up.
This has happened before for example with Emscripten (C++ -> ASM.js/WASM based on Clang). The .NET framework and Java never managed to truely make it on the html5 platform (even now it is struggling). Likewise Unity has a .NET IL -> C++ converter just to get their stuff working on the web. This is inelegant.
I think the problem is that those who run Linux are often vehemently anti-Microsoft and they, given the choice between using a Microsoft product and killing themselves would likely chose the latter. Then, of course, there are those who have genuinely tried .NET (core or not) and found it doesn't work well for them (or they plain don't like it).
Personally, I haven't tried .Net Core, but the only real problem I have with .NET is the need a for potentially massive runtime to be installed. Note: I know that the runtime is <100 Meg, but that *is* massive if the utility you are writing using .NET is only a few K, and have no other need for .NET.
That, plus from a security point of view, I don't really want unnecessary software of any kind installed. More code=greater chance of a vulnerability.
Microsoft worked really hard to earn a certain reputation: Embrace, extend, extinguish.
When there was an opportunity to use .net on Linux my first question was about the patents. I fully expected anyone making money from .net or a clone to have their profits taken away by Microsoft's patent lawyers. Clearly I was not alone in this concern because Microsoft made a public statement resembling a promise not to use their patents until the wind changed. As this convinced hardly anyone Microsoft came out with more weasel worded non-commitments.
I stopped paying attention years ago. Perhaps there is some legally binding commitment by Microsoft not to patent troll .net (or clone) users. It is simpler to use other tools than to look for and hire a lawyer to check such a commitment.
> I think the problem is that those who run Linux are often vehemently anti-Microsoft and they, given the choice between using a Microsoft product and killing themselves would likely chose the latter.
After avoiding MS Win since version 3.1 I now have to use a Win10 Laptop for my remote lectures. Killing myself now indeed seems to be a thing worth consideration. I always though our bombastic bob is way over the top when it comes to Win10 and MS software. He is not.
I was prepared for some culture shock, being a command-line person. I was not prepared to thinks breaking without any interaction whatsoever (just leaving the thing on for five minutes unattended). I was aware of intrusive pop-ups, but not the sheer insanity of going through it. I had hoped Win10, at least while doing literally nothing, not being a total resource hog. The machine was set up by people really knowing what to do, therefore I assume there was no silly mistake with install and setup.
Me, now, unhappy ---->
Personally, I haven't tried .Net Core, but the only real problem I have with .NET is the need a for potentially massive runtime to be installed. Note: I know that the runtime is <100 Meg, but that *is* massive if the utility you are writing using .NET is only a few K, and have no other need for .NET.
.NET Framework required the full framework to be installed.
.NET Core only requires the bits you used to create the application.
...and the smallest core piece of that weighs in at about 60Mb, still easily fitting into the parent's definition of "huge" and mooting your point.
After a quick look at Dell, the smallest hard disk I could find was 1 TB. If you seriously regard 60 mb as "huge" in that context, please can you speak to my wife about my "huge" cock?
60mb is huge compared with a few kilobytes, which is what the parent said. Nobody made any claims about hard disk sizes until you came along.
And your cock probably is huge compared with that of a housefly, so all you need to do is get your wife a microscope for her birthday and show her that fly cock and I'm sure she'll appreciate you more! You're welcome, just remember to name a kid after me ;)
60mb is huge compared with a few kilobytes, which is what the parent said. Nobody made any claims about hard disk sizes until you came along.
And yet what was written to which I responded was....
"Personally, I haven't tried .Net Core, but the only real problem I have with .NET is the need a for potentially massive runtime to be installed. Note: I know that the runtime is <100 Meg, but that *is* massive if the utility you are writing using .NET is only a few K, and have no other need for .NET."
You apparently didn't realize that installed means on the hard disk. SMH.
You're welcome, just remember to name a kid after me ;)
How about Rick, with a silent "p" ;-)
You're splitting hairs and playing semantic games. OP says "potentially massive" and then goes on to clarify that their definition of "potentially massive" in this context means "compared to the size of the program". Hard disk size is irrelevant to that discussion, and you're clever enough to know that full well.
Further, there are still places where 60mb is actually pretty massive. Embedded jumps immediately to mind. installing a 60mb .net framework on my openpandora or your router would take up a massive amount of the internal storage on these devices. In both cases it would almost certainly be the single biggest thing installed on the internal storage.
You apparently didn't realise that "installed" doesn't mean "on a hard disk". There are plenty of other storage mediums that come in a range of storage capacities. SMH.
How about Rick, with a silent "p"
Ooh, burn! But I'd prefer Richard ;)
>Further, there are still places where 60mb is actually pretty massive.
And those places are not usually candidates for greenfield applications. Stick to the maintaining your existing C/C++ code in those cases.
>Embedded jumps immediately to mind.
Most embedded devices come with microSD slots. microSD cards can go up 1TB these days.
If the size of the assembly is your primary objection to using .NET Core, your objections are pretty weak and probably just serves to hide some ideological bent.
And those places are not usually candidates for greenfield applications. Stick to the maintaining your existing C/C++ code in those cases.
So what you're saying is that .net isn't suitable for this use. Right, thanks for clarifying.
Most embedded devices come with microSD slots.
1. most != all
2. The SD card slots tend to be for extra storage. The software on these systems tends to be installed on internal memory. Some of these internal memories are still in the ~256Mb range even today. I don't think I've ever seen an embedded system that shipped with an SD card inserted and the software installed there. So that argument holds no water.
your objections are pretty weak and probably just serves to hide some ideological bent
Or it might be that you're in a situation where you actually care about size.
But nobody said it was their primary objection., not sure where you got that idea. I make no attempt to hide my ideological problems with it. But I also don't think they're quite as serious as the technical problems.
>1. most != all
Yes, in the same way that not all programs written for Fedora can run on Ubuntu.
>2. The SD card slots tend to be for extra storage.
No, they tend not to actually, unless they're ancient pieces of junk that should be replaced. And even if they don't, they come with 4GB internal flash MINIMUM.
>Or it might be that you're in a situation where you actually care about size.
IOW, the fact that you point out the most irrelevant constraint as something so important means you have an ideological bent.
>But nobody said it was their primary objection
It seems to be your primary objection because you really know very little about .NET, but you've probably heard about the size of the assemblies and now you're running with it. Seriously, if your sorry job requires you to write programs that are less than 28MB because your employer is too cheap to buy modern embedded equipment, go find yourself different career.
No, they tend not to actually
Oh really? Then you shouldn't have any trouble backing up this assertion by providing a bunch of examples of this in real world embedded systems. Why don't you start off by finding me an example of an IP camera that comes shipped with an SD card pre-inserted and the system software on the card. That should be pretty easy for you since you've asserted that it's a common setup. I'll be waiting.
unless they're ancient pieces of junk that should be replaced.
1. Oooooh you're just the type of customer MS is looking for: nothing wrong with it, but it's 18 months old, so we'll throw it away! Keep at it - those landfills aren't going to fill themselves! I'm sure you'll be very happy together.
2. The router I bought last year has 256mb of internal storage and no SD slot.
And even if they don't, they come with 4GB internal flash MINIMUM.
1. You realise that there are other embedded devices out there that aren't amazon echoes, right? Your comment makes it very clear that you've never actually seen an embedded system.
2. The router I bought last year has 256mb of internal storage and no SD slot.
the most irrelevant constraint
I'm not sure where you got the idea that not having enough storage is an "irrelevant constraint". But sure, fine, whatever, it's not like you're clearly and obviously talking out of your ass.
It seems to be your primary objection
Someone hasn't been paying attention. I didn't even raise the point in the first place.
Seriously, if your sorry job requires you to write programs that are less than 28MB because your employer is too cheap to buy modern embedded equipment, go find yourself different career.
Firstly, for a mass-market embedded device, you can save yourself big dollars if you can squeeze your code into a smaller capacity. It's kind of like how you can go to a car shop and buy something other than a Lamborghini. It's not about buying "modern" equipment, it's about only paying for what you actually need, because you're not so incompetent that you'll happily slap a 60mb library into your product for no benefit.
Secondly, Wow. This is a textbook example of the type of attitude you see from graduates who know one language and aren't actually interested in engineering - the ones who are into programming because they want sports cars. Sort of like the dunning-kruger effect, only amped up to 11. I wonder if it's a coincidence that these type or people are almost exclusively microsoft. It's an attitude that leads to horrible fucking kludges, terrible inefficiency, and boneheaded security mistakes - the types of mistakes I often get paid to un-fuck. In fact, next time you fuck something up (let's face it, it'll probably be monday), do me a favour and let your boss know that I'm available on contract basis and I have plenty of experience correcting the mistakes of dumb kids who don't know or care what they're doing.
Seriously, please do me (and the rest of the world) a big favour and promise that you'll never ever work on anything that could possibly endanger lives.
I'd also tell you to stay away from embedded but it's clear that your knowledge and skill levels will keep you out of that field.
I'll be waiting.
I just thought I'd jump back in to let you know that I'm not able to see any response to my challenge.
I expect that this is probably due to some kind of bug in the reg's forum software (probably caused by it not being written in .net) which is causing your reply to not show up, I'm sure the problem is that the reg's forum isn't capable of displaying the huge spreadsheet of backing data that you posted 15 minutes after my challenge, and not because you can't find a single example of the setup that you claim is common.
I guess I'll keep waiting
None of my .Net Core stuff has ever been a release deploy over about 20MB. And I've done .Net Core stuff for a few years.
I also do Go, Node, Python, and Ruby, so I have a reasonable basis for comparison. And unfortunately for Microsoft although I've been doing .Net since around 2003 (IIRC) my conclusion is that C# is a brilliant piece of engineering, the coverage of the framework is superb, the quality is excellent, but I still do not trust them to stick to a path once chosen.
With Core they had an opportunity, after a decade and half of the framework, to get it right. All that experience should have meant a smooth and ever better cadence in the creation of the new and improved cross-platform framework. Instead, for example, they couldn't even get the project file definition right (initially json and then csproj).
In brief (sorry) C# is a superb language and the .Net 'library' is very good, but the whole thing is cursed by "belonging" to Microsoft.
>...and the smallest core piece of that weighs in at about 60Mb, still easily fitting into the parent's definition of "huge" and mooting your point. Thanks for playing!
I don't worry too much about storage these days, so I didn't know offhand if this was true. So I decided to create a self-contained .NET Core "Hello World" console app. Turns out that the executable is 28MB, along with a 1K PDB file.
I have a lot of trouble seeing anything in .NET that offers any real advantage to developers on any platform.
When .NET was a new shiny thing Microsoft made much of the fact that Visual Studio could generate a lot of boilerplate Windows GUI code for C# automatically, and I can see that that may have offered a productivity boost on Windows ... but only on Windows. Mono never supported Windows's GUI APIs on other platforms. This led to a drop in popularity for Microsoft's previous favourite language, C++, on Windows, and a big "Meh" from people working on and targeting other platforms.
Microsoft have since lost the way badly on the GUI front with ribbon bars, their fascination with the abomination formerly known as "Metro", store apps, and suchlike, and all that old C# GUI code is looking less and less like a good investment.
Meanwhile, other languages have appeared on the scene and gained in popularity, but are poorly served by .NET -- making .NET itself seem less and less relevant. Where are Kotlin.NET and Rust.NET, for example?
Where are Kotlin.NET and Rust.NET
Given that Kotlin started off as an alternative to Java and its Java version depends on the Java Class Library, I'm not sure what you would gain by targeting the CLR. One of Rust's features is a lack of garbage collection, so again it's not clear why you'd target a system that uses GC extensively.
There are a lot of things that .NET offers as opposed to traditional C/C++ development in terms of speed of development and safety of the relevant code. But you really need Visual Studio to get the best development experience and, as you say, you lose the convenience of being able to knock up a quick UI as soon as you move off Windows.
Visual Studio + C# is probably the most productive development environment I've ever used, but I'm not sure that "Develop on Windows, Deploy on Linux" is a compelling message, even though my experience of .NET Core is that it works well and is commendably fast.
Visual Studio + C# is probably the most productive development environment I've ever used, but I'm not sure that "Develop on Windows, Deploy on Linux" is a compelling message, even though my experience of .NET Core is that it works well and is commendably fast.
I agree on the dev environment stuff - it is easily the most productive combination available today. However, having used Windows Servers since they first came out, I very much now do "Develop on Windows, Deploy on Linux" because it is just so very easy to do. It scales well. Its very cheap in the cloud.
Unless you're building desktop apps or have a specific need for a Windows Server, and I'm open to what that need may be, then I'd wholly recommend the DoWDoL approach. Its become my default way of working over the last few years, though for how many more years much of my code will even need a server (in the sense of me deploying it to one) remains to be seen due to advances in "serverless".
.
Given that Kotlin started off as an alternative to Java and its Java version depends on the Java Class Library, I'm not sure what you would gain by targeting the CLR.
Kotlin's original design goal was to produce a more expressive and safer language than Java running within the Java ecosystem. Kotlin doesn't have to target the JVM, though. Kotlin Native is "a thing", and Kotlin.NET could be too, were there the will for it to exist. I see C# as about on a par with Java so far as safety and expressiveness go, so I think the idea is sound.
One of Rust's features is a lack of garbage collection, so again it's not clear why you'd target a system that uses GC extensively.
Rust's main objective is to provide a syntax that supports rigorous compile-time checking, to eliminate (or, at least, drastically reduce) runtime errors. Rust does also position itself as a system programming language, and eschews garbage collection for that reason, but a lack of garbage collection is not one of its primary goals. Methinks the question is whether you consider the elimination of runtime errors to be desirable in .NET, and if so whether you like Rust's approach to that goal.
Visual Studio + C# is probably the most productive development environment I've ever used, ...
Many people have said that ... but is that really anything to do with .NET, or is it that Microsoft have chosen to support .NET by providing a lot of programmer productivity tooling for C# (in particular) that they haven't provided for native code development? I would argue that had .NET never existed and all the development resources that went into it had instead been spent on making Visual Studio a more productive toolset for native code C++ development then Visual Studio and C++ would be just as productive a development environment as VS+C# is, today, with the added benefit that the resultant programs would be smaller, cleaner, and faster.
>Many people have said that ... but is that really anything to do with .NET, or is it that Microsoft have chosen to support .NET by providing a lot of programmer productivity tooling for C# (in particular) that they haven't provided for native code development?
It's a combination of few things:
- C# language itself has evolved over time with productivity in mind. From implicit typing with "var" to string interpolation to multiple return values in methods to out variable initializers, each version of C# has allowed developers to write much less verbose code.
- .NET assemblies are very feature-rich, which largely comes from it being so mature. Sure, .NET Core didn't start out that way, but it was really just a matter of porting the existing code over to the new assemblies. Since .NET itself is written in C#, I would imagine most of the work came in reorganizing the code into the new assemblies. What physical assembly files the code lives in may have changed, but the namespaces themselves didn't change much, if at all. System is still System and System.IO is still System.IO in .NET Core.
- The Roslyn compiler provides amazing code analysis capabilities that serve as the basis for much of Visual Studio's productivity features as well as those of third-party extensions.
>I have a lot of trouble seeing anything in .NET that offers any real advantage to developers on any platform.
C# is a really good language, .Net is a pretty comprehensive set of libraries.
But you seem overly focused on GUI which is a pretty tiny part of modern software development.
I don't think I've seen any Job ads specifying .Net that didn't also mention most of the rest of the Microsoft stack (not in the last six or seven months)
And if not, why would a hobbyist coder bother with .Net on a non-windows platform except from some perverse masochistic challenge project (granted, some are inclined to odd language picks, just because) - girls won't be particularly impressed, and it doesn't seem like employers are looking for the combo.
My notion tells .Core is a fancy toy to force Windows web service developers out to learn something new. Experience interviewing with an establishment boasting all-shiny .Net Core 3 and from scratch development ended up an interviewer in a leading position not really understanding any true benefit of the platform as they mentioned MSSQL server is on board, while elaborating they have no experience neither with MySQL nor with Postgres. Overall felt like it's just the same opinionated Windows chaps doing the same under a new hood and outsiders aren't quite welcome.
Mind, all the Github tickets i've opened for .Net core related feature requests were answered by MS employees. And all of them ended up being: we're not planning to add such capabilities in near future or "it's not on our milestones". So if it's MS team members deciding what gets to be supported in future, or any milestones how is it a genuine open source project is they get orders from a single patron.
This kind of comment implies a male audience, bro's at that, and is juvenile and sexist.
Can't think why the industry is still failing to draw in a more balanced workforce.
I was going for a certain humorous exaggeration of possible motivations.
Congratulations on taking me much, much too literally. So literally in fact, you completely missed the actual message.
It's all a nightmare:
If you want to use modern TLS with ALPN in .NET Core/,NET Standard that will run on both Windows and Linux, Microsoft forces you down a path that precludes use of Windows 7, because of lack of support of ALPN for any versions of .NET libraries that run on WIndows 7.
If you want your code using ALPN to run on Linux, you're forced to use Windows 10 on the Windows side, otherwise, on Windows 7, you have use a native C++ layer to rely on the ALPN support from openssl, and then it you can't use it on Linux because it is mixed-mode code.
I tried to install it on linux but it was dirty stuff pulling in tons of win32 dependencies and all. That was just a empty project. It might run on linux but I didn't bother to look any further to that mess. If they want it cross platform at least make it easy to start with a clean slate and not by pulling a quarter of a century in legacy compatibility.
I think there is good reason to still not trust microsoft btw
I have really enjoyed using .Net core since 2.0. I've developed a microservice framework, plus a websites an webapi.
I've reached out to ms .net core developers who have been very helpful and skyped called me to follow up.
The transition from mac dev to windows production is straight forward and easy using azure and aws. Docker is what it is at present.
The changes seem mostly logical and straight forward. Entity Framework Core has been the only difficulty as they have uncovered the difficulties of transforming to line to sql.
My experience is wide having started off writing c, c++, sql, objective-c, java, c#, javascript, python, kotlin for example.
Yeah it is so easy, and you don't even notice that your competence is being siphoned away. Do you know that the docker containers are running in virtualized linux hosts? "Easy", apparently trumps everything else!?
Good for you that the 3. world supporters from the companies ruling our communication is so nice and loving to their subscription-paying serfs.
Soooo Easy!!
I would suggest that most people working on Linux are used to using other tech so why would they take the time to learn .Net? And those already on Windows are unlikely to move to work on Linux.
I would certainly look at .Net on Linux but I am unlikely to get hired for Linux work as all my background is on Windows.
When people asked me about the difference between .NET and .NET Core I'ld tell them that .NET Core was the multi-platform version of .NET. Now, with .NET 5 replacing .NET Core this isn't true anymore, because some of the targets (e.g. Windows Forms) only work on Windows, not on Linux and Mac.
This change was instigated by Microsoft PHB's, because the open-source community would never have made such a change.
It goes to show Microsoft's strategic directing of .NET's future is still very much governed by its profit motives.
"Now, with .NET 5 replacing .NET Core this isn't true anymore, because some of the targets (e.g. Windows Forms) only work on Windows, not on Linux and Mac."
This is like complaining that the Linux kernel isn't truly multi-platform because Android applications don't run on CentOS.
WinForms is a framework that can run on top of .NET 5.0, which absolutely is multi-platform, but the WinForms framework itself is not. Some frameworks that run on top of .NET 5.0 happen to be multi-platform, but that doesn't mean all frameworks built on top of .NET 5.0 are required to run on all platforms for .NET 5.0 to be considered multi-platform.
I've been working with mono since .NET 1.x, and the problem has always been that you're expected to do all of your R&D on Microsoft platforms and then, later, try to figure out which parts will fail when you move off of Windows. The actual runtime is great and the command line tools work.
Microsoft knows it's all about developers: libraries and IDEs are the things developers use, and these are all Windows-centric. Debugging in Monodevelop and managing libraries with Nuget is an ongoing nightmare.
I currently have some things I really want to port to Java when I have the time. Faster execution, better tools, more tool options, the whole ecosystem is better. I used to prefer C# as a language, but its desperate desire to become Javascript and facilitate poor coding styles has undermined most of the things I used to like about it.
Basically, this post is all about regret. Sadly, anonymous because my "problems" are my employer's problem and I'm not really at liberty to talk about them. :(
My last experience of monodevelop was a couple of years ago when I happened upon some code I wrote about five years ago and decided to see if it still worked. From what I could tell, monodevelop hadn't changed an awful lot (my code worked first time by the way). It was a bit basic and clunky and certainly not a patch on Visual Studio, which, for all its warts was certainly the best (if not the only other) to in which to develop using C#.
This is one particular issue I see as being quite prominent in the wider uptake of C#. Whilst other languages like Java benefit for a wide choice of good quality multi-platform IDEs such as IntelliJ, Eclipse and NetBeans. I'm not aware of anything that's geared up for C#. There's ReSharper but I don't believe that it's actually an IDE, just an analysis/optimisation tool.
I know there's lots of folks talking about developing on Windows and deploying to Linux - fine, but I don't think it's healthy to be tied to VS with its hefty price tag, and even if VS Code improves support as noted in the main article; that's still a Microsoft product - where's the competition?
Mono was starting to gain ground in some communities. For instance, there are a number of mono / gtk apps out there. However, microsoft in their grand wisdom decided that when mono migrated to .net core it would no longer support other platforms besides the big three (win, mac, linux). many microsoft employees thought this was stupid, but it was done anyway.
Microsoft has embraced linux but not open source as a whole.
Mono didn't "migrate to .net core".
Microsoft doesn't own Mono. Microsoft appears to have cloned Mono to make Ms Net Core.
They've been trying to stuff that genie back into the lamp ever since Novell started the Mono project, and having failed to do so they decided that *claiming* to have done so is just as good.
I am fairly cross platform so when the .Net Core thing came out I was keen. Except that you couldn't interface with native applications in Linux, there was no built in GUI framework and you can't port .net Framework apps (other than asp.net and even that is brittle) to Linux. Soooo.... WHY would a developer spend time trying to piece together a solution in broken .Net code when there are so many other tools?
What is the ROI in building or converting applications for a platform where the only users are too cheap to buy software??? (I include myself in that 'too cheap' comment).
No, Microsoft is inching towards replacing the NT kernel with something else. That is the only reason for .Net Core. They are biding their time until they switch the kernel model and NT becomes the subsidiary to Linux. Then suddenly all the features that developers need will magically appear. Just wait...
Ignorance disclosure: I've never been a coder and I have been out of the IT industry for nine years now so I have no real idea about modern coding platforms, hence my questions:
Given QT is A Thing and there are actual apps written using QT that are truly cross platform such as Kdenlive which I live and die by, does .NET bring anything to the party worth anything?
Could it be that the fact QT exists rather weaken the need for .NET which is aligned with a company known for EEE?
[Asking for a friend.]
Qt is an application development framework first and foremost. It has a very nice UI toolkit and lots of cool features to make it easy to write interactive apps that run fast and respond well, but it's very focused on software that presents a graphical UI that you interact with (interesting fact: Qt is used in a lot of in-car entertainment systems, precisely because it's so good at GUI stuff on relatively slow hardware)
.NET isn't really comparable, as it's a runtime and a general purpose programming library (like Java). You can use it to make servers, clients, web-apps or desktop apps. It doesn't have a single UI toolkit, so you have to make a choice between them (of the available ones, only the Windows-only UWP comes close to Qt, but Uno could have potential).
I think both are great technologies, and I've written apps for mobile and desktop with both of them. There's things to like about each: C# is a more productive language than Qt's C++ (speaking as someone who had decades of experience with C++ and came to C# relatively recently), but on the other hand, Qt's QML layout system (and its use of JavaScript for tying together stuff that's a little more complex than a binding) is so much more developer-friendly than the XAML-based schemes you tend to see on C#, Net applications.
The FOSS puritans don't like Qt either, by the way - I can't remember what the reason was, something to do with its dual licencing where commercial customers got features first, but I find those people tend to do much more talking than actual programming, and thus are really only in a position to advise on political, not technical matters.
I lose count of the different languages and environments I've used - somewhere over 30, anyway. All trade off features. These days, I tend to develop over-10-line software in one of three languages:
1) Smalltalk (Squeak, these days) for pure prototyping where I only care about implementation speed. As the original team opined, it is "an exquisite personal computing environment" - crazily productive.
2) C++ where I need close-to-the-metal data layout and can't afford garbage collection. Arguably I should investigate Rust for this. Interestingly, performance in modern .Net environments is usually close enough to C++ that I no longer care about the difference.
3) C# for everything else, linked through to a platform UI library if I'm not doing web. Nice clean deploy across many different platforms - there aren't many languages where you can write an algorithm and have it run unchanged on your GPU, both major phone OSs, and all three major OSs on x64 and ARM. That's worth quite a lot to me.
Horses for courses; the ecosystem around C# works for me for quite a lot of the courses.
This will sink down in the comments because it's from someone who uses .NET every day and is content to do so.
I've been building web for 20 years in different forms and I do like C# as a language. Where I need object models, I have them. Where I need dynamics, I have them. Where I want a more functional style, I can do that too. If someone wants me to integrate with a legacy telnet client than I can interop if need be. I'm more productive than code I've written in Typescript/Node or Python or PHP or Perl. I can choose whatever database I want, I swapped MSSQL to Postgres with very little faff and I've used Raven, Couch and Mongo too. I've deployed to Linux as well as Windows, although I'd prefer Linux for future work Whatever fits the need. In my spare time I get to write Unity games in the same language, which is nice.
My bug bear has been with their naming. .NET is a stupid name, always was. In the early days googling for a .NET thing would throw up domains more often than not. .NET Core should have been given a new name that was nothing like .NET because it is a new product. There is no direct upgrade path from framework to core unless you're lucky to use supported libraries with supported features. They should have introduced it as a new cross-platform system rather than hanging onto the old name. With .NET Standard thrown into the mix, it's added a confusion that would rightly put people off.
After reading the article I decided to give .NET Core a quick try (in Ubuntu).
I needed to download and install packages-microsoft-prod.deb
When creating a project i get a lot of info, including:
"It is collected by Microsoft and shared with the community."
The automatically generated Program.cs starts with an efbbbf blob, and (as the project file) uses DOS line breaks.
And obviously it is all documented and downloaded from microsoft.com.
Building the entire thing from source (configure, make, make install) is not quite supported or explained on the MS pages (correct me if I am wrong), which is kind of common for open source code.
All these things are hints to Microsoft and the .NET Core people what makes it feel less like a true open source platform.
But in the end my problem with .NET Core is that I have little use for it. There are simply other languages that allow less footprint or less installation effort (for myself, or those I share my code with). And I don't see any case where .NET is the best option for my code. JavaScript, Python, Bash, C and PHP all have their obvious use cases where they shine.
.NET Core seems to be #1 only for the reason that you are already in that ecosystem or have to use it.
I can't say I am a fan of David Fowler. I think he has done a horrible job with ASP.NET, starting with ASP.NET MVC. IMHO, Microsoft had it right with Web Forms to begin with. It had the concept of UI controls. MVC ditched that and basically just became a .NET version of Ruby On Rails. It's like they fired the entire team of whoever originally worked on .NET and made it great, and brought in people who wanted to make it like Java, or whatever the trendy language of the moment was. I have always hated MVC and cannot stand modern versions of ASP.NET. Then, Microsoft while somehow managing to bring Windows Forms and WPF forward onto .NET Core, refused to move Web Forms forward leaving existing developers in a lurch. I have a lot of Web Forms application, and I'm not re-writing them all. I'm using Telerik's UI controls which are still by far more robust than the versions for MVC, Blazor etc. They are intranet apps and Web Forms is a highly productive environment for developing the kind of applications that I'm working on. I spent a lot of time converting from Entity Framework to Entity Framework Core. Now, they changed EF Core to use .NET Standard 2.1 which doesn't support .NET Framework. Also, the newest language features are unavailable on .NET Framework. While I'm glad that Microsoft is getting more into open source and opening things up, I think they have done a horrible job with respect to moving things onto .NET Core. I think the decision to not move Web Forms is by people like David Fowler. They think they know everything and have done nothing but make the platform more difficult to work with. Just look at the ridiculous new logging API, and all the other overly complicated over design patterned code they are writing. It's convoluted as hell. Things should be getting easier, but, that's not what's happening. They are shoving new technology down everyone's throats. That would be fine if it was better, but, that isn't necessarily the case. I hope Microsoft considers their long term developers and doesn't throw them under the bus while they chase the younger developers. It appears that they already have. Personally, I think they need a management shake up. Current management are doing a bad job.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
