Live data from Hacker News

Ten Years of Erlang

ferd.ca

81–90 of 155 posts

Re: Ten Years of Erlang

#81
post #75

I 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 for measuring all sorts of things in software dev. 10 years, 20 years, the language may just never do more than incremental changes (like elixir).

2. Handling text is still awful in these languages.

Re: Ten Years of Erlang

#82
post #9

I love Erlang, and am one of the very few people who (in the past) managed to find work doing it full time. The actor paradigm it provides is surprisingly simple and elegant to write an app, even on a single node, and of course making distributed apps is fairly straightforward as a result of it. I have found that I like Lisp-Flavoured-Erlang (LFE) a bit more, since I still find the prolog-esque syntax a bit frustrati…

Not being facetious, but could the joy resemble the fun I associate with developing with Ruby?

if you want that kind of joy with erlang, try elixir. it's basically ruby on the erlang vm.

Re: Ten Years of Erlang

#83
post #16

Earlier quoted context omitted.

We probably had our discussions about this before, tooling definitions diverge at times, and I have a vested interest in some of them, but I will just state my disagreement on the better tooling side of things ;)

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!

Re: Ten Years of Erlang

#84

Earlier quoted context omitted.

Disagree with “cleaner”.

It'd be nice if dissenting opinions came with elaboration to continue the discussion instead of shut it down.

The dissenting opinion that it has "cleaner" syntax came with no elaboration.

Re: Ten Years of Erlang

#85

Here's to another 10 years of Erlang/Elixir. The programming stack for the boring software developer that wants to clock out at 5 sharp. It's fantastic I tell ya. I have been blessed with opportunities to work with Elixir fulltime and it's hands down the best experience I've had. Compared to C#, Rails, Nodejs, it's miles ahead. (Although C# with dotnet is coming up fast and _crazy_ compared to what it was 9 years ago…

I think you should add to this comment "in my opinion." Because in my opinion C# is miles ahead of Erlang. If I want to create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc, I would use C# 1000 times over versus Erlang. The tools available, documentation, huge amount of libraries and support mean that developer efficiency in C# land is light-years ahead of Erlan…

> create an application, back-end, front-end, running on a wide variety of platforms, Mac, Linux, PC, IOS, etc,

You might not believe it, but that is a fairly niche desire. There a tons of use cases for server software running only on server OSes (which these days, is some flavor unix 90+% of use cases)

And gee, Erlang is/was made to excel at server based software. Not desktop frontends.

My point C# can do 10 things. Erlang can do 1. If all you care about is the 1, then the other 9 C# can do are moot. If Erlang does that 1 better, then it is best (for that use case). C# is best for others.

Re: Ten Years of Erlang

#87
Functional 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 existed since Lisp was invented. The benefits would have to be large to overcome the downsides of this learning curve, and so far they are not, except in certain niches.

I hate the rain the functional parade, but it's been tried and retried for many decades, but will just not fly in the majority of the real world. I'm just the messenger. The jet-powered chainsaw works wonderful in the lab, but actual lumberjacks either can't figure out how to start it or blow their arms off.

If you disagree, please reply instead of negativate me. I would greatly appreciate that.

Re: Ten Years of Erlang

#88

"But the vast majority of them will be a continuous flow of serial early adopters who surf from tech to tech, sniffing the best opportunity to gain a competitive advantage by being first to use a type of framework, language, or toolkit." - Oh god, that hit me so hard.

What's the common slang for that? "Buzzword Surfer"?

Re: Ten Years of Erlang

#89
post #87

Functional 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…

Hi there,

I sometimes try to help normals relate to me by asking, "You know Sheldon Cooper from Big Bang Theory? I'm like a stupid, slighty-less-social-idiot Sheldon Cooper."

I identify with Dr. Cooper. (BTW it sucks being like that. Don't ever think we do it because we like it. There are a few perks but it mostly sucks. Also, it's like living in "Idiocracy". I can't watch that movie because it's too painful. That's my life. From my point of view y'all are running around pouring Gatorade on the plants talkin bout "It's got lectrolites!" It's getting seriously scary now IRL too: where the fuck are all the fucking insects!? We should all be fucking terrified right now.)

Anyhow, from my POV the "average" programmers should GTFO and stop peeing in the pool. I would fire 90% of working programmers. They're not needed and actively counter-productive.

Also, FP is coming on stronger today than ever before. You are in actual fact just wrong.

Re: Ten Years of Erlang

#90

Earlier quoted context omitted.

LiveView is great for writing form validations or simple admin stuff. Even though the examples show that you can do 60fps animations, it is not the intended use case, you're not going to write anything that needs small latency or that needs a ton of processing using LiveView, front end developers are fine.

Even in very simple CRUD projects I have to write a few hundred lines of Javascript to enhance the UI. Stuff like: if you check this box 4 more options appear. Or here is an autocomplete field/dropdown that autofills in 4 other form fields. A lot of basic stuff that cannot be done with raw HTML alone. I can see how something like LiveView would replace the need for mucking around with jQuery when your project doesn't…

Hiding things with unchecked checkboxes, at least, can be done entirely in simple CSS.

  .optional {
      display: none;
  }
  input:checked ~ .optional {
      display: inherit;
  }
Post reply on HN