undefined | Better HN

0 pointshnedeotes4y ago0 comments

I think that it would be helpful if you provided examples about those things, good and bad. As it is it's mostly "erlang's" bad - perhaps if you offer the counterparts to what would be a better pick we could have a discussion - and then perhaps see how far the tree of dependencies goes on each side? And also what you would loose by picking up those solutions?

Just taking on some random stuff:

> Trivial pattern matching is replaced by this, and to be honest, non-trivial pattern matching is probably a code smell if not an antipattern; if you're reaching three levels down into a data structure

If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?

> Modern Erlang performance is meh;

This I'm not sure. I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. Obviously there will be plenty of stuff that a low level language can do more efficiently and faster I don't think anyone disagrees with that - but I think sometimes people sell erlang and elixir's speed short.

> but the entire gen_server set up, with its initialization phase and its three proscribed ways to call it and the need for an explicit "gen_server" module type are largely the creation of Erlang in the first place

I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop. (and I read your other reply and thread). There's also a reason why some things have a particular way of being set up inside the beam, and that's mostly related to the guarantees it provides and with the fact that processes are transparent across nodes. If you take out the impossible to block scheduling and network transparency you'll be of course able to spin up something similar to a GenServer without the same "ritual" - but it no longer has anything to do with the former perhaps except its API?

> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one.

Given that you can have any socket, tcp or not, and easily handle it, this doesn't seem to be a fair point. On kafka or any other message bus the implementation language will be that of the sources and sinks communicating with kafka? Or you just write kafka and the other programs wake up as insects in a bed?

> Mnesia, a clustered DB was a neat idea, but in 2021 is so poorly featured and unreliable it doesn't even qualify as one anymore; nobody in their right mind would bring up an Erlang cluster just to back some other language's code to Mnesia as a database

I haven't used mnesia at scale and indeed heard people complaining about it, more than once so there's probably some issues there - having said that, in terms of similar db's (KV based and not SQL,etc) even db's like MongoDB and such need expensive and usually paid managing solutions right? And can still loose data unless you really cover your redundancy?

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better.

Could you tell us succinctly how? As a, usually, solo developer I would be really interested in knowing, and I'm not asking sarcastically.

I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top.

0 comments

jerf4y ago

"If the data structure is being accessed in a module to deal with it specifically then that is part of the knowledge of the module. And you can't escape that with or without pattern matching, since you'll have to codify those things in code anyway, be it long chains of ifs, switches, or whatever, you'll always have to write the code with the same level of knowledge about the data structure to express the same conditions?"

There are other options. In object oriented design, using the loose definition of "anything with 'methods'" (thus, including Go and Javascript even if they don't have "inheritance"), if you want to know something, you ask directly, using a method for that case. It is the difference between "account.getBill(lastMonth)", where you load the logic into the account object to fetch bills from different times, and pattern matching where you write into the code taking the bill deep assumptions about how the account is structured, such that when refactoring the account you have to go change all its consumers. Note I am only criticizing deep pattern matching here; pattern matching in general I like, even if I can live without, but in Erlang terms, if your patterns look like

    [thing, [_, _, {something, X, [Y, _, Z]}]]

you've gone off the rails.

"I've seen libs written in elixir beat libs written in C++ and they had to start a VM to be run. "

There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).

"I haven't seen any language with the concept of an independent program, that has a synchronous interface (mailbox), but can be modelled entirely asynchronously, and can't block whatever running loop."

Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.

"Given that you can have any socket, tcp or not, and easily handle it"

There is a lot more to being a message bus than just having a TCP socket.

"I also don't understand how it's difficult to integrate Erlang with other things, it basically has a standard lib very accommodating of sockets and inter process communication through STDIN/OUT, with effective monitoring on top."

That is not "easy to integrate with", that's table stakes. What I'm referring to being hard to integrate with is how you tend to be stuck in the ecosystem. It has monitoring, sure... but in 2021 it's a very quirky monitoring that doesn't integrate with any of the rest of what has developed. You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific, with its own quirky term format that isn't quite JSON or quite anything else, is so difficult as to not be worthwhile. Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?

hnedeotesOP4y ago

I still don't understand the point about the deep pattern matching. In OOP you'll have an object that encapsulates all that knowledge, and in functional programming you'll have a module that encapsulates all that knowledge, clients of both the object in OOP and clients of the data structure in FP will need to have the same knowledge to deal with it - once you need to serialise the information. I just don't find the argument compelling, in my reading it would be akin to saying, it's a code smell a class has all this implicit knowledge of the object it's modelling (assuming the deep pattern matching in the module dealing with transforming it).

> There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++).

Usually it's microbenchmarking that doesn't flatter elixir/erlang - and stampede problems where you can get away with just brute forcing - eg. parsing directly to output a bunch of files where the output is a file(s) - but there, if you want then to build usable metadata through all of it things change fast - writing a correct program in any of the fast languages that has the same ergos for keeping usable information throughout and is at the same time easily changeable, can interleave information in parallel with pretty amazing monitoring, and doesn't require years of training, is quite a different thing.

I know it doesn't use C++ because I wrote it and I know how much more it does as well, though I'm not here to convince you.

> Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that.

Well, sure, I just think it should not be written as "cover" the problem space, is more "making holes" in the problem space.

> There is a lot more to being a message bus than just having a TCP socket.

Given that your argument was:

> A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one

I'm not sure there's any more esperanto than tcp/sockets, which comparing to any other language are a joy to write, use, monitor, and deal with.

> You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific

This sincerely... How do you connect to other clusters in other languages (if they're even able to set up meshes)? You don't. How do you solve it? With clustering solutions. How is it that a runtime that can be put inside those same clustering solutions, by the same process, but has a zillion more functionality can be worse than those other solutions regarding that?

> Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again?

Yeah, because they all speak something else than http/tcp and we know erlang is not really made for handling sockets and can't do http.post().

j / k navigate · click thread line to collapse