I'm on AWS currently. They keep their old / uncool stuff around in a nice way (and totally seem to drop ball on other stuff that matters less like their new Amazon Linux 2 effort - python 3 support in that is totally wonky etc).
For various reasons, supporting new runtimes was never an easy task, even for small version bumps. This has changed drastically, starting with Java8 runtime, to the recently announced NodeJS beta, and to the closed alpha of Python 3 (remember this is Python 3.7). If you followed recent announcements from Google you probably can connect the dots.
I think we are pretty open on what we are working on to our customers, as long as an NDA is signed. If you are interested be sure to let our cloud support team know!
Disclaimer: I'm on App Engine SRE team.
I work on a project on GAE standard and the platform was chosen before I started. I would say this was the worst possible solution to chose and the biggest cost for us right now.
The most annoying point is that it is actually not easy at all to switch to the Flexible environment, because libraries are completely different.
Examples of troubles :
- new google-cloud libraries run in the flexible environment but not in the standard one (ex: google-cloud-pubsub doesn't run in the standard env after 0.27, and the doc for 0.27 is dead: https://google-cloud-python.readthedocs.io/en/0.27.0/pubsub/...)
- traditional standard env libraries do not run in the flexible env. The most typical example is NDB for the Google datastore.
Which means that migrating from the standard to the flexible env requires you to rebuild EVERYTHING that touches Google services... Great, then I'd better just switch to AWS instead!
What's moer, flexible env is nice but for some reason it is not possible to have basic scaling anymore, nor is it possible to scale down to 0 when needed, which makes modular apps much more costly (previously we would have several services and when unused they just scaled down to 0).
On top of that we just watched services get deprecated one after the other (mail service, then the datastore backup etc.) and old troubles not getting fixed (like memory problems with queries).
Service deprecation is not taken lightly, and we guarantee 12 months per GCP deprecation policy (https://cloud.google.com/terms/deprecation). Of the services you mentioned, I don't think mail API is officially deprecated (per https://cloud.google.com/appengine/docs/deprecations/), and Datastore Backups is superseded by Managed Export (https://cloud.google.com/datastore/docs/export-import-entiti...).
Not sure about the memory problems you mentioned though.
Disclaimer: I'm on App Engine SRE team.
"multi quarters" of work is odd phraseology. Does the GAE team prefer smaller, easier to schedule, features to longer more difficult projects to keep pace with development of the underyling toolset?
"pretty open" "as long as you sign an NDA" is borderline oxymoronic.
"enterprise focused" speaks for itself.
GAE is a business and has a niche. Perhaps they'd really be dead if they didn't focus on a set of paying customers. NDAs are the norm for enterprise and are reasonable given that they want to maintain their niche.
It's less reasonable for me to comment on their development/deployment methodology since I don't work at Google, but multiple quarters of work doesn't seem unusual for getting products like these deployed across multiple global data centers and achieve the kind of reliability required by these customers.
It also depends on how long companies like Redhat support it (CentOS 6 comes with Python 2.6 and CentOS 7 comes with Python 2.7).
They support their products 10 years, or indefinitely if you pay extra for it, so Redhat will support Python 2 until June 30, 2024.
If I understand it correctly, that means CentOS will too.
I look forward to using c99 and Python 2.7 for many years to come. There are more then enough Companies and Devs to keep Python 2 ticking over forever.
What it certainly true is that it will take exponentially more work to keep Python 2 alive. They're not allowed to use the name so that's an instant usage drop-off. And many major third party libraries are dropping support too.
You're probably right though. You'll probably get to use Pytwo (or whatever they call its) for a few more years yet.
ISO C++14 requires C99 library compatibility, ISO C++17 requires C11 library compatibility only when C++ doesn't already offer better alternatives.
For C developers there is clang/gcc integration in Visual Studio.
"Modern C++ Game Development on Microsoft Platforms"
Of course, that would be much less painful than Python 3, because C11 is (a) almost entirely compatible with C99, and (b) not noticeably slower.
It's quite hard to write a C89 program that isn't C99. Basically any Python 2 program that uses 'print' won't be valid Python 3. Even after fixing that, I always find a bunch of string related problems.
In practice I imagine some day some PhD student will take it upon themselves to rewrite a significant chunk of libraries to be python 3 compatible, and then we could move on from there, but I wouldnt want to force anyone to spend the time doing a massive Python 3 rewrite.
Can the Java runtime implement the full Servlet 3.1 spec now? It's 5 years old (and most Scala http libs don't support blocking Servlets anymore).
This resulted in more developers actually porting their libraries, an effort that had been basically non-existent before. The result was that the 3.4 ecosystem actually got mature enough that Real Work could get done, and more end-users started moving.
IIRC 3.3 also had some big performance problems that were sorted in 3.4, but I cannot remember the details.
Personally, I did very little with 3.2 but actually built Real Stuff only with 3.4.
I wonder, though, if future development should target Docker/K8S and GAE should only be the domain of legacy applications.
Neither the question nor the answer in your link compare Docker and App Engine.
Docker is a containerization platform, whereas App Engine is a PaaS (platform as a service). Their functions are wholly different.
Very, very loosely; Docker is about building and running an individual package of some software. Basically, bundling software and running bundles. PaaS are platforms for developing, running, and managing (often pre-bundled) software.
I mean, other languages have new versions too...
Python 2 bolted on Unicode support, so now you had two kinds of strings (old-style strings and Unicode strings) with implicit conversions between them (that would blow up spectacularly when you least expected it) and overall a huge mess.
Python 3 removes the old-style strings (replacing them with the "bytes" type and explicit conversions), so that we once again have only one type of string, and once again things are simple. This clean-up unfortunately means that code relying the Python 2 string type confusion will break.
Other languages simply carry these bugs around forever.
What changed is that Python 3 was modified, and libraries were added to both Python 2 and 3, so that it started to became practical to write code that could work on both 2 and 3. The result: instead of having to transition your entire program and all its dependencies simultaneously, people could work incrementally, making little improvements here and there so that programs would keep working in 2, and eventually work in 3 as well. Various hacks were also created so that Python 3 could handle stuff like filenames (!).
It would have been much better had the Python 3 developers made it easier to transition from 2 to 3 from the start, but it's finally easier. It's still somewhat painful; mercurial still hasn't transitioned, and it's not clear that they ever will. I'm unhappy about what the Python developers did earlier, but I think they've made good strides in trying to finally make it much easier to transition from Python 2 to Python 3.
The main takeaway here should be, "make it as PAINLESS as POSSIBLE for your existing users to transition to a new version". It's okay to change APIs, but use different names or use versioned APIs. It's okay to change other things, but make it easy for people to modify parts of their program at a time. You'd think that'd be obvious, but it's clear that really smart people don't always think about that.
Python 3, and Perl 6 did. I don't think anyone uses Perl 6.
In the meantime, Perl 5 keeps getting better while mostly maintaining backwards compatibility. So basically we avoided the problem of transferring people from one language version to the next by allowing them to stay with Perl 5.
Perl 5 maintains backwards compatible with code written 30 years ago for the first version of Perl. Which is the reason you have to opt-in to strict mode.
The last major change in Perl 5 that caused widespread problems was done to improve security. (v5.18 hash randomization)
Mostly what it did was cause already existing bugs in user code to happen more often, making them easier to track down.
Also thanks for pointing out that not enough people use Perl 6, as it is an awesome language that brings in a lot of ideas from other languages and makes them seem as if they have always belonged together.