www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Dear Google Cloud: Your Deprecation Policy is Killing You

reply jmh530 <john.michael.hall gmail.com> writes:
Ran across this via reddit yesterday and thought people here 
might find it interesting.

https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc
Aug 16 2020
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here 
 might find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc



I enjoyed it.
We should learn from this.
Aug 16 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Aug 16, 2020 at 11:27:47PM +0000, Stefan Koch via Digitalmars-d wrote:

 On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might
 find it interesting.
 
 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc


 
 
 I enjoyed it.
 We should learn from this.


I feel like we're not even in that ballpark yet. First things first, we
need to stop releasing with new regressions... second, we need to stop
releasing with *any* regressions.  Third, now we can start talking about
deprecation policy.


T

-- 
Public parking: euphemism for paid parking. -- Flora
Aug 16 2020
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/16/20 6:03 PM, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might find 
 it interesting.
 
 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-kill
ng-you-ee7525dc05dc 
 


That is a fabulous article, thanks!

-Steve
Aug 16 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/16/2020 3:03 PM, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might find it 
 interesting.
 
 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-kill
ng-you-ee7525dc05dc 
 


Thanks! Steve, as always, writes great articles.
Aug 16 2020
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/16/20 8:08 PM, Walter Bright wrote:

 On 8/16/2020 3:03 PM, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might 
 find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-kill
ng-you-ee7525dc05dc 


 
 Thanks! Steve, as always, writes great articles.


Our Steve, too, I should add.
Aug 18 2020
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-08-17 00:03, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might find 
 it interesting.
 
 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-kill
ng-you-ee7525dc05dc 


If you never can remove anything, you have to live with the old baggage 
forever. The means documentation, books, specs and other material that 
wants to be complete need to still include the deprecated things. There 
are also some language issue that can never be fixed, like implicitly 
convert integer and character literals to bool (I guess they could be 
fixed by introducing new types). With a library code it's much easier, 
just point users to a new function.

This is basically what happens to C++. Adding new things, never remove 
the old. The old will always be around. I'm sure there still new code 
being written that uses old style C++. The biggest advantage and 
disadvantage with C++ is the C source level compatibility.

Perhaps something like editions in Rust. For D, that would be something 
like supporting D2 and adding new non-breaking things to it. At the same 
time developing D3 which gets the new non-breaking things and possibly 
breaking changes as well. Both editions working side by side in the same 
application. But it's the same problem as always, we don't have the 
manpower.

-- 
/Jacob Carlborg
Aug 17 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 01:16:00PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
[...]

 If you never can remove anything, you have to live with the old
 baggage forever. The means documentation, books, specs and other
 material that wants to be complete need to still include the
 deprecated things.


[...]

Not necessarily. You can remove it from documentation, but leave the
implementation intact, so that newer code will stop using it but older
code will not break.

But yeah, backwards compatibility does come at a cost.


T

-- 
Why have vacation when you can work?? -- EC
Aug 17 2020
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 17 August 2020 at 11:16:00 UTC, Jacob Carlborg wrote:

 This is basically what happens to C++. Adding new things, never 
 remove the old. The old will always be around. I'm sure there 
 still new code being written that uses old style C++. The 
 biggest advantage and disadvantage with C++ is the C source 
 level compatibility.

 Perhaps something like editions in Rust. For D, that would be 
 something like supporting D2 and adding new non-breaking things 
 to it. At the same time developing D3 which gets the new 
 non-breaking things and possibly breaking changes as well. Both 
 editions working side by side in the same application. But it's 
 the same problem as always, we don't have the manpower.


Personally I much prefer the current approach where we can sort 
of take deprecations on a nice smooth gradient. With a hard D2/D3 
cut it would be difficult to know when to make the jump, and old 
code that wasn't worth switching to D3 would eventually fall off 
the update bandwagon. I think the current approach of "opt in 
flag new feature, deprecate old feature, fallback flag old 
feature, old feature removed" is a good one.

I'm in favor of killing old code. Google and MS can afford to 
carry deprecations because they can literally throw hundreds of 
people at it. (And make no mistake - it costs them.) D should 
focus on being the best language it can be in each moment. I 
think our reaction to this should much rather take the form of 
cautiously weighing new features against their maintenance cost 
than worrying about whether or not D should deprecate old ones. 
Worstcase, you get old features that linger and look usable 
despite nobody being willing to maintain them or being actively 
discouraged from maintaining them, cough std.json cough.
Aug 17 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 02:17:58PM +0000, FeepingCreature via Digitalmars-d
wrote:
[...]

 I'm in favor of killing old code. Google and MS can afford to carry
 deprecations because they can literally throw hundreds of people at
 it. (And make no mistake - it costs them.) D should focus on being the
 best language it can be in each moment. I think our reaction to this
 should much rather take the form of cautiously weighing new features
 against their maintenance cost than worrying about whether or not D
 should deprecate old ones.  Worstcase, you get old features that
 linger and look usable despite nobody being willing to maintain them
 or being actively discouraged from maintaining them, cough std.json
 cough.


I think we should pay attention to the distinction Steve draws between
deprecation in the sense of discouraged but still working, vs.
deprecation in the sense of it won't compile until you fix your code.
One way to discourage the use of certain deprecated features but still
allow old code to work, is to deprecate them, then undocument them, but
never remove them.  So the old code still compiles and works as before,
but the old features are no longer documented and so new code will no
longer use them.

Of course, as you said, maintaining forever backward compatibility does
come with a cost, a potentially very heavy one.  You have to keep the
old code around basically forever, *and* maintain it in the face of new
changes. And the existence of this old code may forever prevent certain
things from ever being fixed, because the fix would break the old code
in a fundamental way.  In some cases you might be able to re-implement
the old code in terms of the new, but that isn't always possible and
it's a big resource sink. Probably bigger than we have the manpower for.



T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL
Aug 17 2020
parent reply Mathias LANG <geod24 gmail.com> writes:
On Monday, 17 August 2020 at 14:38:54 UTC, H. S. Teoh wrote:

 I think we should pay attention to the distinction Steve draws 
 between deprecation in the sense of discouraged but still 
 working, vs. deprecation in the sense of it won't compile until 
 you fix your code. One way to discourage the use of certain 
 deprecated features but still allow old code to work, is to 
 deprecate them, then undocument them, but never remove them.  
 So the old code still compiles and works as before, but the old 
 features are no longer documented and so new code will no 
 longer use them.


Another key difference is that you can opt-out of the 
deprecation, pretty easily. Just don't update your compiler. Or 
your dependencies. We don't remove old versions from the website, 
so if your code compiled with v2.052.0, then it will still 
compile with it today... Unless you're using Mac, in which case 
you will be force to upgrade to a recent version, because Apple.

Another example that I really like is Github. You guys remember 
we renamed the organization name on Github years ago ? Well the 
redirect still works 
(http://github.com/D-Programming-Language/dmd).
Aug 17 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 03:17:23PM +0000, Mathias LANG via Digitalmars-d wrote:
[...]

 Another example that I really like is Github. You guys remember we
 renamed the organization name on Github years ago ? Well the redirect
 still works (http://github.com/D-Programming-Language/dmd).


Believe it or not, some of my clones still refer to upstream using this
old redirect. :-)


T

-- 
An imaginary friend squared is a real enemy.
Aug 17 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/17/2020 8:42 AM, H. S. Teoh wrote:

 On Mon, Aug 17, 2020 at 03:17:23PM +0000, Mathias LANG via Digitalmars-d wrote:
 [...]

 Another example that I really like is Github. You guys remember we
 renamed the organization name on Github years ago ? Well the redirect
 still works (http://github.com/D-Programming-Language/dmd).


 
 Believe it or not, some of my clones still refer to upstream using this
 old redirect. :-)


Mine too.
Aug 17 2020
prev sibling parent Ben <benjiro benjiro.com> writes:
On Monday, 17 August 2020 at 15:17:23 UTC, Mathias LANG wrote:

 Another key difference is that you can opt-out of the 
 deprecation, pretty easily. Just don't update your compiler. Or 
 your dependencies. We don't remove old versions from the 
 website, so if your code compiled with v2.052.0, then it will 
 still compile with it today...


Good luck with that. I assume you also like your application open 
to potential security issues as you are now relying on older 
compiler version and packages ( that also need specific aka newer 
compiler versions at times! ).

Its always easy to say you can opt-out but the reality is 
different.
Aug 20 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/17/2020 4:16 AM, Jacob Carlborg wrote:

 This is basically what happens to C++. Adding new things, never remove the old.


They have finally removed a couple things. When C89 was standardized, the "sign 
preserving" rule that half of the C compilers followed was abandoned.

So it's not absolute.
Aug 17 2020
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here 
 might find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc


Anything Google touches goes this way. They have infinite 
resources to reqrite stuff so no one cares about the sole 
developer maintaining a project ...

Example is LLVM. Each version has breaking changes. For no good 
reason, causing users to have to fix their code. Google touch.
Aug 17 2020
parent James Lu <jamtlu gmail.com> writes:
On Monday, 17 August 2020 at 21:40:48 UTC, Dibyendu Majumdar 
wrote:

 On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here 
 might find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc


 Anything Google touches goes this way. They have infinite 
 resources to reqrite stuff so no one cares about the sole 
 developer maintaining a project ...

 Example is LLVM. Each version has breaking changes. For no good 
 reason, causing users to have to fix their code. Google touch.


I wonder if it's because the engineers never design things the 
right way the first time.

I haven't ever used a Tensorflow project without deprecation 
warnings.
Aug 24 2020
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/16/20 6:03 PM, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here might find 
 it interesting.
 
 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-kill
ng-you-ee7525dc05dc 


cc Walter, Atila

This article is very illustrative on how we could approach deprecation. 
We have been closer to Google's approach than Emacs' or Java's.

I've suggested this coyly for years - coyly because it seemed so unclean 
and compromise-y: we should deprecate "psychologically", by keeping 
things but using (natural) language and UX techniques to deemphasize the 
deprecated libraries and (programming) language features. Use gray text, 
smaller, italicized, slightly more difficult to read. Put it one extra 
click away. Start those sections with a RED YELLING warning. Emphasize 
disadvantages and point to better approaches. Over time, even remove 
documentation for deprecated features but leave them in. And so on. 
Emacs and Java have shown that this works.
Aug 18 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 18, 2020 at 06:17:36PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]

 I've suggested this coyly for years - coyly because it seemed so
 unclean and compromise-y: we should deprecate "psychologically", by
 keeping things but using (natural) language and UX techniques to
 deemphasize the deprecated libraries and (programming) language
 features. Use gray text, smaller, italicized, slightly more difficult
 to read. Put it one extra click away.  Start those sections with a RED
 YELLING warning. Emphasize disadvantages and point to better
 approaches. Over time, even remove documentation for deprecated
 features but leave them in. And so on. Emacs and Java have shown that
 this works.


Sounds like a good idea. Undocument deprecated features, but don't
actually remove them, leave them in so that existing code that depends
on them won't break.  But undocument them so that new code won't use
them anymore.  Either that, or wrap the docs in big yellow warning
signs.

This does not work for some things, though. Things like integer
promotion, for example, cannot be changed without causing breakage, no
matter how you try to do it.  Fundamental things of this nature will
basically have to remain the way they are forever.

But many other things could change -- even the range API, for instance,
can be rewritten -- as long as it's given a new name, like std.v2.range
or something like that. Over time, deprecate std.range, then undocument
it, but leave it in so that old code still works, but new code will stop
using it.  Of course, this also means everything that depends on the old
API will have to be duplicated and reimplemented for the new API, so
changes to foundational things of this sort will have to be carefully
weighed lest we drown in the resulting technical debt.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying
Aug 18 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/18/20 6:43 PM, H. S. Teoh wrote:

 Things like integer
 promotion, for example, cannot be changed without causing breakage, no
 matter how you try to do it.  Fundamental things of this nature will
 basically have to remain the way they are forever.


I disagree. There are cases in which it's possible to surgically remove 
the bad cases and keep the good cases. We've done that a few times:

* We managed to effectively remove all "bad" uses of the comma operator 
and keep all "good" uses. It went over very smoothly. The rule we 
introduced was you can't use the result of the comma operator.

* We improved comparison operators by simply making them 
non-associative. This made chained comparisons such as a<b<c illegal 
without otherwise impacting semantics.

* We got rid of the dilemma between using a ton of casts among integral 
sizes, and allowing lossy conversions. That also went over very 
smoothly. This does not compile:

ubyte b = array.length;

But this does:

ubyte b = array.length & 0xff;

(Interesting detail, the generated code doesn't even contain the "&": 
https://godbolt.org/z/1Go91n)

So there is opportunity, we just need to carefully search for it.

On the face of it, the bad cases of integral promotion concern 
converting negative integrals to unsigned integrals. I don't think we 
apply Value Range Propagation there. If we did, presumably we could 
eliminate at least some bad cases without impacting the good cases.
Aug 19 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 August 2020 at 13:46:31 UTC, Andrei Alexandrescu 
wrote:

 * We got rid of the dilemma between using a ton of casts among 
 integral sizes, and allowing lossy conversions. That also went 
 over very smoothly.


Have you written much code using this? It is so painful outside 
the simple examples.

The others are wins, but this leaves a LOT to be desired and is a 
frequent asked question with people coming from C too. I used to 
defend it but the more I use it, the more I hate it.


 If we did, presumably we could eliminate at least some bad 
 cases without impacting the good cases.


but yeah this is always worth exploring.
Aug 19 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Aug 19, 2020 at 01:56:38PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 On Wednesday, 19 August 2020 at 13:46:31 UTC, Andrei Alexandrescu wrote:

 * We got rid of the dilemma between using a ton of casts among
 integral sizes, and allowing lossy conversions. That also went over
 very smoothly.


 
 Have you written much code using this? It is so painful outside the
 simple examples.
 
 The others are wins, but this leaves a LOT to be desired and is a
 frequent asked question with people coming from C too. I used to
 defend it but the more I use it, the more I hate it.


[...]

Yeah, this was a royal pain to work with. The fact that you cannot write
this:

	ubyte b;
	b = -b;	// NG, no thanks to integer promotion rules

is a royal, royal pain in real-world code.  It essentially marginalizes
narrow ints into a pariah caste where everything has to be cast()'ed
(caste-ed :-P) just to please the nitpicky compiler, with no real gain
in code quality (it is already beyond obvious in the code that we are
working with narrow ints -- *everything* uses ubyte in that piece of
code so int promotion is nothing but a needless roadblock), increase in
verbosity, decrease in readability, and just death by a thousand needle
pricks all-round.

It was so annoying to work with that I wrote a nopromote.d module with
an infectious narrow int wrapper that forces non-promoting arithmetic,
just so I can write code without a hundred casts.

"Went over very smoothly" is a total mockery of the reality of the
situation.


T

-- 
That's not a bug; that's a feature!
Aug 19 2020
parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 19 August 2020 at 15:59:52 UTC, H. S. Teoh wrote:

 "Went over very smoothly" is a total mockery of the reality of 
 the situation.


 T


I concur. And to follow the "Bugzilla or GTFO" rule: 
https://issues.dlang.org/show_bug.cgi?id=20678
Aug 19 2020
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Thursday, 20 August 2020 at 06:30:11 UTC, Mathias LANG wrote:

 On Wednesday, 19 August 2020 at 15:59:52 UTC, H. S. Teoh wrote:

 "Went over very smoothly" is a total mockery of the reality of 
 the situation.


 T


 I concur. And to follow the "Bugzilla or GTFO" rule: 
 https://issues.dlang.org/show_bug.cgi?id=20678


Guys.. these days why do we even need the integer promotion rules?

Thanks to Kenji it is very easy to do it by hand:

```
byte b;
auto i = -int(b);
```

So I think D should do what it did before (before 
-preview=intpromote) and /not/ promote to integers.
Aug 20 2020
prev sibling parent user1234 <user1234 12.de> writes:
On Thursday, 20 August 2020 at 06:30:11 UTC, Mathias LANG wrote:

 On Wednesday, 19 August 2020 at 15:59:52 UTC, H. S. Teoh wrote:

 "Went over very smoothly" is a total mockery of the reality of 
 the situation.


 T


 I concur. And to follow the "Bugzilla or GTFO" rule: 
 https://issues.dlang.org/show_bug.cgi?id=20678


 From what I've read recently, the problem is not the dprecation. 
The problem is that a deprecation has been used to hide a 
limitation of the backend.

The problem is that DMD backend generates instructions for 32bit 
R/M or 64 bits only R/M only. It does not care if the source type 
is 8bit or 16 bit. The source type is supposed to be at least a 
32 bits int. so the big problem is... if you try to write an 
unalagined data, the instruction will be wrong. If you write an 
ushort that starts two bytes before a new system aligned address 
then the two first bytes of the next system aligned address will 
be eventually corrupted. The 16 bits versions of the instructions 
are never generated, that is the real problem. D backend wants 
everything to be 8 or 4 aligned.
Aug 20 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/18/2020 3:17 PM, Andrei Alexandrescu wrote:

 I've suggested this coyly for years - coyly because it seemed so unclean and 
 compromise-y: we should deprecate "psychologically", by keeping things but
using 
 (natural) language and UX techniques to deemphasize the deprecated libraries
and 
 (programming) language features. Use gray text, smaller, italicized, slightly 
 more difficult to read. Put it one extra click away. Start those sections with
a 
 RED YELLING warning. Emphasize disadvantages and point to better approaches. 
 Over time, even remove documentation for deprecated features but leave them
in. 
 And so on. Emacs and Java have shown that this works.


I agree. We've done too much feature removal. Your suggestions are good. On a 
pragmatic note, we have UNDEFINED_BEHAVIOR and IMPLEMENTATION_DEFINED macros
for 
the documentation - we could add DEPRECATED and then style it as seems
appropriate.

I created the undeaD library because it was simply too much work to transfer
the 
old D1 date/time code to the new stuff. There was no straightforward way to do 
it. I needed it for my own code. We should have left it in, just de-emphasized 
it as you suggest.
Aug 19 2020
parent James Lu <jamtlu gmail.com> writes:
On Wednesday, 19 August 2020 at 10:39:07 UTC, Walter Bright wrote:

 On 8/18/2020 3:17 PM, Andrei Alexandrescu wrote:

 [...]


 I agree. We've done too much feature removal. Your suggestions 
 are good. On a pragmatic note, we have UNDEFINED_BEHAVIOR and 
 IMPLEMENTATION_DEFINED macros for the documentation - we could 
 add DEPRECATED and then style it as seems appropriate.

 I created the undeaD library because it was simply too much 
 work to transfer the old D1 date/time code to the new stuff. 
 There was no straightforward way to do it. I needed it for my 
 own code. We should have left it in, just de-emphasized it as 
 you suggest.


I have a question: Why were the !> !< !>= !<= etc operators 
removed?
Aug 24 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
A topical example for us:

https://github.com/dlang/dmd/pull/11581
Aug 19 2020
prev sibling next sibling parent Canklederz <zacharianic.holson0853 gmail.com> writes:
On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here 
 might find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc


I also prefer the current approach where we can sort of take 
deprecations on a nice smooth gradient.
Aug 20 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 August 2020 at 22:03:07 UTC, jmh530 wrote:

 Ran across this via reddit yesterday and thought people here 
 might find it interesting.

 https://medium.com/ steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc


Yes, the basic theme is relevant, but the article is inaccurate. 
Python 2 is on their 
https://cloud.google.com/appengine/docs/standard/long-term-support page.

The upgrading issues aren't really Python 2 vs Python 3. The main 
issue is that the original App Engine services (like task queue, 
memcache and the image rescaling service) are not available on 
Google Cloud in their original form. They still work for Python 2 
runtimes though.

That said, core infrastructure such as Datastore is available as 
a modified layer on top of Firestore (that actually performs 
better than native Firestore). So they do provide compatibility 
layers.

So, the serious challenges they give external developers have 
less to do with APIs than restructuring services and business 
policies. Google seem to have made the decision that they are 
restructuring to serverless, standard runtimes and many loose 
decoupled services. Whereas the original App Engine eco system 
provided custom runtimes with better out-of-the-box integration 
of services, and thus allowed for more rapid development.

As a consequence of this policy shift a worse change is coming 
next year, when they turn off spending limiting daily budgets (a 
feature many developers rely on as a safety feature). So you have 
to write your own code to shut down services when something goes 
wrong and blows your budget... (like AWS).

Sadly, AWS, Azure and GC seem to try to become more alike rather 
than standing out. Some might say it is a sign of industry 
maturity others might say it is a lack of vision. Perhaps both.
Aug 30 2020