And you are probably right about Google not changing its attitude on dynamic versus static.
I think your premises are flawed. Google uses a mix of C++, Python, Java, JavaScript, and Go, and all of those languages support both static and dynamic type checking. And Google clearly isn't happy with C++, otherwise they wouldn't have hired someone to develop Go. Furthermore, Go has substantially weaker static type checking than C++, so it doesn't look like Google is as adamant about static typing as you seem to be.
I started my career writing compilers and so I feel strongly about the benefits of static analysis.
Static analysis is nice, but you can only analyze information that is actually available at compile time, and a lot of information is not; that's why languages like C++ have added features like RTTI and dynamic casting. Furthermore, static type analysis can become enormously complex and be more hassle than it's worth, which is why Java uses type erasure and Go doesn't even provide generics at all. On the other hand, many dynamically typed languages are completely type safe and allow you to add type annotations that catch type errors early and easily; and with JIT compilation, they can even generate better code than static analysis. In practice, the differences between statically and dynamically typed languages are pretty fluid and ill-defined, and the choices are often not as clearcut as you seem to think.
I think we need to look at the gRPC specs to see if it handles this case.
Be my guest. I'm just telling you don't hold your breath for gRPC to take off.
The debate between synchronous calls and messaging is as old as the Internet.
No, I'm sorry, but you still don't understand. Asynchronous message passing is a programming language abstraction, not a network abstraction; it's what Alan Kay originally envisioned for Smalltalk methods.
The asynchronous approach is much, much more complex for the programmer to implement, because of the large number of states that must all be handled
The asynchronous approach is much, much more complex to implement on top of an RPC system. That's my point: RPC systems are a bad abstraction because they make asynchronous programming unnecessarily difficult.
The "little guy" is the Uber driver who makes less than minimum wage after costs. The "little guy" is the poor shlub passenger stuck with the drivers $25,000 in medial coverage, after an uninsured drunk causes a crash
If taxicab businesses pay better and provide better services, then both drivers and passengers can continue to use them.
The only thing you're supporting here is exploitation....idiot.
How can people who have a free choice of jobs and services be "exploited"? Exploitation can only happen when people take away choices, and that is what you are defending.
The point remains, making such a change should be done through government and not by starting a rogue company that ignores laws
Look, aren't you listening? Ride sharing companies were not covered by taxi laws; laws governing the ride sharing industry are new laws and I am pointing out that they are bad for consumers. And, you're absolutely right, I have no problem with people flaunting bad laws; as I was pointing out before: the US has a British legal system, not a Napoleonic one, so widespread civil disobedience is a legitimate and common way of changing the law.
he thing is, you say the taxi industry is a bunch of collusion, yet you are ushing in an industry where there may only be two major players.
There are only two major players because few companies are big enough to put up with the legal and political bullshit the people you favor are imposing on the industry.
Well whether travel for the disabled should be paid for by the government or not is a debatable case.
Anything is "debatable", but the side of the debate you are taking is the side of corruption and crony capitalism, because you are using "the disabled" as an excuse to hand monopolies to wealthy businesses.
Hey, amen to that. But he'll be going from bring able to support a family to working for practically minimum wage. But hey, as long as you got cheap rides right?
Yours is the typical, arrogant attitude of well-off people: "hey, I have enough money so that paying a little more doesn't bother me, so why should it bother anybody else?" And you don't even understand what's going on: taxi medallions are often held by well off investors who then rent out their fleet of taxis to drivers; those drivers are already at the bottom of the totem pole. For them to be able to drive for themselves as ride share drivers is often a step up.
People in less profitable areas still need service, physically disabled people still need access,
Yes, and as I explained before: trying to provide those services through taxi regulation simply forces other taxi riders to pay for them through increased fares. But providing service to less profitable areas and disabled people is something that society as a whole is responsible for, so it should be paid out of taxes, not through some non-transparent cost shifting involving government-granted monopolies and crony capitalism.
there are still financially devastating car accidents, and there are ever more cars on the road today making it even more important that the number of taxi's be regulated
Operators of ride sharing cars already pay registration, gasoline taxes, tolls, and insurance; they already have the ride to drive around the city all day long anyway, like any other motorist. Furthermore, there is no evidence that they impose extra costs or create extra traffic.
Furthermore, the taxi industry is miffed because the government set up a standard set of rules for everyone. If I buy a house...
A taxi license is not property, it is a temporary license to operate, granted ostensibly for the benefit of the public. The government is under no obligation to preserve the value of that license or to compensate anyone for it should policy changes make it less valuable. (Note that you generally don't get compensated even for zoning changes or environmental regulations that decrease the value of your home either.)
How can people run a business if the market they have been guaranteed in law suddenly gets eroded because the government decides not to care about upholding the laws that they were holding everyone to in the first place.
Taxi licenses are licenses to pick up people who hail rides from the curb, nothing more and nothing less. The purpose of taxi licenses was to ensure that when people hail something, it is actually a taxi. That mechanism then got hijacked by taxi operators and turned into a restrictive monopoly that screwed over customers.
Ride-sharing services broker rides between riders and drivers in real time, and hence don't need a taxi license; in fact, the rationale for taxi licenses (namely to establish authenticity of unknown vehicles) is meaningless for ride sharing, since drivers, riders, and rides are tracked closely by the ride sharing company. The taxi business model (picking up people on the street anonymous) has been made obsolete by new technology.
Furthermore, nothing is stopping any taxi driver from switching over to providing ride sharing services, so it's not like they are out of business.
Fair enough, but don't punish the taxi industry for it.
The taxi industry is the special interest that wants government handouts. They are miffed that their monopoly is disappearing and that their medallions are becoming worthless.
And they aren't being punished, they are being replaced by newer, better services. Government licensing and supervision kind of made sense when people hailed taxis on the street and needed a place to complain. But with the advent of smartphones, ridesharing services provide far better supervision of drivers, tracking of rides, and evaluation by customers. When a ridesharing driver takes a passenger for a ride, the ridesharing company knows instantly; when a ridesharing driver is rude to a passenger, that is reflected instantly in their evaluation. Traditional taxi licensing does none of that and isn't necessary to provide it.
I didn't really voice an opinion on the merits of C++ either way. You had said that "of late, Google has turn[ed] away from several current cherished paradigms", implying that there is some kind of repudiation of dynamic languages going on. I just pointed out that Google never was much into dynamic languages in the first place, and that just because C++ is a good choice for Google's core applications doesn't mean it's a good choice for most programmers. As a C++ programmer myself, I think it's great that Google supports C++ programming. But C++ programming is a very specialized skill, and most people are better off using something different.
"not designed for large messages...": Hmmm - isn't there a way to attach a file - i.e., a MIME "part"? Since PB uses HTTP2, it would be hard for me to imagine that they left that out. But if you are right, I agree it would be a terrible problem. Perhaps attaching files is part of gRPC but not PB?
Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish.
Not sure I understand your comment about non-copy memory transfers, since PB/gRPC are remote (out-of-process) communication tools.
High-performance networking tries to avoid memory copies as much as possible. That is, once received, the data should never have to get copied unless you need to process it in some way.
Yes, you are right, that message passing (e.g., UDP) is more scalable when one has a single server.
Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity.
But if you can massively scale the servers, the limitations of RPC-like communication go away.
A "procedure call" generally means something that is synchronous, strict, sequential, and runs in the same address space. Distributed programming in general has none of those properties. RPC systems first try to emulate those properties as much as possible, and then provide various workaround for the fact that the real world doesn't work like that, ending up with complex frameworks that don't behave much like procedure calls in the general case. That works well for tightly coupled distributed applications written in procedural languages, like Google's original search engine and similar applications. It doesn't work well for large, highly heterogeneous systems that need to work over the Internet or in many other contexts. (Incidentally, I might add that gRPC doesn't even have a load balancer yet; I suspect writing one isn't easy given gRPC's design.)
RPC libraries have their uses. But my point is: they are no replacement for REST, and they really inhabit a small niche in the space of distributed systems.
That's what I have been struggling with. The laws are the laws. It doesn't matter which ones we favor
We live in a democracy. Of course it matters which laws we favor because we vote based on that. Furthermore, in the English system, laws can also be nullified by lack of enforcement, widespread disobedience, and/or juries, or invalidated by courts.
How do you or Uber get to pick which laws are important? You're placing your own needs ahead of the millions of people that made those laws. After that, nothing matters.
The anti-ridesharing laws weren't "made by millions of people", they were made by a small number of lobbyists and politicians to advance their own interests. Afterwards, they try to bamboozle voters like you into believing that this was all for your benefit. In fact, if you want to talk about what the people want, polls pretty clearly suggest that the majority of people do not want the kinds of onerous restrictions on ride sharing services you advocate.
gRPC uses (by default) Protocol Buffers, which is reportedly ten times more efficient/responsive in terms of bandwidth and latency.
Protocol buffers have a couple of serious problems. First, they are not designed for large messages (>1Mbyte); so forget about using them for things like audio, video, image, or document upload... like most of what people actually do with REST. That limitation goes to the core of their APIs, which don't support incremental decoding or non-copy memory transfers very well. Protocol buffer data types also don't map well onto programming languages. And they aren't self-describing. There are several other binary protocols that address these issues. gRPC also becomes extremely cumbersome when dealing with asynchronous operations, failures, and load balancing; that's because Internet-scale distributed systems don't work like procedure calls.
Once can use gRPC with a REST-like paradigm
You could, but why would you want to? Adding gRPC to REST doesn't fix any of the problems with REST, while adding all the limitations and problems that gRPC has on top of those of REST.
a component-oriented approach has become popular today (we are back to a popularity contest) - driven largely by the frameworks that embed a "react" pattern
React patterns are based on message passing, not remote procedure calls. You can emulate message passing with procedure calls (and that's what you do when you use gRPC in such a context), but that's really just a workaround for the lack of a good message passing library, and you pay for it with all those issues that I mentioned above.
gRPC is good for what it is: an old-fashioned protocol for building large, monolithic, long-term, distributed systems within big companies full of Java and C++ programmers. To replace REST on the Internet, as well as for supporting microservices, however, we need something different.
They do. But that doesn't mean that you do. What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints.
As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."
I suggest you read the entire interview, because Alan Kay was, in fact, criticizing people with just your views. About C++, he also said "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind".
Well, Uber / Lyft are taxi companies, unless they're going to stop carrying passengers for profit. An app isn't enough to prevent them from qualifying as a taxi company
Taxis are something you can hail anonymously from the road side; Uber/Lyft are not taxi companies, and they aren't regulated as such, not even in places like Austin.
I'm not sure how preventing someone from building a flawed house and selling it to some unsuspecting person leads to the rich getting richer.
You're confusing the stated intent of regulations with the actual effect.
Obviously there shouldn't be crony capitalist laws but that's for the people to work out through the system of government.
Well, and that's what we are doing here: people like you support crony capitalist laws because you don't understand what's going on, and people like me oppose them.
As I said before, apparently you don't favor laws at all and that is not a society I would like to live in.
There are plenty of laws I favor, just not the crony capitalist kind that people like you favor.
So everyone should be able to move along and not follow the law in whatever way works for them?
Not at all. Uber/Lyft weren't taxi companies by the legal definition, so they didn't have to follow taxi-related laws. Lawmakers, in response to lobbying by taxi companies, created new laws restricting ride sharing services. What they should have done is abolished the regulations and privileges of taxi companies.
Restaurants can have vermin crawling around in their kitchen. Houses can be built in a way that will stand for 5 years and then fall over on the occupants despite outwardly looking like a luxury home...
Laws and regulations are neither necessary nor sufficient for preventing that. And, yes, like taxi companies, overregulation of restaurants and homes are other examples of why "the rich are getting richer" and "the middle class is stagnating".
You're basically inviting everyone to break the law in the way that suits them.
No, what I am advocating is abolishing crony capitalist laws that allow groups with lobbying power to enrich themselves at other people's expense. You apparently favor such laws.
How much longer do you think those other three players will be sitting at the table with their chance of coming out ahead being basically zero?
Hopefully not very long. Hopefully, they'll figure out quickly that they, too, should convert to a ridesharing model because customers prefer it and that their medallions and government-sponsored monopolies are worthless, the same way buggy whip manufacturers figured out that buggy whips were worthless and started making car accessories when cars took off. That is the whole point.
Of late, Google has turn away from several current cherished paradigms, including REST and dynamic languages, returning to older concepts that have stood the test of time.
Google hasn't "turned away" from anything, Google never embraced REST or dynamic languages much in the first place. Google has always been a stodgy C++/Java shop, and they can get away with using such unproductive tools because they have gobs of money and tens of thousands of programmers. I'm not sure where you work, so it may come as a surprise, but 99.99% of software development doesn't work that way. That's why Python, PHP, and REST are so popular.
Also, Google's internal systems are Internet-scale - they are the ones providing that scale!
The "Internet scale" we are talking about here isn't one big honking corporate serving lots of people; Google is good at that, and RPC can be an OK paradigm to build that on. The "Internet scale" we are talking about here is millions of different clients and servers, and thousands of different platforms they run on; constantly changing interfaces; developers who don't have Stanford graduate degrees in computer science; small shops that just want to get an app working and sell/deploy a few thousand copies.
You're sacrificing all these things for nothing but a cheap ride.
Allowing Uber/Lyft to operate freely doesn't "sacrifice" anything since it doesn't prevent anybody else from offering services, including traditional taxis.
You're making the typical argument of crony capitalists, namely justifying government-granted monopolies that result in a small benefit to some vulnerable group, a large financial benefit to cronies, and a small distributed cost to a politically powerless group (taxi riders in this case).
If it is government policy that unprofitable areas of the city or the physically disabled should receive subsidized rides, then those rides should be paid for by all taxpayers and accounted for in the budget; shifting the burden of paying for those services onto taxi passengers has no justification whatsoever.
Ignoring the billions it takes to add lanes to highways, road wear, accidents/insurance, pollution... Don't forget about the TIME people lose and the economic damage caused by having massive gridlock.
Sorry to break it to you, but public transit has never been shown to be effective in helping with any of those issues.
Ah so it all comes down to cost for you. Or as so many have put it, "as long as I get what I want, screw the rest".
You got it backwards. By advocating higher prices for services and by supporting cartels, your attitude is "as long as I get what I want, screw the rest". After all, as you just explained, you don't actually take taxis much, and your transportation needs are mostly met by a (subsidized) public transportation system, so for you, the cost of taxi-like transportation is just an abstract exercise in signaling your progressive attitudes.
My view is that I'd like goods and services to be as cheaply and widely available as possible because that actually helps people, in particular, people who don't have a lot of money. Uber/Lyft is a great choice, for example, for my elderly parents, who can't drive anymore; taxis are not just expensive, they take forever to show up and keep trying to defraud my parents, with government doing shit to intervene. But hey, you don't give a fuck because you don't actually take taxis.
Obviously not. I'm sure you also prefer sipping lattes at your local artisanal, organic coffee shop and bakery while foaming at the mouth about Walmart, Mr. Moneybags.
Sure, I understand that it doesn't actually fail, it is user error, but if you have to (literally) put bells and whistles in place to warn drivers they have selected the wrong position,
The user error here is not turning off the engine, not engaging the hand brake, and not curbing/turning the wheel. There are no UI problems with any of those steps.
In the end, when you've "dumbed-down" (not necessarily in a bad sense) driving with an auto transmission
People operating cars with automatic transmissions are still responsible for the operation of a heavy, lethal hunk of metal and need to learn to use it properly. That includes parking it properly, a procedure that is largely unrelated to the transmission.
When you leave the car, use the parking brake (and curb your wheels when on an incline). It's actually the law in some states. Anybody who doesn't do that and relies on the "P" setting of their automatic transmission isn't just a risk to themselves but also a risk to others. That's not just because relying on "P" alone creates a single point of failure for a multi-ton lethal projectile, but also because the "P" setting simply isn't designed to guarantee immobilization of a car. While it's sad that Yelchin died this way, this should not be the car manufacturer's responsibility: the car was parked improperly.
Most vehicle manufacturers and auto mechanics do not recommend using the transmission's parking pawl as the sole means of securing a parked vehicle, instead recommending it should only be engaged after first applying the vehicle's parking brake. Constant use of only the parking pawl, especially when parking on a steep incline, means that driveline components, and transmission internals, are kept constantly under stress, and can cause wear and eventual failure of the parking pawl or transmission linkage. The pawl might also fail or break if the vehicle is pushed with sufficient force, if the parking brake is not firmly engaged. Replacement can be an expensive operation since it not only requires removing the transmission from the vehicle, it's usually the first component to be installed in the gearbox case during a complete overhaul rebuild.
gRPC and REST don't even solve the same problem. Google is using RPC extensively, but mainly in the context of their own internal distributed systems, with an army of testers and developers, massive integration testing, and a single codebase. REST is for highly heterogeneous systems, languages, developer skills, a huge range of latencies, and numerous failure and security models. RPC can be a useful tool for the kinds of distributed systems Google is building to support their services; it is not a good tool for the kind of applications that REST is being used for, and there is tons more of the latter than the former.
As for CORBA, going through firewalls was the least of its problems; it was just badly designed. That's why Google, IBM, Microsoft, and Sun all developed their own systems. So, if you want RPC, by all means, use gRPC. But chances are that any form of RPC is probably not the right solution to your problem to begin with and you should be using something different.
Slashdot Mirror
I think your premises are flawed. Google uses a mix of C++, Python, Java, JavaScript, and Go, and all of those languages support both static and dynamic type checking. And Google clearly isn't happy with C++, otherwise they wouldn't have hired someone to develop Go. Furthermore, Go has substantially weaker static type checking than C++, so it doesn't look like Google is as adamant about static typing as you seem to be.
Static analysis is nice, but you can only analyze information that is actually available at compile time, and a lot of information is not; that's why languages like C++ have added features like RTTI and dynamic casting. Furthermore, static type analysis can become enormously complex and be more hassle than it's worth, which is why Java uses type erasure and Go doesn't even provide generics at all. On the other hand, many dynamically typed languages are completely type safe and allow you to add type annotations that catch type errors early and easily; and with JIT compilation, they can even generate better code than static analysis. In practice, the differences between statically and dynamically typed languages are pretty fluid and ill-defined, and the choices are often not as clearcut as you seem to think.
Be my guest. I'm just telling you don't hold your breath for gRPC to take off.
No, I'm sorry, but you still don't understand. Asynchronous message passing is a programming language abstraction, not a network abstraction; it's what Alan Kay originally envisioned for Smalltalk methods.
The asynchronous approach is much, much more complex to implement on top of an RPC system. That's my point: RPC systems are a bad abstraction because they make asynchronous programming unnecessarily difficult.
If taxicab businesses pay better and provide better services, then both drivers and passengers can continue to use them.
How can people who have a free choice of jobs and services be "exploited"? Exploitation can only happen when people take away choices, and that is what you are defending.
Look, aren't you listening? Ride sharing companies were not covered by taxi laws; laws governing the ride sharing industry are new laws and I am pointing out that they are bad for consumers. And, you're absolutely right, I have no problem with people flaunting bad laws; as I was pointing out before: the US has a British legal system, not a Napoleonic one, so widespread civil disobedience is a legitimate and common way of changing the law.
There are only two major players because few companies are big enough to put up with the legal and political bullshit the people you favor are imposing on the industry.
Anything is "debatable", but the side of the debate you are taking is the side of corruption and crony capitalism, because you are using "the disabled" as an excuse to hand monopolies to wealthy businesses.
Yours is the typical, arrogant attitude of well-off people: "hey, I have enough money so that paying a little more doesn't bother me, so why should it bother anybody else?" And you don't even understand what's going on: taxi medallions are often held by well off investors who then rent out their fleet of taxis to drivers; those drivers are already at the bottom of the totem pole. For them to be able to drive for themselves as ride share drivers is often a step up.
Yes, and as I explained before: trying to provide those services through taxi regulation simply forces other taxi riders to pay for them through increased fares. But providing service to less profitable areas and disabled people is something that society as a whole is responsible for, so it should be paid out of taxes, not through some non-transparent cost shifting involving government-granted monopolies and crony capitalism.
Operators of ride sharing cars already pay registration, gasoline taxes, tolls, and insurance; they already have the ride to drive around the city all day long anyway, like any other motorist. Furthermore, there is no evidence that they impose extra costs or create extra traffic.
A taxi license is not property, it is a temporary license to operate, granted ostensibly for the benefit of the public. The government is under no obligation to preserve the value of that license or to compensate anyone for it should policy changes make it less valuable. (Note that you generally don't get compensated even for zoning changes or environmental regulations that decrease the value of your home either.)
Taxi licenses are licenses to pick up people who hail rides from the curb, nothing more and nothing less. The purpose of taxi licenses was to ensure that when people hail something, it is actually a taxi. That mechanism then got hijacked by taxi operators and turned into a restrictive monopoly that screwed over customers.
Ride-sharing services broker rides between riders and drivers in real time, and hence don't need a taxi license; in fact, the rationale for taxi licenses (namely to establish authenticity of unknown vehicles) is meaningless for ride sharing, since drivers, riders, and rides are tracked closely by the ride sharing company. The taxi business model (picking up people on the street anonymous) has been made obsolete by new technology.
Furthermore, nothing is stopping any taxi driver from switching over to providing ride sharing services, so it's not like they are out of business.
How about running a full Ubuntu system, while still supporting all Chrome and Android apps?
The taxi industry is the special interest that wants government handouts. They are miffed that their monopoly is disappearing and that their medallions are becoming worthless.
And they aren't being punished, they are being replaced by newer, better services. Government licensing and supervision kind of made sense when people hailed taxis on the street and needed a place to complain. But with the advent of smartphones, ridesharing services provide far better supervision of drivers, tracking of rides, and evaluation by customers. When a ridesharing driver takes a passenger for a ride, the ridesharing company knows instantly; when a ridesharing driver is rude to a passenger, that is reflected instantly in their evaluation. Traditional taxi licensing does none of that and isn't necessary to provide it.
I didn't really voice an opinion on the merits of C++ either way. You had said that "of late, Google has turn[ed] away from several current cherished paradigms", implying that there is some kind of repudiation of dynamic languages going on. I just pointed out that Google never was much into dynamic languages in the first place, and that just because C++ is a good choice for Google's core applications doesn't mean it's a good choice for most programmers. As a C++ programmer myself, I think it's great that Google supports C++ programming. But C++ programming is a very specialized skill, and most people are better off using something different.
Not that I know of. And what would be the point? That would amount to a REST call with metadata attached in PB format, which is kind of like a bicycle for fish.
High-performance networking tries to avoid memory copies as much as possible. That is, once received, the data should never have to get copied unless you need to process it in some way.
Asynchronous message passing refers to a style of programming similar to (but different from) OOP. It really has nothing to do with UDP other than a superficial similarity.
A "procedure call" generally means something that is synchronous, strict, sequential, and runs in the same address space. Distributed programming in general has none of those properties. RPC systems first try to emulate those properties as much as possible, and then provide various workaround for the fact that the real world doesn't work like that, ending up with complex frameworks that don't behave much like procedure calls in the general case. That works well for tightly coupled distributed applications written in procedural languages, like Google's original search engine and similar applications. It doesn't work well for large, highly heterogeneous systems that need to work over the Internet or in many other contexts. (Incidentally, I might add that gRPC doesn't even have a load balancer yet; I suspect writing one isn't easy given gRPC's design.)
RPC libraries have their uses. But my point is: they are no replacement for REST, and they really inhabit a small niche in the space of distributed systems.
We live in a democracy. Of course it matters which laws we favor because we vote based on that. Furthermore, in the English system, laws can also be nullified by lack of enforcement, widespread disobedience, and/or juries, or invalidated by courts.
The anti-ridesharing laws weren't "made by millions of people", they were made by a small number of lobbyists and politicians to advance their own interests. Afterwards, they try to bamboozle voters like you into believing that this was all for your benefit. In fact, if you want to talk about what the people want, polls pretty clearly suggest that the majority of people do not want the kinds of onerous restrictions on ride sharing services you advocate.
Protocol buffers have a couple of serious problems. First, they are not designed for large messages (>1Mbyte); so forget about using them for things like audio, video, image, or document upload... like most of what people actually do with REST. That limitation goes to the core of their APIs, which don't support incremental decoding or non-copy memory transfers very well. Protocol buffer data types also don't map well onto programming languages. And they aren't self-describing. There are several other binary protocols that address these issues. gRPC also becomes extremely cumbersome when dealing with asynchronous operations, failures, and load balancing; that's because Internet-scale distributed systems don't work like procedure calls.
You could, but why would you want to? Adding gRPC to REST doesn't fix any of the problems with REST, while adding all the limitations and problems that gRPC has on top of those of REST.
React patterns are based on message passing, not remote procedure calls. You can emulate message passing with procedure calls (and that's what you do when you use gRPC in such a context), but that's really just a workaround for the lack of a good message passing library, and you pay for it with all those issues that I mentioned above.
gRPC is good for what it is: an old-fashioned protocol for building large, monolithic, long-term, distributed systems within big companies full of Java and C++ programmers. To replace REST on the Internet, as well as for supporting microservices, however, we need something different.
They do. But that doesn't mean that you do. What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints.
I suggest you read the entire interview, because Alan Kay was, in fact, criticizing people with just your views. About C++, he also said "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind".
Taxis are something you can hail anonymously from the road side; Uber/Lyft are not taxi companies, and they aren't regulated as such, not even in places like Austin.
You're confusing the stated intent of regulations with the actual effect.
Well, and that's what we are doing here: people like you support crony capitalist laws because you don't understand what's going on, and people like me oppose them.
There are plenty of laws I favor, just not the crony capitalist kind that people like you favor.
Not at all. Uber/Lyft weren't taxi companies by the legal definition, so they didn't have to follow taxi-related laws. Lawmakers, in response to lobbying by taxi companies, created new laws restricting ride sharing services. What they should have done is abolished the regulations and privileges of taxi companies.
Laws and regulations are neither necessary nor sufficient for preventing that. And, yes, like taxi companies, overregulation of restaurants and homes are other examples of why "the rich are getting richer" and "the middle class is stagnating".
No, what I am advocating is abolishing crony capitalist laws that allow groups with lobbying power to enrich themselves at other people's expense. You apparently favor such laws.
Hopefully not very long. Hopefully, they'll figure out quickly that they, too, should convert to a ridesharing model because customers prefer it and that their medallions and government-sponsored monopolies are worthless, the same way buggy whip manufacturers figured out that buggy whips were worthless and started making car accessories when cars took off. That is the whole point.
No, not really, at least not in the US. In addition to turning off the engine, you must engage the parking brake.
No, because garage floors (at least in the US) are level. You turn/curb the wheel when the ground is sloped.
As a devotee of public transit, I suppose you can be forgiven your ignorance.
Even you aren't as stupid as that
Google hasn't "turned away" from anything, Google never embraced REST or dynamic languages much in the first place. Google has always been a stodgy C++/Java shop, and they can get away with using such unproductive tools because they have gobs of money and tens of thousands of programmers. I'm not sure where you work, so it may come as a surprise, but 99.99% of software development doesn't work that way. That's why Python, PHP, and REST are so popular.
The "Internet scale" we are talking about here isn't one big honking corporate serving lots of people; Google is good at that, and RPC can be an OK paradigm to build that on. The "Internet scale" we are talking about here is millions of different clients and servers, and thousands of different platforms they run on; constantly changing interfaces; developers who don't have Stanford graduate degrees in computer science; small shops that just want to get an app working and sell/deploy a few thousand copies.
Allowing Uber/Lyft to operate freely doesn't "sacrifice" anything since it doesn't prevent anybody else from offering services, including traditional taxis.
You're making the typical argument of crony capitalists, namely justifying government-granted monopolies that result in a small benefit to some vulnerable group, a large financial benefit to cronies, and a small distributed cost to a politically powerless group (taxi riders in this case).
If it is government policy that unprofitable areas of the city or the physically disabled should receive subsidized rides, then those rides should be paid for by all taxpayers and accounted for in the budget; shifting the burden of paying for those services onto taxi passengers has no justification whatsoever.
Sorry to break it to you, but public transit has never been shown to be effective in helping with any of those issues.
You got it backwards. By advocating higher prices for services and by supporting cartels, your attitude is "as long as I get what I want, screw the rest". After all, as you just explained, you don't actually take taxis much, and your transportation needs are mostly met by a (subsidized) public transportation system, so for you, the cost of taxi-like transportation is just an abstract exercise in signaling your progressive attitudes.
My view is that I'd like goods and services to be as cheaply and widely available as possible because that actually helps people, in particular, people who don't have a lot of money. Uber/Lyft is a great choice, for example, for my elderly parents, who can't drive anymore; taxis are not just expensive, they take forever to show up and keep trying to defraud my parents, with government doing shit to intervene. But hey, you don't give a fuck because you don't actually take taxis.
Obviously not. I'm sure you also prefer sipping lattes at your local artisanal, organic coffee shop and bakery while foaming at the mouth about Walmart, Mr. Moneybags.
The user error here is not turning off the engine, not engaging the hand brake, and not curbing/turning the wheel. There are no UI problems with any of those steps.
People operating cars with automatic transmissions are still responsible for the operation of a heavy, lethal hunk of metal and need to learn to use it properly. That includes parking it properly, a procedure that is largely unrelated to the transmission.
When you leave the car, use the parking brake (and curb your wheels when on an incline). It's actually the law in some states. Anybody who doesn't do that and relies on the "P" setting of their automatic transmission isn't just a risk to themselves but also a risk to others. That's not just because relying on "P" alone creates a single point of failure for a multi-ton lethal projectile, but also because the "P" setting simply isn't designed to guarantee immobilization of a car. While it's sad that Yelchin died this way, this should not be the car manufacturer's responsibility: the car was parked improperly.
https://en.wikipedia.org/wiki/...
http://www.driversedguru.com/d...
You're evidently talking about yourself there.
gRPC and REST don't even solve the same problem. Google is using RPC extensively, but mainly in the context of their own internal distributed systems, with an army of testers and developers, massive integration testing, and a single codebase. REST is for highly heterogeneous systems, languages, developer skills, a huge range of latencies, and numerous failure and security models. RPC can be a useful tool for the kinds of distributed systems Google is building to support their services; it is not a good tool for the kind of applications that REST is being used for, and there is tons more of the latter than the former.
As for CORBA, going through firewalls was the least of its problems; it was just badly designed. That's why Google, IBM, Microsoft, and Sun all developed their own systems. So, if you want RPC, by all means, use gRPC. But chances are that any form of RPC is probably not the right solution to your problem to begin with and you should be using something different.
Google Trends pretty much tells the story: http://tinyurl.com/ho8gs7f