I would argue that is a good thing and in the case of Spring, doesn't feel true. In part, Spring is so hard to learn because it has too much support for legacy stuff (though this may have changed in the last few years).
The only issue with not supporting retro-compatibility is because the JVM doesn't support retro compatibility. I recently tried to upgrade an application to the latest version of Java (I think it was Java 12) and found that date formaters were completely changed to match an ISO standard which broke a lot of code. We also found a similar problem with the Java 8 transition as well forcing a huge upgrades to our libraries.
I am of the view that libraries and frameworks should support not support retro compatibility but the language should. This way, if you don't want to upgrade your library then you don't have to.
Using the web as an example, old Angular JS applications still work today as they did back when they were first written. I doubt applications written in the first version of Spring will work with the latest version of the JVM.
I daily drive FF and even develop using it. Everyone else in the company use Chrome. Recently one of our clients complained about a performance issue, I tried to replicate it on my fast PC, but could not replicate. The people who could replicate it were on Chrome, but when they followed the replication steps in FF, the problem disappeared.
Google web applications still not great, but still usable I find. Facebook performance isn't great either.
I only test in Firefox, because FF is my browser of choice. Everyone else in the office only tests on Chrome because that is their browser of choice. We all know it is wrong, but cross browser compatibility makes it so much easier to forget that there are subtle differences.
Fun fact, we recently found a performance issue on one of our products which I was completely unaware of because it didn't affect. Even now, we cannot get Chrome to match FF's performance especially (of all things) for Google maps. Just goes to show that basic assumptions that Chrome is faster than Firefox are not 100% accurate. Like most things, it depends.
I use Firefox day in and day out and the only time I have found myself using Chrome is when I have to do profiling and even then that is because profiling tools in all browsers kinda sucks.
I have often wondered what is the killer feature that Chrome dev tools has that Firefox does not that forces people to switch back to Chrome as this seems to be a common refrain and while I don't work on the dev tools I sometimes wonder what awesome feature I am missing in Chrome...
In some cases, I actually find Chrome lacking. For example, the ability to see what events are attached to a dom element.
DISCLAIMER: I do not work on the developer tools for Chrome or Firefox and don't do much CSS.
We have been using Stride for a few months and are baffled by how bad it can be and how it seems to miss key features that was in Hipchat (such as a call indicator). I used to always say "this is not the hard part of your job, stride " because it would fail to do basic things such as display images.
A colleague of mine found a security issue but had a hard time logging it and had to make it public.
Basically, I got the impression that the stride team in Atlassian was a bit of a mess.
All that said, it is sad to see it go because it was an alternative to the near monopoly of Slack. The only other alternative is rocket chat and MS teams now.
While I agree that the more investment is probably required in rural areas, I think your assertion that the reason why rural areas are being under funded is incorrect.
Reality is that more people now live in urban areas[1]. Democracy being what it is, most funding goes to the majority - which are in the city. Add to that that setting up this infrastructure is often not cost effective for a private business (due to a lack of customers) and that most rural communities prefer less government intervention (ie less taxes), we have a situation where there is little impetus to invest in rural communities by private companies and governments (at least local) don't have funding to pay for service.
>Democracy being what it is, most funding goes to the majority - which are in the city.
Democracy has to be more than two wolves and a sheep deciding what's for dinner.
It's true that the majority can just vote to line their own pockets and leave the minority in squalor, but that leaves a pretty shitty country leftover. Many of these rural areas look like third-world countries and that's not something us urbanites should be proud of.
Scholarship money disproportionately goes to lower income students, but that doesn't mean we should stop giving them scholarship money.
Note however that the census definition of "urban" is very broad. I live in a 7,000 population town and between myself and a few neighbors, we're on about 100 acres--not counting adjacent conservation land. We're urban according to the census.
I have never really coded in C# or in the .Net platform, but I remember when it came out.
I always thought that prior to C# 1.0 being released, the Java language was stuck. There was no generics, annotations, enumerations, for/each loops or auto boxing which made programming in Java not only painful but dangerous (especially with the lack of generics and for/each). I personally, never considered anything before Java 1.5 "good enough".
I was always under the impression that these language change were in response to what C# and many of these language concepts were practically copied from C#. Is this actually the case?
In the case of generics, C# got them right (but required changes to CLR 2.0) and then Java tried to copy the idea (without requiring any changes to the JVM) but fucked them up. Look up "type erasure": Java's underlying compiled classes weren't actually generic, and generics compiled down to "Object" and casts (which are less efficient, and can be subverted at runtime). Generics were implemented by the Java compiler, not the JVM runtime.
I am glad you're pointing this out, because the limitations of the JVM are often overlooked as a big reason for why "we can't have nice things" in Java.
"Frameworks do not keep retro-compatibility"
I would argue that is a good thing and in the case of Spring, doesn't feel true. In part, Spring is so hard to learn because it has too much support for legacy stuff (though this may have changed in the last few years).
The only issue with not supporting retro-compatibility is because the JVM doesn't support retro compatibility. I recently tried to upgrade an application to the latest version of Java (I think it was Java 12) and found that date formaters were completely changed to match an ISO standard which broke a lot of code. We also found a similar problem with the Java 8 transition as well forcing a huge upgrades to our libraries.
I am of the view that libraries and frameworks should support not support retro compatibility but the language should. This way, if you don't want to upgrade your library then you don't have to.
Using the web as an example, old Angular JS applications still work today as they did back when they were first written. I doubt applications written in the first version of Spring will work with the latest version of the JVM.