4 ms·

Also the docs got a facelift: http://erlang.org/doc/ http://erlang.org/doc/ Now that we are talking Erlang: What's missing in Erlang that would be valuable to

Also the docs got a facelift: http://erlang.org/doc/ http://erlang.org/doc/ Now that we are talking Erlang: What's missing in Erlang that would be valuable to you? What are the biggest pain points right now on the Erlang ecosystem that makes it harder for you to try it/adopt it?

marianoguerra 9y ago
didn't noticed that the submitted link is to the docs :P
StreamBright 9y ago
For me the biggest pain point was the lack of great libraries for doing basic stuff like HTTP requests (client side). I was not able to reach the performance of Java/JVM with the Erlang implementation and I could not figure out what I am doing wrong. OTP and those pattern associated with it are still a bit opaque after reading countless manuals, howtos and books.
deleted 9y ago
[deleted]
derefr 9y ago
> Also the docs got a facelift You can finally zoom into them on mobile without the sidebar covering half the text :D
- pmontra 9y ago
  They forgot to fix it for Firefox. I guess they're using only Chrome.
digitalzombie 9y ago
> What are the biggest pain points right now on the Erlang ecosystem that makes it harder for you to try it/adopt it? Personally, Erlang solve stuff that is very niche and I don't have any project in those stuff. Elixir web frameworks really help in term of practicing the language. Erlang had cowboy, etc.. but it wasn't close to the other MVC language. So practicing Erlang to get real experiences in it was hard. Maybe there should be a page of examples of other problem Erlang can solve so I can decide which problem I like to start a project on? Cause so far when I think of Erlang it's just concurrency, back end protocol, etc... But I'm sure there may be other problems it can be address that I don't know about and that I would like to start a trivial project on it.
- klibertp 9y ago
  > Erlang solve stuff that is very niche Well, it's true that Erlang supports some strange, esoteric (at least, esoteric for people outside of telecom) protocols. But it supports all the "normal" stuff also, as you write: > Erlang had cowboy, etc.. but it wasn't close to the other MVC language. Cowboy is actually pretty decent a framework for web development. It's not Rails or Django equivalent, it's similar to something like stripped-down CherryPy, which may be regarded as minimalistic, but it's perfectly functional. And fast. And WebSocket handling is pure bliss. So, Cowboy doesn't support MVC out of the box, but you can implement this pattern on top of Cowboy in ~30 loc. > So practicing Erlang to get real experiences in it was hard. Erlang is different. From its Prolog roots to its concurrency primitives to immutability and tail-call elimination - it's built to be different. It's not exactly surprising that you can't use it as freely as you'd like immediately after learning it. It's expected. The only thing I can tell you now is that the problem disappears with time. You need to practice Erlang fundamentals for a bit and slowly advance to more complex topics. In my case, it took me a year to become proficient with Erlang: the main language was a bit of a hassle, but its std library and OTP and ecosystem in general took even more effort to grok. OTOH, after a year of learning and practicing, I was able to write a proof-of-concept web apps in a day, including learning Cowboy. The "proof-of-concept" was fast and solid enough that it reached production stage and ran there for 3 years until finally replaced by some other tool. So I'd say it's worth the effort, but of course YMMV :)
dqv 9y ago
I wish there was better discovery in Erlang sources. I'd really love to see something like Mozilla DXR for Erlang code. That way I can see what's going on in more mature Erlang sources. Grep and GitHub leave much to be desired searching through Erlang code. It would also be nice to have a way to infer--without actually running the app--the supervision tree from the source and then graph it.
- macintux 9y ago
  > It would also be nice to have a way to infer--without actually running the app--the supervision tree from the source and then graph it. That'd be effectively impossible for the general case, since it's trivial to supervise/launch processes whose primary module isn't known at compile time. I definitely agree that understanding the supervision structure is both valuable and non-trivial.

marianoguerra 9y ago

didn't noticed that the submitted link is to the docs :P

StreamBright 9y ago

For me the biggest pain point was the lack of great libraries for doing basic stuff like HTTP requests (client side). I was not able to reach the performance of Java/JVM with the Erlang implementation and I could not figure out what I am doing wrong. OTP and those pattern associated with it are still a bit opaque after reading countless manuals, howtos and books.

deleted 9y ago

[deleted]

derefr 9y ago

> Also the docs got a facelift You can finally zoom into them on mobile without the sidebar covering half the text :D

pmontra 9y ago
They forgot to fix it for Firefox. I guess they're using only Chrome.

digitalzombie 9y ago

> What are the biggest pain points right now on the Erlang ecosystem that makes it harder for you to try it/adopt it? Personally, Erlang solve stuff that is very niche and I don't have any project in those stuff. Elixir web frameworks really help in term of practicing the language. Erlang had cowboy, etc.. but it wasn't close to the other MVC language. So practicing Erlang to get real experiences in it was hard. Maybe there should be a page of examples of other problem Erlang can solve so I can decide which problem I like to start a project on? Cause so far when I think of Erlang it's just concurrency, back end protocol, etc... But I'm sure there may be other problems it can be address that I don't know about and that I would like to start a trivial project on it.

klibertp 9y ago
> Erlang solve stuff that is very niche Well, it's true that Erlang supports some strange, esoteric (at least, esoteric for people outside of telecom) protocols. But it supports all the "normal" stuff also, as you write: > Erlang had cowboy, etc.. but it wasn't close to the other MVC language. Cowboy is actually pretty decent a framework for web development. It's not Rails or Django equivalent, it's similar to something like stripped-down CherryPy, which may be regarded as minimalistic, but it's perfectly functional. And fast. And WebSocket handling is pure bliss. So, Cowboy doesn't support MVC out of the box, but you can implement this pattern on top of Cowboy in ~30 loc. > So practicing Erlang to get real experiences in it was hard. Erlang is different. From its Prolog roots to its concurrency primitives to immutability and tail-call elimination - it's built to be different. It's not exactly surprising that you can't use it as freely as you'd like immediately after learning it. It's expected. The only thing I can tell you now is that the problem disappears with time. You need to practice Erlang fundamentals for a bit and slowly advance to more complex topics. In my case, it took me a year to become proficient with Erlang: the main language was a bit of a hassle, but its std library and OTP and ecosystem in general took even more effort to grok. OTOH, after a year of learning and practicing, I was able to write a proof-of-concept web apps in a day, including learning Cowboy. The "proof-of-concept" was fast and solid enough that it reached production stage and ran there for 3 years until finally replaced by some other tool. So I'd say it's worth the effort, but of course YMMV :)

dqv 9y ago

I wish there was better discovery in Erlang sources. I'd really love to see something like Mozilla DXR for Erlang code. That way I can see what's going on in more mature Erlang sources. Grep and GitHub leave much to be desired searching through Erlang code. It would also be nice to have a way to infer--without actually running the app--the supervision tree from the source and then graph it.

macintux 9y ago
> It would also be nice to have a way to infer--without actually running the app--the supervision tree from the source and then graph it. That'd be effectively impossible for the general case, since it's trivial to supervise/launch processes whose primary module isn't known at compile time. I definitely agree that understanding the supervision structure is both valuable and non-trivial.