Go vs. Erlang for distribution
groups.google.com
groups.google.com
Go was created to make buildng a single server (in the software not hardware sense) easier.
Erlang was created to create systems for managing a lot of servers with a complicated dependency hierarchy.
Go doesn't have OTP and a fault tolerant runtime because Google has all that stuff at a separate layer in their datacenters and the Go engineers didn't feel a need to solve that problem. They wanted to solve the problem of still having to build http servers in C++ for performance and all the attendant annoyances that brings.
If I were going to build a massive distributed system today I'd use the Erlang runtime to manage the overall system in a fault tolerant way and I'd use Go to build the components.
They complement themselves well but they don't really replace each other.
The thread was short on people with both experience in Go and with knowledge of the motivations for Go.
When I began learning Erlang, I immediately understood why people compared them: I found them quite similar to each other (much more simllar to each other than either to c++, python, ruby, perl, lisp, lua, etc) as well.
It should/will.
For me Erlang is first fault tolerant, then concurrent,
then functional, yet for many people it seems to be the
opposite order. I personally care very little about
Erlang being functional (though I do care a great deal
about immutability and pattern matching being the default
behavior, the rest not so much), and the concurrency is
nice but only because it enables all the fault tolerance
features of the language.
Go is no "ultimate antagonist to Erlang" as OP hypothesized.
Node.js vs Erlang: https://groups.google.com/forum/#!msg/erlang-programming/ufN...
I think the Erlang guys are not very good at marketing (in the broad sense) their system, which is a pity, because Erlang is very nice for some kinds of applications.
Think about some of the articles from people like patio11, and what kind of ideas they might apply were they trying to sell something like Erlang.
- Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it.
The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management.
There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution).
Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.
Until a little while ago the website http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page.
Erlang just needs better marketing.
The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace?
Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks.
For documentation: there's http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ that provides more modern design to the reference manuals.
Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
I was talking about the impressions that the official site gives to non expert.
> Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
Didn't notice that my suggestions were so vague, sorry. I'd say - avoid all the empty pages like http://www.erlang.org/doc/apps/mnesia/index.html or http://www.erlang.org/doc/apps/odbc/index.html - remove the folders icons and use something else, or at least update the icons - clearly separate functions, either having more empty space between each one of them or using subtle colors or lines or whatever - use different text styles for functions and arguments or some sort of syntax highliting
That said I'm not a designer, I'd ask one for help.
Lowering those barriers to entry is important. Erlang will never be the easiest/quickest thing out there, but if it's a bit easier to get into it, it will, at the margin - meaning people who are undecided or on the fence - bring people in.
Package management is a big one.
Easy to get started examples is important too.
I think a more curious attitude would help some people too... thinking about why Erlang doesn't "sell well" rather than immediately placing the blame on others for not being "good enough" or whatever. The community is good, but there is some of "it's not a wart, it's a feature!" - perhaps more than elsewhere. I saw this in the Tcl world too, and it can be unproductive.
On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.
1. Erlang the functional language with a syntax inspired by prolog.
2. OTP and the Erlang Runtime.
The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM.
It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it.
The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises.
These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.
If most people find the syntax any of {awkward, intimidating, unreadable, inscrutable, undesirable} then they won't use it unless they have to.
This means programming languages are path-dependent. Perhaps in a different world, lisp-type syntax is how people think about programming. Or maybe in a different world Haskell syntax is the norm. But we live in this world, and in this world, such syntax is pretty much all of the above. This makes it harder for people to read and understand programs written in those languages. Since that's ultimately the central point of a programming language -- to make programs readable to human beings -- syntax is the primary thing on which languages are evaluated.
Obviously there are other factors like available libraries, tools, platform support, and so forth, but syntax is an extremely important pillar.
The syntax defines the form of a valid program, but gives no information about what it means. Semantics define what the execution of that program would be.
For example, 'X = X+1' can be valid by the syntax of two languages, except one of them (say Erlang), will fail to do the pattern matching defined under operator '=', whereas the other will do an assignment where 'X' is now worth its former value plus one.
There is a lot more meaning and deeper implications to defining what 'x = x+1' means than defining how to write it. Another example can be '1 + 3 * 5': this is an addition and a multiplication, but what's the operator precedence? In smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely different meaning.
You can think of it this way: Erlang the language can have a mostly-equivalent semantic set of operations in LFE, which is a lisp. It could have had semantic equivalence with Elixir's syntax, but it didn't (because Elixir made different decisions with re-binding and whatnot).
Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring about: pattern matching, recursion, shared-nothing, etc.
Syntax is important, but it's not nearly as important or challenging as semantics are.
As a sibling post mentioned, syntax is like a paint job. Yeah a pink tank is not appealing to everyone. . looks better than ;. Some like {}, some like begin/end blocks. That is syntax. If that is unsurmountable and is the central issue for that developer that is a sign they probably will not handle well a whole new paradigm (actors, distribution, distributed systems issues etc).
Another level is what does the language operate with. This is after the syntax has been parsed. What are the building blocks: functions, variables, records, processes, ETS tables, messages, OTP behaviors, macros. Those are things that define a language more than Syntax. These can be familiar or unfamiliar. Like I see a class in C++, Java and Python. The syntax to define one is different but in my head I can conceptualize it in a similar way. Erlang is functional and concurrent. So those two things will make it unusual. It also operates with immutable, single assignment data. That is unusual. I can see someone having a gripe with that.
As a mental experiment, if we switch all the . to ; and introduce {} brackets. Rename records to structs maybe or give them a C/Go like definition syntax. There won't be a revolution and Google, Facebooks other companies and universities will all of the sudden flock to it. They won't because they still have to use a new paragidm to develop -- processes and concurrency and single assignment variables.
Yet another axis on which to judge syntax is consistent vs inconsistent. Erlang's syntax is unfamiliar but it is small and consistent. Same goes for the meanings of operations. Like say in Javascript if you watch the Wat talk, you'll how you add an object to some array for example and get a NaN. The syntax is familiar but the meaning and how it works is inconsistent. The same can be said about libraries as well.
That's an unfair criticism of the defenses of Erlang vs. people complaining that the syntax doesn't look like C. I think Erlang's syntax is wonderful on it's own terms. Criticism of it because it doesn't look like C just seems like it's from lazy people who have a very narrow view of how programming should look.
That's entirely separate from criticism by people like Tony Arcieri or Damien Katz, who criticize the syntax itself, rather than in comparison to some idea of what they think all languages should look like.
Syntax is important because of two distinct reasons. First is technical: how complex the syntax is impacts how fast, how many and how good tools (for refactoring, autocomplete, docs generation, macros and so on) will be created for the language.
Second reason is sociological in nature, and also is further divided into two reasons, one reasonable and the other stupid.
The first is that it's natural for people to use simpler things first. If the syntax involved in spawning a new thread is much more complex than the syntax for making and passing a callback you're going to end with most language users using event-driven, reactor based programming, even if launching a new thread would be more efficient (up to some threshold of difference in performance, above which people will feel it's worth it to use more complex feature). In short, syntax matters in that it statistically dictates how the language is used, which impacts what "best practices" and "idioms" are created.
The second reason is idiotic and unprofessional. Imagine a carpenter who refuses to use a hammer because it has a pink handle, even if it's the only or the best hammer in some circumstances. Emotions felt towards tools - and specifically syntaxes - are what amateurs can get away with, but it's also one of the things which defines them as amateurs. The syntax is "awkward"? "intimidating"? ("unreadable" is a whole another can of worms) That's either funny or pathetic, depending on circumstances.
If you are a professional programmer, you should be already at least comfortable with 5+ styles of syntax, including C-like, Pascal-like, Lisp-like and Prolog-like. This makes it impossible for any syntax to ever "intimidate" you.
in some languages it's just a b c (Haskell)
Downvoted to oblivion.
a b c
1 2 3
g a b
what is that? sudoku? complete the phrase? too little syntax.. it doesnt say what it does..
besides f(x) is is math for centuries ;)
(1)(2)(3) since they are literals it's probably an argument list to a function, but not valid by itself
g(a)(b) etc.
remember, in Haskell pretty much everything is a function
I just hope I don't dislocate a thigh.
Eh. Let it crash.
I mean, I totally understand, and to a large extent approve of, their conservatism, but "this ecosystem is boring in a good way" is a hard sell to a generation brought up on 15 minute blog videos.
IO List and Binaries (look at Elixir, also Cowboy and pretty much every optimized piece of Erlang code) solved this problem quite some time ago. Yeah, more syntactic sugar would be nice, but then - unlike many other languages - you can just write a parse transform and be done with it.
Also "just write a parse transform" is not really encouraged very much because it'll make your code hard to read and maintain, something which is valued in Erlang land more than some super-tricky piece of really clever coding.
If anyone should be marketing Erlang, it's a company that relies on it and wants to lower labor costs, or even better a company that licenses an application that requires on-site Erlang expertise.
In my opinion, Erlang is already where it needs to be, and new things happen for it every month or two that completely blow my mind. Why should Erlang care that people want to use node.js for everything that Erlang does better?
I think you're getting at the idea that marketing a language stimulates demand for programmers or it stimulates the supply of programmers. If there's a fixed number of positions for Erlang programmers more proficient people to fill those positions will lower wages. However, if the marketing convinces people who have problems to solve, that Erlang and the work Erlang programmers can do is the solution then demand will increase.
However, whereas econ 101 helps identify some of the central concepts, later courses would explore the dynamics in greater detail. For example, languages derive value from their communities and the network effects. Or, someone who is called a Erlang programmer could program in many other languages, but may enjoy Erlang more, or believe they can be more productive if they're able to use Erlang.
Anyway, it makes me think of open source projects where there are difficult people. You can tell non-paying, non-customers they don't have to use the work you've publicly released for free when they find problems, but presumably you're deriving some utility from releasing the software, and your utility function probably isn't served by getting your work ignored.
Even if advocacy only encouraged new programmers rather than marketing the language to people who have problems to solve, I think that advocates for the language want its usage to grow. There are language communities where people talk about proficiency as some sort of secret gold mine, but I think those 'secret' high-paying jobs are probably involve a lot of uninteresting maintenance of legacy code.
What new things and how do they blow your mind?
http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of... (Or the Abstractitude of the Hewitt Actor Model.)
http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thes... (Or a summary of the original problems Erlang was trying to address.)