Fork me on GitHub
#off-topic
<
2016-12-25
>
nur02:12:53

why isn't there marketing channel here? I thought you guys want more adoption?

nur02:12:10

or just let Clojure be a secret weapon ๐Ÿ˜›

fellshard02:12:02

It all starts with a Hickey talk. ๐Ÿ˜‰

tbaldridge03:12:23

@nur Elixir is rather limited by the Erlang VM. So a lot of stuff Clojure can do is pretty impossible in Elixr

tbaldridge03:12:07

Stuff like atoms, agents, refs, vars, transients, transducers, etc.

johanatan03:12:39

@nur the binary protocol pattern matching from Erlang is probably one thing that Clojure doesn't do as easily

johanatan03:12:45

@nur and generally bit fiddling of that sort. also, Erlang has lower level networking support than the JVM

tbaldridge03:12:35

@johanatan really? You can do some really low level stuff on the JVM.

tbaldridge03:12:26

My friend got zero copy user mode networking working on the JVM, that's pretty low level

johanatan03:12:05

@tbaldridge yea, i suppose so. I just know that people say networking is more efficient in Erlang: I think it bypasses the OS networking stack entirely (implemented in the language/runtime)

johanatan03:12:14

i.e., WhatsApp gets a ridiculous number of concurrent connections on a single box

johanatan03:12:35

I think it might have something to do with memory usage too: processes & sockets are lighter weight

johanatan03:12:52

and JVM isn't known for being kind to memory ๐Ÿ™‚

fellshard03:12:47

That's the idea, I think. Designed for distributed / many lightweight prcesses

tbaldridge04:12:08

@johonatan look at that use case though, large numbers of very low bandwidth connections. Same for the original use-case of Erlang, control over hardware telecom switches

fellshard04:12:27

Was just gonna say, yeah. Context is key.

fellshard04:12:51

A lot of the stuff that makes actor systems appealing apply to Erlang as well

fellshard04:12:58

self-healing w/ supervision etc.

tbaldridge04:12:11

But people have to go and apply that to other things like HTTP servers, databases, backend services, etc. In all those cases Erlang really seems like the a really bad choice.

tbaldridge04:12:45

I'm not even convinced that a properly written JVM app couldn't have done what WhatsApp did. Perhaps it wouldn't fall out-of-the-box as it did with Erlang, but it's not impossible.

fellshard04:12:07

Harder to govern that kind of thing on the JVM

tbaldridge04:12:19

But even the self-healing stuff isn't really needed 99% of the time. I've built systems with quite high up-times and all it took was a solid distributed queue, a lot of boxes, and some hammock time.

fellshard04:12:48

One way to solve a problem that isn't as relevant anymore

fellshard04:12:22

We're not trying to pack parallel / independent processes onto a single VM now

fellshard04:12:43

Those are system-level properties, not application-level now

tbaldridge04:12:29

As I heard a well known programmer once say: "Most people that choose Erlang, the first thing they do is go out and write a distributed queue...why not just start with that?"

tbaldridge04:12:58

Also, I've been burned by Erlang tech a few too many times. My experience with Riak was...really bad (to put it nicely). Compared to my experience with stuff like Cassandra. And this was on different projects spread over a few years. Maybe that's just the way Riak was written...maybe it's Erlang. I don't know, either way it left a really bad taste in my mouth. And that was backed up by my personal experiences with Erlang.

tbaldridge04:12:28

So yeah, I'll look to Erlang next time I need to build a telecom switch, with "nine nines" of uptime. Otherwise I'll stick with something faster and less restrictive.

fellshard18:12:34

Merry Christmas, Clojurians ๐Ÿ™‚

agigao20:12:52

Merry Christmas! :)

aisamu22:12:36

Merry christmas (and hi!)