.NET Core angst
-
@Adynathos said in Pressure to upgrade to Windows 10 ratchets up. AGAIN.:
@cartman82 said in Pressure to upgrade to Windows 10 ratchets up. AGAIN.:
See also: The disaster that is .NET Core RC 2.
Do you maybe know whats the state of NET Core? It looks promising, because I want to try C# (on Linux).
What problems are they facing?Summarized here:
Basically, over the past 2-3 years, Microsoft kept changing their mind what they want .NET core to be and work like. Early adopters, people who beta tested and got managers to buy into the new platform, were already unhappy with the lack of focus. But finally they've reached Release Candidate stage, and things could finally settle down for the big release later this year. Or so they thought.
Then Microsoft bought xamarin, and Miguel De Icaza got into the fray. Suddenly, MS announces they are abandoning their simplified json project format and moving back to MSBuild. Just as that settled down, now it seems a whole bunch of old .NET api-s are also getting showed back in. Probably to support UWP cross-compilation. Or something. No one is sure, and .NET core team is either silent or giving contradictory information.
Note this is ALL happening between RC1 and RC2. After this latest twitter fray, it's not certain .NET core will even be released this year at all.
It's a huge mess.
-
Don't miss this read too
How one announcement destroyed the .NET ecosystem on Windows
This post is based on events that happened 5 years ago. I had the basic points of it in my “drawer” for years, but thought it’s water under…
-
These were RC releases, you aren't supposed to use RCs.
-
@fbmac You also aren't supposed to introduce large architectural changes once you reach the RC phase.
-
@Onyx I they were catastrophic for important MS customers they did the sane thing.
They did revert large changes if I understood it.
-
@fbmac said in .NET Core angst:
These were RC releases, you aren't supposed to use RCs.
RCs are past beta, you're not supposed to be changing the product after it hits RC status.
But, hey, they're all open source-y now, and open source-y people release buggy broken shit all the time, and now you know why I drink.
-
@blakeyrat said in .NET Core angst:
RCs are past beta, you're not supposed to be changing the product after it hits RC status.
But, hey, they're all open source-y now, and open source-y people release buggy broken shit all the time, and now you know why I drink.It's really tragic you have some kind of hard-on against Apple, you'd probably like it much better there.
-
@cartman82 What are you talking about? I used Apple computers for like 15 years.
-
@blakeyrat said in .NET Core angst:
@cartman82 What are you talking about? I used Apple computers for like 15 years.
But they're becoming all open sourcey recently, so they'll be a steaming pile of shit in no time.
-
As I said previously stick with 4.0 / 4.6 and Mono and make sure anything you write is PCL compliant. Most stuff has worked fine cross platform for a while if you are doing web work.
Microsoft have royally fucked up with this. The whole point of .NET Core was so they wouldn't lose developer mindshare.
There is some great tech there but there are just too many breaking changes.
-
@blakeyrat said in .NET Core angst:
@cartman82 What are you talking about? I used Apple computers for like 15 years.
But you aren't using them now. They are also going OSS these days, but apparently are deteriorating slower than MS.
-
Ahahahahaha! The .NET Foundation Forums run on
!
-
@MathNerdCNU said in .NET Core angst:
Ahahahahaha! The .NET Foundation Forums run on !
Following that link from WTDWTF was like stepping out of a chariot into a limousine, so the laugh is really on us.
-
@cartman82
What can I say, I've been in a black-comedy mood lately.
-
I wonder if they fixed the fa-spin bug on there.
-
@Captain maybe it's
-ms-spinthere
-
-
@blakeyrat said in .NET Core angst:
But, hey, they're all open source-y now
I used to think you were making a joke, but literally the only thing that changed between Microsoft .NET and Microsoft .NET Core is that the latter is open source. And managed about a billion times shittier.
Although that might be related to the amount of bullshit we actually get to see. It might be that the amount of total bullshit is the same in both cases.
-
@ben_lubar said in .NET Core angst:
It might be that the amount of total bullshit is the same in both cases.
it's bullshit all the way down.
and i mean ALL the way down.
-
@accalia "hey Intel, what's the new i7 made of?"
-
@ben_lubar said in .NET Core angst:
@accalia "hey Intel, what's the new i7 made of?"
all.
the.
way.
down.
-
@accalia said in .NET Core angst:
@ben_lubar said in .NET Core angst:
@accalia "hey Intel, what's the new i7 made of?"
all.
the.
way.
down.
Hm. So if it's
all the way down, then it's a type of infinity, no? So is it parallel to the natural numbers (ℵ0), reals (2ℵ0), or something else?And where do JavaScript place?
Also, do we need a new notation? x language is in
0, but y language is in 0 ?
-
@Dreikin said in .NET Core angst:
Also, do we need a new notation? x language is in
0, but y language is in 0 ?Superscript? That would appear to be
all the way up…
-
@dkf said in .NET Core angst:
@Dreikin said in .NET Core angst:
Also, do we need a new notation? x language is in
0, but y language is in 0 ?Superscript? That would appear to be
all the way up…To
and beyond?
-
@dkf said in .NET Core angst:
@Dreikin said in .NET Core angst:
Also, do we need a new notation? x language is in
0, but y language is in 0 ?Superscript? That would appear to be
all the way up…You're right, it should be
0
-
@cartman82 Thanks for the reply.
So if I understand correctly:
- porting the CLR-VM to various platforms is done
- now they try to port the massive amounts of .NET libraries and can not decide which libraries should be ported and in what shape?
However, the majority of libraries should be in the CLR, and the only ones needing porting are those directly interacting with the OS. So why is there such a problem with that?
Please forgive if I miss something obvious, all my knowledge of C#/.NET is that it is similar to JVM.
-
@Adynathos Because you have to build the whole build system etc.
They keep on changing namespaces which breaks builds and loads of other stuff.
-
@Adynathos said in .NET Core angst:
@cartman82 Thanks for the reply.
So if I understand correctly:
- porting the CLR-VM to various platforms is done
- now they try to port the massive amounts of .NET libraries and can not decide which libraries should be ported and in what shape?
However, the majority of libraries should be in the CLR, and the only ones needing porting are those directly interacting with the OS. So why is there such a problem with that?
Please forgive if I miss something obvious, all my knowledge of C#/.NET is that it is similar to JVM.
The CLR is the Common Language Runtime. It's the .NET equivalent to the JVM: the execution engine for .NET code.
The libraries are the .NET Framework, code that runs on the runtime. A good amount of that has not been ported.
-
@masonwheeler yes it has. I am supporting intranet sites using mono on Linux machines on Amazon right now.
No I haven't ran internet site with large amounts of traffic. But for what I do there is a proof of concept.
No it isn't perfect, because some libraries use P/Invoke etc.
If you are writing a WinForms app then no you are correct, it hasn't been ported. But almost anything that isn't Windows Specific has been ported.
-
@Adynathos said in .NET Core angst:
However, the majority of libraries should be in the CLR, and the only ones needing porting are those directly interacting with the OS. So why is there such a problem with that?
It's not just about being multi-platform. It's also about getting rid of the accumulated legacy garbage.
MS tried to make NET core as thin as possible. AFAIU you should be able to just X-Copy deploy it wherever, or even package it with your program, instead of relying on an installed runtime.
It seems the sticking point was getting companies to actually transition their legacy tech to NET core, instead of NET 4.6 becoming the new Windows XP. Companies wanted an easy update path, where new NET core stuff is opt in and all the old API-s are available. MS wanted them to rethink a lot of their software and move to the new, clean platform, without a bunch of legacy garbage dragging everyone down.
As usual, MS blinked first.
-
@ben_lubar Well the x86 architecture is shit, so yeah, pretty much.
-
@anonymous234 would you prefer MIPS? ARM?
-
@cartman82 said in .NET Core angst:
MS wanted them to rethink a lot of their software and move to the new, clean platform, without a bunch of legacy garbage dragging everyone down.
A noble idea, unfortunately it rarely works :(
@cartman82 said in .NET Core angst:
easy update path, where new NET core stuff is opt in and all the old API-s are available
That seems like the way which minimizes the risk of very poor adoption. I think that was the main problem of the python 2->3 transition - would it cost them so much if the python3 runtime could run files with python2 syntax in some "legacy file mode"? I like using the latest version and don't want the library author to have an excuse not to support it :P
From outside, this seems easy enough - move those old APIs to CLR-only packages using the new VM's API, then forget about them. But things are never as easy as they seem, the libraries are probably massive and people are using them in some insane ways that will break regardless of what you change.
-
@Adynathos said in .NET Core angst:
That seems like the way which minimizes the risk of very poor adoption. I think that was the main problem of the python 2->3 transition - would it cost them so much if the python3 runtime could run files with python2 syntax in some "legacy file mode"? I like using the latest version and don't want the library author to have an excuse not to support it
From outside, this seems easy enough - move those old APIs to CLR-only packages using the new VM's API, then forget about them. But things are never as easy as they seem, the libraries are probably massive and people are using them in some insane ways that will break regardless of what you change.The problem isn't so much the decision they made. The problem is they waited until RC2 to make it.
-
@Adynathos said in .NET Core angst:
I think that was the main problem of the python 2->3 transition - would it cost them so much if the python3 runtime could run files with python2 syntax in some "legacy file mode"?
AIUI, given what they were changing, yes.
Migrations require two things to overcome inertia: a really good reason to move away from the old, and a really good reason to move to the new. These are frequently independent. An acceptable pair is “get rid of security holes” and “makes nearly everything much faster”; it'll persuade even pretty conservative places to get their asses in gear. It also really helps if any breakage is really small and well described; it lets people do their own risk assessments.
But some people just don't seem to want to move. Even being out of extended security support doesn't seem to persuade them to move. :( I think I'll bitch about this some other time…
-
@dkf said in .NET Core angst:
given what they were changing, yes
I mean to parse the code and replace it with modern equivalents, maybe make a few subclasses on new objects which emulate the old API, while using the new core.
On the other hand, they still have not fixed threading in CPython, so maybe they have small development power.My motivation for updating is that when I write any program, the new version seems good and elegant, and the old version is disgusting. When using libraries I imagine their developers think the same, so I don't want to use the old disgusting version :)
But I guess if it is someone's job to maintain some stable deployments, updating is just more work for them and is not fun.
-
@Adynathos said in .NET Core angst:
On the other hand, they still have not fixed threading in CPython, so maybe they have small development power.
No, they've got quite a bit (by comparison with many software projects) but fixing it is mega-difficult. The problem is that threads without the GIL make it difficult to decide on little things like object ownership and lifetime, as the current model (encoded in the assumptions of billions of lines of Python) is that everything is shared. Fixing things requires going through a whole heap of code in order to figure out where to add in local locks, and implementing a VM model that can decide things like the lifetime problem. Or using an existing system such as the CLR or JVM, which is what some people have already done (and where this whole thing has already been solved). Except that those VM models come with rather large amounts of baggage…
There are other ways to solve it that require a lot less developer resources (such as strongly walling off threads from each other except when sent through highly controlled channels) but they're utterly incompatible with existing Python code. You think the switch from Python 2 to Python 3 was bad? This would be many times worse, because it would be that much more difficult to detect that there was a problem in the code (whereas writing output is at least pretty easy to grep for).
Ruby's technically in the same mess, but it's in such a lot of other, worse messes that what's one more? ;)
-
@dkf Some of what you said applies to basically all open protocols and systems out there. The whole internet is built upon hacks and bad protocols which can never be changed. Open standards and systems are doomed to become mediocre over time because you can't control their evolution.
I recently read the following blog post, which explains why Signal will never become a federated protocol/system. It makes some good points:
Reflections: The ecosystem is moving
At Open Whisper Systems, we’ve been developing open source “consumer-facing” software for the past four years. We want to share some of the things we’ve learned while doing it. As a software developer, I envy writers, musicians, and filmmakers. Unlike software, when they create something, it is...
-
@dkf said in .NET Core angst:
fixing it is mega-difficult
I do not say it is easy, but that other languages usually have threading support, and some also have garbage-collection at the same time (like JVM you mentioned).
@dkf said in .NET Core angst:
everything is shared
Yes, of course, that is what happens when I do low-level threading in C++ and that is what I would expect in Python - because that is what the OS gives you. I do not expect shared memory to have some automatic mutexes, if I write to the same structure from 2 threads, it is my fault.
If I wanted the "everything is safe and synchronized" model, there ismultiprocessingmodule. But I usually use Python for numeric / image-processing tasks - so for example pre-process 100 images and combine them into one - it would be nice to parallelize the preprocessing, but then moving the data through some inter-process-communication would be inefficient.
-
@dkf said in .NET Core angst:
Migrations require two things to overcome inertia: a really good reason to move away from the old, and a really good reason to move to the new. These are frequently independent. An acceptable pair is “get rid of security holes” and “makes nearly everything much faster”; it'll persuade even pretty conservative places to get their asses in gear. It also really helps if any breakage is really small and well described; it lets people do their own risk assessments.
The thing is that nobody is expecting people to migrate their bespoke code from current .NET to .NET Core.
-
@Adynathos said in .NET Core angst:
so for example pre-process 100 images and combine them into one - it would be nice to parallelize the preprocessing, but then moving the data through some inter-process-communication would be inefficient.
This video @cartman82 posted seems to indicate that's possible (using process pools, IIRC), and that Python proper is the IPC method/glue.
-
@Adynathos said in .NET Core angst:
I do not expect shared memory to have some automatic mutexes
C++ doesn't use shared memory nearly so much (at least with code that's following current best practice) and so doesn't feel the costs of the locks in that part of the memory management system nearly so much. Yes, it's possible to make
newavoid these sorts of things through the use of per-thread memory pools, but then you've got a devil of a time elsewhere if those objects migrate to another thread. (That's where it all gets into GIL territory.)moving the data through some inter-process-communication would be inefficient.
Shared memory segments? Rather voodoo-ish, but fast provided you get the communications protocol sorted out. (I used to know of commercial image processing suites that did this…)
-
@asdf said in .NET Core angst:
Some of what you said applies to basically all open protocols and systems out there. The whole internet is built upon hacks and bad protocols which can never be changed. Open standards and systems are doomed to become mediocre over time because you can't control their evolution.
The thing that's most likely to happen with open systems and protocols, provided they're successful at all, is that they get broader. Supporting a wider range of use-cases is definitely the most likely outcome (other than outright death through disinterest) and that's not evolution in a way that the original author really thinks of; they tend to be much more focused on making things deeper as that's much more playing to their expertise and the experience of others is not rated nearly so highly.
-
@dkf said in .NET Core angst:
locks in that part of the memory management system nearly so much
So you mean that every time you touch an object, things like refcounts will be written so they need to have mutexes on everything?
Concurrency is indeed difficult to add if the system has not been designed with it in mind in the first place.@dkf said in .NET Core angst:
Shared memory segments?
Probably the only feasible solution. It requires some funny casting of numpy arrays, but should work.
-
@Adynathos said in .NET Core angst:
So you mean that every time you touch an object, things like refcounts will be written so they need to have mutexes on everything?
Concurrency is indeed difficult to add if the system has not been designed with it in mind in the first place.Basically, yes. Determining when to throw objects away is rather difficult when there are (part-)owners in potentially many threads. Knowing how reference-counting systems work and stop-the-world GC works, I remain very impressed at how well the CLR and JVM cope.
-
@Adynathos said in .NET Core angst:
So you mean that every time you touch an object, things like refcounts will be written so they need to have mutexes on everything?
If you're just incrementing/decrementing a reference count and not writing anything else, you can use atomic instructions and skip the full lock — I think that saves about half the cost if the lock is uncontested, and more if it is contested since you never go into a spinlock or kernel-mediated situation. There's more to memory management than reference counts though, and a generic approach in java/.net will need to be significantly more complicated than something you'll write yourself.
-
@PleegWat said in .NET Core angst:
you can use atomic instructions and skip the full lock
Still forces a bus synchronization; those things still have quite a lot of cost.
-
@Adynathos said in .NET Core angst:
I mean to parse the code and replace it with modern equivalents, maybe make a few subclasses on new objects which emulate the old API, while using the new core.
This is only possible with Py2 applications written with all the Py3 semantics in mind. You can't do it with just any old code. There's been a tool to make all the superficial changes automatically from the very start.
-
@dkf said in .NET Core angst:
No, they've got quite a bit (by comparison with many software projects) but fixing it is mega-difficult. The problem is that threads without the GIL make it difficult to decide on little things like object ownership and lifetime, as the current model (encoded in the assumptions of billions of lines of Python) is that everything is shared. Fixing things requires going through a whole heap of code in order to figure out where to add in local locks, and implementing a VM model that can decide things like the lifetime problem.
I'm kinda curious how well transactional memory would fix this. You can do reads against shared objects (like the global variable store or whatever) without locking, and the hardware will tell you if things went wrong (i.e., somebody wrote to the memory you were accessing).
Normally, I'm a bit suspicious of the idea that transactional memory will magically make everything better, but in this case I could see how it could help.
-
@cvi said in .NET Core angst:
I'm kinda curious how well transactional memory would fix this. You can do reads against shared objects (like the global variable store or whatever) without locking, and the hardware will tell you if things went wrong (i.e., somebody wrote to the memory you were accessing).
I suppose it might help with making a concurrent GC, but I don't think it helps with deciding whether a thread-shared object has really been finished with; that requires the threads to come to an agreement, and that requires synchronization (especially once you move to larger systems). It's better to write the code to be lock-free in the first place, though that's got other consequences.
.NET Core is Boiling the Ocean
