7 ms·

I guess everything old is new again. Welcome JS devs to RPC.

belfalas 4y ago
There's not much new under the sun. Virtual machines were created in the 1960s, for example. The wisdom I was given by an old hand is that the computer industry goes through a cycle of focus: disk, network, CPU - at any given time the currently 'hot' technology is targeting one of these hot spots. I am not sure I have lived long enough to see this play out for myself but it seemed that there was some truth to it when I first heard it.
- ipdashc 4y ago
  > the computer industry goes through a cycle of focus: disk, network, CPU - at any given time the currently 'hot' technology is targeting one of these hot spots Which would you say we're in now?
  - haimez 4y ago
    Network, and to a lesser extent: CPU (or more generally, compute) in large scale deployments as a result of possibilities enabled by networking. We’re calling this the cloud, but the first iteration of “the cloud” started with storage enabling efficient, reliable access of data storage being decoupled from individual nodes. Now we take that for granted- so maybe the current era is “all of the above, but storage started to feel like a solved problem”
    - tharkun__ 4y ago
      We’re calling this the cloud, but the first iteration of “the cloud” started with storage enabling efficient, reliable access of data storage being decoupled from individual nodes This is exactly what I dislike about all this "look, shiny, new" kind of thing. No, networked storage that is decoupled from compute nodes is not a cloud thing. Sure the cloud does that too. But data centers all over the globe used EMC^2 Symmetrix for a long time: https://en.wikipedia.org/wiki/EMC_Symmetrix https://en.wikipedia.org/wiki/EMC_Symmetrix
      - indymike 4y ago
        The novel part is selling it.
  - djbusby 4y ago
    I think CPU is currently in GPU cycle, learning to use all those cores for cool stuff not just fog and magic hashes.
  - doctor_eval 4y ago
    SSR makes me think we’re going back to doing everything on the server, after quite a few years focusing on the client. I think this might be the third go-around in my career.
    - indymike 4y ago
      I suspect we're on the way back to the client, about the time we get cheap 128GB RAM SOCs.
- tharkun__ 4y ago
  You're absolutely correct. Had this moment w/ my dad, when I started playing around with early VMware and excitedly told him about it and he was like "Well, yeah we use that all the time at work. It's called VM/370" (current: https://en.wikipedia.org/wiki/Z/VM https://en.wikipedia.org/wiki/Z/VM but see list of historical versions) What I just really dislike is all the fanfare and marketing blah. It seems that we can't have a proper conversation about such things. Performance and bottlenecks are always the same. Something is your current bottleneck. You focus on getting rid of that bottleneck and you discover the next bottleneck. There is always one. People will always take advantage of the bottleneck removed and hit the next one. Can't we just openly talk about the fact that we've removed one and the new bottleneck is of a different 'type' (like you say, disk, network, CPU). Do we always have to pretend like something truly new has been found? Can't we acknowledge what we're really doing there? Different thing, same vein: The recent posts on here about finite automata (aka state machines). These are the bread and butter of computer science. You learn about those in every computer science 101. And in 101.2 you learn about pushdown automata because finite automata can't do everything you might need (i.e. they can't count). Yet the discussion here and the linked articles and frameworks linked to sound like they're completely novel.
  - ctxc 4y ago
    Can you share links to resources you recommend about these topics? I'll Google it, but still :)
    - tharkun__ 4y ago
      You mean FSMs? I don't really have any links about those, no. I learned about them in university. That's been a while and all of that info was in paper form. But I'm sure there are great online resources nowadays. Just in general I do see in my history this which came through HN a while ago. I never read any of that but it seems a lot like what we did in computer science in uni from a cursory glance: http://infolab.stanford.edu/~ullman/focs.html http://infolab.stanford.edu/~ullman/focs.html
  - majkinetor 4y ago
    It might not be the same. You see, context and surrounding technolgy changes rapidlly and so ideas that were not feasible 50 years ago (or had some other type of problem) might be feasible today. History can't repeat because underlying technology always moves forward and that change is so important that it invalidates almost anything to be clasified as total repete.
- jjav 4y ago
  > There's not much new under the sun. I wish every CS curriculum had a mandatory course on the history of CS. Covering how many times the same ideas have been "new" and then discarded as not useful, only to be rediscovered. It could help reduce the amount of churn in the industry, so we can move forward instead of forgetting and relearning the same things over and over.
  - madmax108 4y ago
    Mandatory link to Bret Victor's "The Future of Programming" talk which discusses some of the same ideas: https://www.youtube.com/watch?v=8pTEmbeENF4 https://www.youtube.com/watch?v=8pTEmbeENF4
    - jiriro 4y ago
      What’s the year of this presentation? There’s 1973 on the slide. Is this possible? It looks like a joke but I’m not sure.
      - belfalas 4y ago
        It's after the year 2000 - definitely a joke on Bret's part. He is very big on keeping computer history alive and contextualizing things. You're meant to pretend Bret is giving the presentation in 1973; e.g. his comment about "but there's no way Intel will corner the market and stifle innovation, right?"
le-mark 4y ago
Wait until they (re)discover remote objects and remote method invocation and java.rmi.*, and jndi because you have to find things!
- kabes 4y ago
  Lets hope they don't find out about these java atrocities
  - djbusby 4y ago
    DCOM
    - viraptor 4y ago
      It's not Halloween yet! Don't bring up the living dead...
      - mananaysiempre 4y ago
        Why did DCOM fail? Yes, sure, the protocol documentation is extremely obscure and the tooling kind of sucks, but conceptually? I assume that there’s a reason aside from Microsoft choosing to jump on the web services bandwagon, but I can’t actually find anyone come out and say it. The closest I’ve seen is complaints about scalability, but they don’t agree what’s at fault, either—some point to pinging, some to heavyweight COM+ activation... I don’t get it. Given the relative success of seemingly-isomorphic Java tech, there has to be something.
  - zaik 4y ago
    They don't have to find out to reinvent it.
- aaaaaaaaaaab 4y ago
  What should I call my JavaScript CORBA library to get the most stars on GitHub? Corba.js? Corby? What's the current trend?
kabes 4y ago
There tons of js libraries for this already since forever. Meteor is a well known one.
- denysonique 4y ago
  Meteor is a very opinionated framework. This project allows one to seamlessly add RPC to an existing frontend+backend codebase. Plus the out of the box TypeScript support for the remote procedures. I haven't seen anything similar before this.
  - kabes 4y ago
    Sure, but my point is this is not a new concept in JS, which is what the parent implied
Waterluvian 4y ago
JS has had this forever. I’ve been doing RPC over websocket for maybe a decade. It’s really good for a very narrow scope of things. But I keep re-learning what you’re getting at, throughout my career: just keep it simple. Most things can just be simple.
- doctor_eval 4y ago
  > Most things can just be simple. That’s really well put. When I saw this I just thought, well, that’s probably a lot of complexity to save a few lines of code. And then you’ll just add those lines of code back later when you realise that the client stubs are the easy bit.
  - brillout 4y ago
    Yes, depending on your stack, I can only recommend to roll-your-own. But for some stack it ain't that easy though. E.g. if you want TypeScript or SSR.
vbezhenar 4y ago
Issue with RPC was that network calls were masked like they were ordinary calls. But they're not ordinary calls, they might take a long time to respond, they might fail because of network issues, you could send request and then fail to receive response. Those kinds of situations are not common with ordinary calls, so it creates some kind of impedance mismatch. For example it's not possible to call JS function, it'll work and they it'll fail to return a result for some reason. Worst thing that could happen is stack overflow but it won't let you call this function. I think that RPC is fine as long as it's clearly separated and those who read and write code do not mask it behind ordinary innocent looking calls. It's OK to call personApi.getFullName(person.fistName, person.lastName). It's not OK to call person.getFullName().
- Too 4y ago
  Async functions, now available in many languages, solves many of the issues RPC had in its childhood. With the problem that you get "colored" functions. Thinking about it that's probably a good thing, because with RPC you had colored functions, except you didn't know about it, some innocent functions would just randomly take forever to return.
  - mpweiher 4y ago
    No, they don't actually solve any of the problems. They just provide syntactic sugar papering over them and, what's worse, exactly make you believe that the problems have been solved.
    - olalonde 4y ago
      At least with "await person.getFullName()", it's more obvious that a network call is being made.
      - P5fRxh5kUvp2th 4y ago
        that's an abuse and an excuse. 1. It's an abuse of what async/await is. async/await is about concurrency and says NOTHING about the cause of that concurrency. 2. It's an excuse to rationalize what is clearly a bad idea. RPC should obviously be RPC. What seems obvious to you in that function call isn't going to be obvious in 5-10 years once your sensibilities are gone and it's someone else dealing with the crap you wrote.
pragmatic 4y ago
It amazes me the breathless enthusiasm that junior devs show for this stuff. We fought so hard to get rid of crazy RPC protocols (COM+, CORBA) and abominations like SOAP and people keep trying to bring them back. Yes networking is hard. Do everything you can to make it easier to debug. Text protocols, easy to use tools, etc They have no idea how thankful they should be HTML friendly ("REST") APIs. Don't wake the RPC eldritch horrors. Let them dream their undead dreams in the stygian depths.
- indymike 4y ago
  > We fought so hard to get rid of crazy RPC protocols (COM+, CORBA) and abominations like SOAP and people keep trying to bring them back. For those that dare re-kindle the old ways of RPC, only despair, anguish and insanity await. The mindless boilerplate, the infinite depths of parser recursion, the envelopes within envelopes, the madness inducing mysteries of undeclared encoding, the deadly omission of byte order markers, the incomprehensibly complex, yet vague error messages... and the network. The network is waiting to devour your function calls, returning only the broken skeleton and ruptured entrails of what were once perfectly beautiful, good, honest and peace loving return values. The old ways must be locked away, and cast into the deepest fissure in the deepest depths of the ocean, where there is no chance they be rediscovered and unwittingly released on humanity. Or, how I feel when a vendor sends documentation for their SOAP web service.
  - Terretta 4y ago
    > how I feel when a vendor sends documentation for their SOAP web service The only thing worse may be when a vendor sends documentation for their "REST" web service that is clearly just machine reformatted SOAP.
    - indymike 4y ago
      Possibly, but there is one more basement in this particular hell: slapping a GraphQL wrapper on it.
- 0x445442 4y ago

There's not much new under the sun. Virtual machines were created in the 1960s, for example. The wisdom I was given by an old hand is that the computer industry goes through a cycle of focus: disk, network, CPU - at any given time the currently 'hot' technology is targeting one of these hot spots. I am not sure I have lived long enough to see this play out for myself but it seemed that there was some truth to it when I first heard it.

ipdashc 4y ago
> the computer industry goes through a cycle of focus: disk, network, CPU - at any given time the currently 'hot' technology is targeting one of these hot spots Which would you say we're in now?
- haimez 4y ago
  Network, and to a lesser extent: CPU (or more generally, compute) in large scale deployments as a result of possibilities enabled by networking. We’re calling this the cloud, but the first iteration of “the cloud” started with storage enabling efficient, reliable access of data storage being decoupled from individual nodes. Now we take that for granted- so maybe the current era is “all of the above, but storage started to feel like a solved problem”
  - tharkun__ 4y ago
    We’re calling this the cloud, but the first iteration of “the cloud” started with storage enabling efficient, reliable access of data storage being decoupled from individual nodes This is exactly what I dislike about all this "look, shiny, new" kind of thing. No, networked storage that is decoupled from compute nodes is not a cloud thing. Sure the cloud does that too. But data centers all over the globe used EMC^2 Symmetrix for a long time: https://en.wikipedia.org/wiki/EMC_Symmetrix https://en.wikipedia.org/wiki/EMC_Symmetrix
    - indymike 4y ago
      The novel part is selling it.
- djbusby 4y ago
  I think CPU is currently in GPU cycle, learning to use all those cores for cool stuff not just fog and magic hashes.
- doctor_eval 4y ago
  SSR makes me think we’re going back to doing everything on the server, after quite a few years focusing on the client. I think this might be the third go-around in my career.
  - indymike 4y ago
    I suspect we're on the way back to the client, about the time we get cheap 128GB RAM SOCs.
tharkun__ 4y ago
You're absolutely correct. Had this moment w/ my dad, when I started playing around with early VMware and excitedly told him about it and he was like "Well, yeah we use that all the time at work. It's called VM/370" (current: https://en.wikipedia.org/wiki/Z/VM https://en.wikipedia.org/wiki/Z/VM but see list of historical versions) What I just really dislike is all the fanfare and marketing blah. It seems that we can't have a proper conversation about such things. Performance and bottlenecks are always the same. Something is your current bottleneck. You focus on getting rid of that bottleneck and you discover the next bottleneck. There is always one. People will always take advantage of the bottleneck removed and hit the next one. Can't we just openly talk about the fact that we've removed one and the new bottleneck is of a different 'type' (like you say, disk, network, CPU). Do we always have to pretend like something truly new has been found? Can't we acknowledge what we're really doing there? Different thing, same vein: The recent posts on here about finite automata (aka state machines). These are the bread and butter of computer science. You learn about those in every computer science 101. And in 101.2 you learn about pushdown automata because finite automata can't do everything you might need (i.e. they can't count). Yet the discussion here and the linked articles and frameworks linked to sound like they're completely novel.
- ctxc 4y ago
  Can you share links to resources you recommend about these topics? I'll Google it, but still :)
  - tharkun__ 4y ago
    You mean FSMs? I don't really have any links about those, no. I learned about them in university. That's been a while and all of that info was in paper form. But I'm sure there are great online resources nowadays. Just in general I do see in my history this which came through HN a while ago. I never read any of that but it seems a lot like what we did in computer science in uni from a cursory glance: http://infolab.stanford.edu/~ullman/focs.html http://infolab.stanford.edu/~ullman/focs.html
- majkinetor 4y ago
  It might not be the same. You see, context and surrounding technolgy changes rapidlly and so ideas that were not feasible 50 years ago (or had some other type of problem) might be feasible today. History can't repeat because underlying technology always moves forward and that change is so important that it invalidates almost anything to be clasified as total repete.
jjav 4y ago
> There's not much new under the sun. I wish every CS curriculum had a mandatory course on the history of CS. Covering how many times the same ideas have been "new" and then discarded as not useful, only to be rediscovered. It could help reduce the amount of churn in the industry, so we can move forward instead of forgetting and relearning the same things over and over.
- madmax108 4y ago
  Mandatory link to Bret Victor's "The Future of Programming" talk which discusses some of the same ideas: https://www.youtube.com/watch?v=8pTEmbeENF4 https://www.youtube.com/watch?v=8pTEmbeENF4
  - jiriro 4y ago
    What’s the year of this presentation? There’s 1973 on the slide. Is this possible? It looks like a joke but I’m not sure.
    - belfalas 4y ago
      It's after the year 2000 - definitely a joke on Bret's part. He is very big on keeping computer history alive and contextualizing things. You're meant to pretend Bret is giving the presentation in 1973; e.g. his comment about "but there's no way Intel will corner the market and stifle innovation, right?"

le-mark 4y ago

Wait until they (re)discover remote objects and remote method invocation and java.rmi.*, and jndi because you have to find things!

kabes 4y ago
Lets hope they don't find out about these java atrocities
- djbusby 4y ago
  DCOM
  - viraptor 4y ago
    It's not Halloween yet! Don't bring up the living dead...
    - mananaysiempre 4y ago
      Why did DCOM fail? Yes, sure, the protocol documentation is extremely obscure and the tooling kind of sucks, but conceptually? I assume that there’s a reason aside from Microsoft choosing to jump on the web services bandwagon, but I can’t actually find anyone come out and say it. The closest I’ve seen is complaints about scalability, but they don’t agree what’s at fault, either—some point to pinging, some to heavyweight COM+ activation... I don’t get it. Given the relative success of seemingly-isomorphic Java tech, there has to be something.
- zaik 4y ago
  They don't have to find out to reinvent it.
aaaaaaaaaaab 4y ago
What should I call my JavaScript CORBA library to get the most stars on GitHub? Corba.js? Corby? What's the current trend?

kabes 4y ago

There tons of js libraries for this already since forever. Meteor is a well known one.

denysonique 4y ago
Meteor is a very opinionated framework. This project allows one to seamlessly add RPC to an existing frontend+backend codebase. Plus the out of the box TypeScript support for the remote procedures. I haven't seen anything similar before this.
- kabes 4y ago
  Sure, but my point is this is not a new concept in JS, which is what the parent implied

Waterluvian 4y ago

JS has had this forever. I’ve been doing RPC over websocket for maybe a decade. It’s really good for a very narrow scope of things. But I keep re-learning what you’re getting at, throughout my career: just keep it simple. Most things can just be simple.

doctor_eval 4y ago
> Most things can just be simple. That’s really well put. When I saw this I just thought, well, that’s probably a lot of complexity to save a few lines of code. And then you’ll just add those lines of code back later when you realise that the client stubs are the easy bit.
- brillout 4y ago
  Yes, depending on your stack, I can only recommend to roll-your-own. But for some stack it ain't that easy though. E.g. if you want TypeScript or SSR.

vbezhenar 4y ago

Issue with RPC was that network calls were masked like they were ordinary calls. But they're not ordinary calls, they might take a long time to respond, they might fail because of network issues, you could send request and then fail to receive response. Those kinds of situations are not common with ordinary calls, so it creates some kind of impedance mismatch. For example it's not possible to call JS function, it'll work and they it'll fail to return a result for some reason. Worst thing that could happen is stack overflow but it won't let you call this function. I think that RPC is fine as long as it's clearly separated and those who read and write code do not mask it behind ordinary innocent looking calls. It's OK to call personApi.getFullName(person.fistName, person.lastName). It's not OK to call person.getFullName().

Too 4y ago
Async functions, now available in many languages, solves many of the issues RPC had in its childhood. With the problem that you get "colored" functions. Thinking about it that's probably a good thing, because with RPC you had colored functions, except you didn't know about it, some innocent functions would just randomly take forever to return.
- mpweiher 4y ago
  No, they don't actually solve any of the problems. They just provide syntactic sugar papering over them and, what's worse, exactly make you believe that the problems have been solved.
  - olalonde 4y ago
    At least with "await person.getFullName()", it's more obvious that a network call is being made.
    - P5fRxh5kUvp2th 4y ago
      that's an abuse and an excuse. 1. It's an abuse of what async/await is. async/await is about concurrency and says NOTHING about the cause of that concurrency. 2. It's an excuse to rationalize what is clearly a bad idea. RPC should obviously be RPC. What seems obvious to you in that function call isn't going to be obvious in 5-10 years once your sensibilities are gone and it's someone else dealing with the crap you wrote.

pragmatic 4y ago

It amazes me the breathless enthusiasm that junior devs show for this stuff. We fought so hard to get rid of crazy RPC protocols (COM+, CORBA) and abominations like SOAP and people keep trying to bring them back. Yes networking is hard. Do everything you can to make it easier to debug. Text protocols, easy to use tools, etc They have no idea how thankful they should be HTML friendly ("REST") APIs. Don't wake the RPC eldritch horrors. Let them dream their undead dreams in the stygian depths.

indymike 4y ago
> We fought so hard to get rid of crazy RPC protocols (COM+, CORBA) and abominations like SOAP and people keep trying to bring them back. For those that dare re-kindle the old ways of RPC, only despair, anguish and insanity await. The mindless boilerplate, the infinite depths of parser recursion, the envelopes within envelopes, the madness inducing mysteries of undeclared encoding, the deadly omission of byte order markers, the incomprehensibly complex, yet vague error messages... and the network. The network is waiting to devour your function calls, returning only the broken skeleton and ruptured entrails of what were once perfectly beautiful, good, honest and peace loving return values. The old ways must be locked away, and cast into the deepest fissure in the deepest depths of the ocean, where there is no chance they be rediscovered and unwittingly released on humanity. Or, how I feel when a vendor sends documentation for their SOAP web service.
- Terretta 4y ago
  > how I feel when a vendor sends documentation for their SOAP web service The only thing worse may be when a vendor sends documentation for their "REST" web service that is clearly just machine reformatted SOAP.
  - indymike 4y ago
    Possibly, but there is one more basement in this particular hell: slapping a GraphQL wrapper on it.
0x445442 4y ago