Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten Years of Erlang

ferd.ca

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Ten Years of Erlang

#71

Post by imtringued »

thomasfortes wrote: post #46
pault wrote: post #42

Earlier quoted context omitted.

Honest question: if liveView does catch on in a big way, what will the front end developers do? I can't see the huge FED community going back to writing HTML and CSS templates. I wonder if that resistance will hurt adoption.

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 need a big and heavy SPA framework.

Re: Ten Years of Erlang

#72

Post by klibertp »

macintux wrote: post #43
y4mi wrote: post #37

Earlier quoted context omitted.

> It’s more verbose when defining functions, calling anonymous functions, and referencing atoms. and we're finally finding out how both opinions are correct when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously while i cant say…

Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood. I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

> I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

Please, don't use such an excuse for not trying out a language. :(

The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely.

I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared.

There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on.

Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).

Re: Ten Years of Erlang

#73

Post by klibertp »

andrenth wrote: post #70
klibertp wrote: post #68

Earlier quoted context omitted.

> you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class. Well, to be honest, :erlang module has many functions, many of which have literally nothing in common with each other. That's because that module is imported by default in Erlang - it's like `__builtins__` in Python. Exposing it as `Erlang.term_to_binary/1` module/wrapper wouldn't really fit well with the rest of the Elixi…

I agree, but my point wasn't about the erlang module specifically. Maybe :ets would have been a better example. At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".…

> I still think it's a good idea

Hm, it definitely looks like it. What arguments against it were raised?

Re: Ten Years of Erlang

#74

Post by andrenth »

klibertp wrote: post #73
andrenth wrote: post #70

Earlier quoted context omitted.

I agree, but my point wasn't about the erlang module specifically. Maybe :ets would have been a better example. At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".…

> I still think it's a good idea Hm, it definitely looks like it. What arguments against it were raised?

IIRC the main one is that it could be confusing inside a list, e.g. [foo: bar] vs [foo:bar()]. Someone also mentioned that `foo. bar()` (with a space after the dot) is legal syntax, but `foo: bar()` wouldn't be.

I guess you can always do `alias :foo, as: Foo`.

Re: Ten Years of Erlang

#75

Post by mrdoops »

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. Despite being a fallacy of composition, to compare a given Erlang vs Ruby/Rails developer may be useful to consider.

A person who invests in learning Ruby/Rails might be motivated to do so because of that bootstrapping mindset of MVP's and failing fast. Our average Rails developer might be rolling the dice for that "killer app" opportunity more often than our Erlang developer prioritizing concurrency and reliability. This may be because those BEAM features are more useful at a later stage of product development. So while the BEAM features are uniquely powerful if they require an upper-ladder understanding our MVP-developer doesn't yet have - they're unlikely to pick Erlang as tool-set to invest in.

If we accept that the BEAM is good at infrastructure and that doesn't result in as many opportunities for these hype-cycle-causing-killer-apps, than what could be changed in the ecosystem to support this goal? Can we get both the later stage benefits of reliability and concurrency in addition to the early-stage productivity benefits? Maybe this early-stage development focus is where Elixir will break out of the infrastructure-niche Erlang seems to be in. Can Elixir's tooling reach a short enough new-product feedback loop more potential killer-apps get deployed into production? I think as Elixir brings in some different personalities to the ecosystem we could see more killer apps but that idea -> production feedback loop seems to be the key component.

Re: Ten Years of Erlang

#76

Post by verttii »

saberience wrote: post #56
sergiotapia wrote: post #10

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…

Wouldn't this logic make Java by far the greatest language ever invented?

Re: Ten Years of Erlang

#78

Post by arendtio »

mononcqc wrote: post #55
arendtio wrote: post #52

I have never written a single line of Erlang, but I run my own ejabberd. However, looking at the package build scripts and build instruction, I have the impression that compiling a project like ejabberd can be complicated. Does someone know if this is an inherent Erlang problem or just due to some weird project setup in this case?

Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is. All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.

Okay, but if I would start a project today, there would be better tools? Are those documented in the Erlang documentation or are there any recommendations on which tool I should use?

Re: Ten Years of Erlang

#79

Post by strmpnk »

y4mi wrote: post #30
macintux wrote: post #13

Earlier quoted context omitted.

Disagree with “cleaner”.

Disagree with "disagree" ...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner

The original claim is just as pointless. The implication that Elixir fixes Erlang's syntax is so commonly repeated without much discussion that it has many folks dismissing the entire language before they learn it.

I think both languages have issues with Syntax but in the cleaner department, I am baffled at the insistence that Erlang is hard. Inconvenient, maybe but most of the features in Erlang are so primitive that there is little to no ambiguity of what something can mean.

Verbosity strikes both (records and binaries in Erlang vs the sigil and keyword heavy Elixir code) and certainly some folks prefer rebinding variables and colon syntax on atoms but it's certainly not without real trade-offs in common idioms (tagged tuples, special casing required for atoms like true, false, nil, interop with Erlang becomes uglier, etc).

Re: Ten Years of Erlang

#80

Post by mononcqc »

arendtio wrote: post #78
mononcqc wrote: post #55

Earlier quoted context omitted.

Ejabberd runs with a lot of legacy. Essentially the first build tool that could pull deps in Erlang dates from 2007-2009, and it took another few years before more modern tools came to be in what their current form is. All these bigger projects tend to have a bit weirder idiomatic build setups because they had to haphazardly reimplement bits of (at the time) yet non-existing build systems by hand.

Okay, but if I would start a project today, there would be better tools? Are those documented in the Erlang documentation or are there any recommendations on which tool I should use?

As one of its maintainers I’m partial to rebar3 (http://www.rebar3.org/)

It’s become near-official for OSS Erlang work and the OTP team has moved the repo under their GitHub organisation (https://github.com/erlang/rebar3)

Erlang.mk tends to be the other option otherwise.

Post reply on HN