3 ms·

I want a language/runtime that abstracts this away from me. I'll implement and debug functions the regular way, with the runtime in charge of deploying them whi

I want a language/runtime that abstracts this away from me. I'll implement and debug functions the regular way, with the runtime in charge of deploying them whichever way fits. Bonus points for deducing infrastructure from statically analyzing code dependency paths. I believe there is very early stage work [0] in this direction, but obviously nothing going mainstream yet. Would love to find more examples in the wild if anyone knows any! [0]: https://egghead.io/blog/how-to-quickly-build-a-backend-with-dark-lang https://egghead.io/blog/how-to-quickly-build-a-backend-with-...

jiggawatts 3y ago
I love how you responded to a post advocating for simpler architectures by linking to an automagic abstraction over microservices, because microservices weren't difficult enough already. The example also mentions Stripe payments, but nowhere does it mention transactions or error recovery because they're stupidly difficult in microservices designs, so we'll just "skip right over that" and go straight to losing money any time there's a hiccup. "Sure it's incomplete and outright dangerous to our bottom line, but I can't wait to tinker with it!" is precisely the problem with the industry.
- omneity 3y ago
  I mean, I do agree with the parent, insofar as I don't want to deal with the mess of microservices/functions firsthand. Now if a runtime could reap the benefits of this architecture automatically, sort of like a compiler would optimize code for a particular cpu, then that would be a best-of-both-worlds situation.
  - michaelmrose 3y ago
    If you can't run anything remotely like the code you are actually running how will you ever figure out why it isn't doing what you expect?
- threeseed 3y ago
  The problem with your argument is that microservices and lambdas aren’t new. The industry has had plenty of opportunities to ditch them and go back to monolith services and yet it hasn’t happened. Is it because everyone is wrong except for you ? Or is it because they are better for certain types of use cases.
hu3 3y ago
Perhaps erlang/OTP might tackle some of these challenges of simpler scaling. https://www.erlang.org/doc/design_principles/des_princ https://www.erlang.org/doc/design_principles/des_princ WhatsApp famously scaled a lot with relatively few devs: > WhatsApp scaled to 1B users with only 50 engineers https://news.ycombinator.com/item?id=28985169 https://news.ycombinator.com/item?id=28985169
- GiorgioG 3y ago
  Most companies do not have WhatsApp scaling problems to solve. Having said that, I’d love to work on an Elixir project.
  - hu3 3y ago
    Most companies don't but I was replying to omneity's inquiry. And yeah, Elixir is great!
- omneity 3y ago
  Erlang is awesome! I never had a chance to use it in anger but I've been keeping a close eye on Erlang/Elixir for years. In fact we almost considered moving to it at my project for the sake of stability, but went with adopting some of the principles in our codebase instead (embrace failure basically, expect stuff to crash and recover properly).
tikhonj 3y ago
The Unison language does roughly what you're talking about: https://www.unison-lang.org/ https://www.unison-lang.org/ The language is built with this idea from the ground up, so it can move functions around between machines robustly and without running into problems with versioning. It's the only model I've seen for distributed computing that really makes it a first-class citizen of the language.

jiggawatts 3y ago

I love how you responded to a post advocating for simpler architectures by linking to an automagic abstraction over microservices, because microservices weren't difficult enough already. The example also mentions Stripe payments, but nowhere does it mention transactions or error recovery because they're stupidly difficult in microservices designs, so we'll just "skip right over that" and go straight to losing money any time there's a hiccup. "Sure it's incomplete and outright dangerous to our bottom line, but I can't wait to tinker with it!" is precisely the problem with the industry.

omneity 3y ago
I mean, I do agree with the parent, insofar as I don't want to deal with the mess of microservices/functions firsthand. Now if a runtime could reap the benefits of this architecture automatically, sort of like a compiler would optimize code for a particular cpu, then that would be a best-of-both-worlds situation.
- michaelmrose 3y ago
  If you can't run anything remotely like the code you are actually running how will you ever figure out why it isn't doing what you expect?
threeseed 3y ago
The problem with your argument is that microservices and lambdas aren’t new. The industry has had plenty of opportunities to ditch them and go back to monolith services and yet it hasn’t happened. Is it because everyone is wrong except for you ? Or is it because they are better for certain types of use cases.

hu3 3y ago

Perhaps erlang/OTP might tackle some of these challenges of simpler scaling. https://www.erlang.org/doc/design_principles/des_princ https://www.erlang.org/doc/design_principles/des_princ WhatsApp famously scaled a lot with relatively few devs: > WhatsApp scaled to 1B users with only 50 engineers https://news.ycombinator.com/item?id=28985169 https://news.ycombinator.com/item?id=28985169

GiorgioG 3y ago
Most companies do not have WhatsApp scaling problems to solve. Having said that, I’d love to work on an Elixir project.
- hu3 3y ago
  Most companies don't but I was replying to omneity's inquiry. And yeah, Elixir is great!
omneity 3y ago
Erlang is awesome! I never had a chance to use it in anger but I've been keeping a close eye on Erlang/Elixir for years. In fact we almost considered moving to it at my project for the sake of stability, but went with adopting some of the principles in our codebase instead (embrace failure basically, expect stuff to crash and recover properly).

tikhonj 3y ago

The Unison language does roughly what you're talking about: https://www.unison-lang.org/ https://www.unison-lang.org/ The language is built with this idea from the ground up, so it can move functions around between machines robustly and without running into problems with versioning. It's the only model I've seen for distributed computing that really makes it a first-class citizen of the language.