undefined | Better HN

0 pointsjerf4y ago0 comments

"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?

0 comments

hnedeotes4y 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