Earlier quoted context omitted.
The syntax is heavily inspired by Ruby.
What, the words def and do?
Jose himself has cited ruby for syntax inspiration multiple times, because he himself started in the ruby community
Ten Years of Erlang
91–100 of 155 posts
Re: Ten Years of Erlang
#92Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.) This problem…
The blog post is not actually about making FP accessible to the masses nor a how to guide about it, and if you read through the post, it’s even stated in there that it’s not important for the language to gain widespread use.
That’s why I downvoted you. It’s not because of your opinion, it’s because it’s probably not in the right thread.
Re: Ten Years of Erlang
#93Earlier quoted context omitted.
Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones. Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic. And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on…
> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy. And unless you r…
> LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.
If you built a traditional SPA, aren't you still making loads of calls to your server?
I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received.
Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs.
The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app.
Re: Ten Years of Erlang
#94Earlier quoted context omitted.
To say a few things that Fred isn't saying here (these are my opinions not his): - Early Erlang tools had a lot of issues when Elixir showed up but rebar3 made quick progress and is a very good set of tools integrated into one command-line interface - rebar3 has supported creating releases for a very long time which Elixir's mix tool is just catching up to (sure distillery supported things but so did relx and half a…
Very good summary! One quick correction: the equivalent to _checkouts in Mix is to use path dependencies. I often use environment variables to control when to use one or the other and I like the fine grained control more. Here is an example: https://github.com/elixir-ecto/ecto_sql/blob/master/mix.exs#... But in general yes, we are glad to borrow ideas from each other and we should continue doing it!
Thanks for this tip. I find myself a little more reluctant to rely on environment variables for this sort of thing but it'd be fair to say the same about filesystem state.
My only problem with this solution is that it changes the mix configuration itself (which is version controlled) which is fine if others are in need of similar overrides when working on the project. For one-off/local things, it can be a bit heavy for temporary overrides.
Still, it's a fair trade-off since it's a lot easier to code up logic like this with mix compared to rebar3.
Re: Ten Years of Erlang
#95Earlier quoted context omitted.
I work with Ruby and Elixir daily and Elixir is 10x faster. Phoenix recently added functionality to display response times in microseconds, partially as a showcase for its good performance. I dont doubt you can get more performance in C++ or something but its still lighting compared to Ruby.
Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.
> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.
What is your definition of slow or fast?
For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performance.
Also parsing templates with EEx is ridiculously fast, because it's not treated as a string.
Re: Ten Years of Erlang
#96Functional programming has too long of a learning curve to the average programmer. A language should be judged by how long it takes average programmers to become proficient in it, not the "Sheldon Cooper" types. In typical medium and large organizations, it's difficult keep being selective about programmer hiring. (There are org structural/political reasons that would take several paragraphs to explain.) This problem…
I'm hardly smart. The only thing I have going is I'm determined.
I have no CS degree, never went to university but have been doing freelance web dev work for ~20 years.
Been through a lot over the years but never took a shot with a functional language until I met Elixir recently.
It really didn't take that long to get to the point with Elixir where things somewhat started to click. I'm still very much a beginner and am learning multiple new things for every few hours I'm coding but I am able to make progress without feeling like I'm in way over my head. Of course I still have so much to learn about Elixir / Phoenix, Erlang and OTP but it'll come in due time. You don't need to take in all of the complexity at once.
I'm multiple thousands of lines of code into developing my first Elixir / Phoenix web app and there has been stumbling along the way but also great strides of progress.
Re: Ten Years of Erlang
#97I find the key point to language adoption is that self-selection that occurs. What type of person and their personality does an ecosystem attract and what is that type of person good at? The BEAM ecosystem is all about fault-tolerance, distribution, and concurrency. These BEAM concepts could be described as "upper ladder" ideas: they require more prerequisite understanding of systems engineering to appreciate. Despit…
> what could be changed in the ecosystem to support this goal? 1. Change the syntax. Elixir wasn't far enough. Not at all and BEAM doesn't need to know, so we have a chicken-egg problem of people entrenched don't want to spend time that will help the language and underlying strategies become more widely adopted. Perhaps this was the production feedback loop you were referencing. We still don't have a good methodology…
> Handling text is still awful in these languages.
In contrast to what? Honestly just curious.
Re: Ten Years of Erlang
#98Earlier quoted context omitted.
Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text.
> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text. What is your definition of slow or fast? For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performan…
spec-builder git:(master) ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }"
0.005459 0.000009 0.005468 ( 0.005464)
Re: Ten Years of Erlang
#99Earlier quoted context omitted.
Agreed. This is actually why I think the killer apps for the BEAM are 2 Elixir based ones. Nerves, which is already being heavily used for embedded systems and only getting stronger thanks to the likes of Scenic. And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on…
> Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks. LiveView still needs more work to be really ergonomic, wouldn't work for all use cases, but I'm personally holding my breath here in excitement to adopt it in my Elixir projects. Still, I find it…
I've been using LiveView for a small project. It's pretty bumpy right now, but man it's going to be a game-changer for me.
Re: Ten Years of Erlang
#100Earlier quoted context omitted.
> Phoenix is faster than Rails, however Ruby is faster than Elixir when doing CPU intensive tasks. Like parsing text. What is your definition of slow or fast? For example with Elixir it was possible to generate 5,000x random 19 character codes in 3ms on a 5 year old i5 3.2ghz desktop workstation. I don't know how long it would take with Ruby but for such a text / CPU intensive task, I'm quite happy with the performan…
spec-builder git:(master) ruby -e "require 'benchmark'; puts Benchmark.measure { 5_000.times { rand(36**19).to_s(36) } }" 0.005459 0.000009 0.005468 ( 0.005464) I am at 5ms on a MacBook. Can you share your iex code?
Here's a couple of versions of the code: https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80...
It would be interesting if you wanted to come up with a Ruby version that adheres to the random code spec which should be able to be determined from looking at the first 2 versions. It's basically only a subset of characters that can be used and the code should be output as XXXX-XXXX-XXXX-XXXX.
I personally use the 25ms version because I find it to be the best one if you factor in both speed and readability. I'm sure there's better ways but I'm only an Elixir beginner.
Also for the record I didn't write the 2nd or 3rd versions of that gist. I asked around in the community and that's what others have put together.