We didn't forget it. We burned it with fire, and then buried it. Most of us still of nightmares of it. Some didn't survive. :(
Care to share one of the nightmare
Erlang: The coding language that finance forgot (2022)
11–20 of 155 posts
Re: Erlang: The coding language that finance forgot (2022)
#12I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
I don’t quite understand this.
Doesn’t the BEAM runtime also have operational benefits over “lambdas”?
Also not every application or component thereof wants stateless servers? What about live collaboration, game servers or just generally holding stuff in memory for perf reasons.
Re: Erlang: The coding language that finance forgot (2022)
#13Who exactly claims Erlang is dead? The referenced article is SEO-infected garbage that also claims Haskell and Perl are dead.
It's only a word but the very fact the article refers to Erlang as a "coding language" and not a "programming language" is enough to give it a cheap, amateurish feel from the start IMHO. I'd just ignore it as low quality click bait if I were you.
That sounded odd to me too, but not being a native speaker, I was asking myself "is that how they call a programming language nowadays if they want to sound cool?". Guess not...
Re: Erlang: The coding language that finance forgot (2022)
#14I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
You are vastly overestimating the importance of AWS Lambda, even in web tech circles.
Re: Erlang: The coding language that finance forgot (2022)
#15I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
This has it backwards - lambda is only suitable for the cloud equivalent of shell scripts, anything more complex and it becomes an unmaintainable rats nest that cannot be debugged.
Re: Erlang: The coding language that finance forgot (2022)
#16I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
Stop it Jeff...
Re: Erlang: The coding language that finance forgot (2022)
#17I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
...what?
The 99.999% of tech that does not, in fact, run (or would want to run) on friggin' AWS lambdas would like to have a quiet word with you.
Re: Erlang: The coding language that finance forgot (2022)
#18I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
Time to go outside and touch grass.
Re: Erlang: The coding language that finance forgot (2022)
#19Erlang is designed to accommodate principles for building reliable systems in the presence of software errors, and in such capacity it is definitely a worthy instrument. It is one of the few concurrency oriented programming languages in the world. But as Joe Armstrong himself pointed out in his dissertation: "indeed concurrent programs can be written in languages which are not themselves concurrent". You can write co…
> As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant.
Features such as the memory model and lightweight processes are intrinsic to the BEAM VM and aspects of the language (such as immutability). Erlang is a mixture of no memory management, fail-fast and embarrassingly parallel without GC pauses, and getting those characteristics in another language can’t be had without fundamental and breaking changes, to the point of becoming Erlang, which seems awfully redundant.
Re: Erlang: The coding language that finance forgot (2022)
#20I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.
I don’t quite understand this. Doesn’t the BEAM runtime also have operational benefits over “lambdas”? Also not every application or component thereof wants stateless servers? What about live collaboration, game servers or just generally holding stuff in memory for perf reasons.
Yeah, one could easily argue the opposite: The excellent scaling characteristics of the BEAM means that there’s no need to use extreme performance compromises like AWS Lambda. You can scale an Erlang or Elixir application extremely far by just giving it more compute resources.