Erlang's secret sauce is OTP.
What's all this fuss about Erlang? (2007)
61–70 of 193 posts
Re: What's all this fuss about Erlang? (2007)
#62Earlier quoted context omitted.
I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…
As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things. Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).
Honestly, I think that if Ericsson was just starting to build Erlang today, it'd look less like a self-contained emulator, and more like a virtual-machine image. (Or more than one: maybe an Erlang unikernel image ala Erlang-on-Xen, and then companion POSIX VMs to spawn ports on, making the Erlang cluster into its own Kubernetes-alike.)
Re: What's all this fuss about Erlang? (2007)
#63Earlier quoted context omitted.
I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…
Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterpris…
Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data processing where a lighter language like Ruby will not do well. There's nothing in Erlang that conceptually prevents it from being a general-purpose language; it's just that its ergonomics don't really "scale down" to the stupid, simple stuff.
I remember, years ago, trying to write a basic parallel non-OTP log-processing pipeline for some log files, thinking Erlang would be ideal... and being surprised at the number of roadblocks I had to deal with. Around the same time, Tim Bray went through the same process, but spent a lot more effort on it than I [1].
[1] http://www.tbray.org/ongoing/When/200x/2007/09/22/Erlang
Re: What's all this fuss about Erlang? (2007)
#64Earlier quoted context omitted.
Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming. (Also, Erlang has a compile-time static type checker, if type safety is something you're…
Immutability is not a silver bullet. One reason is RAM consumption: while Facebook has bought tremendous amount or RAM for caching content so those extra copies of objects don’t hurt, desktop or embedded apps have different resource constraints. Another reason is performance. Memory allocation/deallocation is not free. RAM bandwidth for copying those objects isn’t free. Also mutable objects generally more cache-frien…
You can have immutability without data duplication; in an immutable-only environment, every process/thread/whatever that uses a specific object can safely reuse a pointer to that object and always know that the object represented by that pointer cannot change under their noses. It's only when you need to "modify" that object (read: create a new copy) where you start to see RAM consumption issues, and even that can be mitigated.
Linked lists are an example of where this works remarkably well; if you have a list (E→D→C→B→A) and want to append F to that list, you can do so trivially without needing to mutate or copy the original (since all you need for the new list is F and a pointer to E). Same if you wanted to replace E with F; just have F point to D instead.
Re: What's all this fuss about Erlang? (2007)
#65Earlier quoted context omitted.
so many people (including me from time to time) misunderstand "computaionally expensive" that I think Elixir/erlang/beam will serve a lot of systems/apps well for a long time until they really see a need for "intense" computation
Oh, absolutely - you can do tons of things with Erlang, just as people do with Ruby, Python, PHP, Tcl, etc... But that article is a bit hype-y.
Re: What's all this fuss about Erlang? (2007)
#66Earlier quoted context omitted.
As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things. Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).
I think it's a mind-expanding experience to set up an Erlang release on an "immutable infrastructure" system like CoreOS, with the Erlang "ssh" application enabled (instead of using ERTS's remsh system), and then keep that system up for weeks/months by doing maintenance through said SSH REPL. It becomes very clear, when you do so, that Erlang really is its own little sandboxed OS, and that the "Erlang Runtime System"…
EDIT: found the link http://erlang.org/pipermail/erlang-questions/2011-October/06...
Re: What's all this fuss about Erlang? (2007)
#67Earlier quoted context omitted.
Are you referring to Dialyzer? I've always wanted to learn Erlang but can't give up on types.
Yup, Dialyzer. Works with Elixir too (there's even a Dialyxir mix task) and gives me all the type checking I want -- which admittedly isn't much.
def some_function(SomeStruct{} = some_struct) do
some_struct.foo + some_struct.bar
end
Or better yet, if I only want certain fields: def some_function(SomeStruct{foo: foo, bar: bar}) do
foo + bar
end
This way, if the "type check" fails (that is, someone tries to use "some_function/1" on something that isn't a SomeStruct), there'll be a clear error to that effect.Between this and protocols, I very rarely feel the need to reach for something like Dialyzer. YMMV, of course.
Re: What's all this fuss about Erlang? (2007)
#68Earlier quoted context omitted.
Obviously said "program" must be a server that services independent requests. I mean, not obviously, but if you work in telecom, web, etc. that's pretty much all programs you see.
I get that, but as I say we already knew how to scale those linearly in most programming languages. Erlang brought nothing new there. It does have advances in things like reloading and supervision.
Re: What's all this fuss about Erlang? (2007)
#69Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists
Not really. Experience after designing and deploying systems that run 100,000 transactions/sec per box: don't bother with engineers that cannot achieve proficiency in Erlang. Elixir is a crutch, and not something you want to show up with in 400 meters hurdles race. You will look pathetic.
Erlang has its uses and Elixir has its uses. Dismissing Elixir's userbase as 'pathetic' is pretty rude and a disservice to a pretty incredible language. See the Discord article where they clearly demonstrate Elixir and Genstage are ready for production and can be used to write performant services.
I get that you really like Erlang and its quirks, but maybe there are more mature ways of expressing this love than calling Elixir users 'pathetic'.
Re: What's all this fuss about Erlang? (2007)
#70Earlier quoted context omitted.
Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterpris…
But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks. Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data proces…
(Though, even in that setup, there's no way to get an effect equivalent to requiring un-bundled gems from your script in Ruby.)