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

Ten years without Elixir

blog.cretaria.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: Ten years without Elixir

#101

Post by jolux »

kazinator wrote: post #83
jolux wrote: post #81

Earlier quoted context omitted.

In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand…

> While emacs has parts written in C, that portion really exists to enable elisp. You might not have noticed that the parts of GNU Emacs written in C exceed 250,000 lines of code.

You may be responding to the wrong comment.

Re: Ten years without Elixir

#102

Post by jFriedensreich »

swat535 wrote: post #92
jFriedensreich wrote: post #51

As someone who came to erlang at least in part because i hated ruby (and also rails/phoenix like frameworks) i can partially sympathise. I would however put pipe operators clearly on the pro side of elixir and also add the string handling to that list (no pun intended). I am ultimately really happy about Elixir giving BEAM some new popularity in otherwise unreachable audiences, even though i had really hoped for some…

What's the advantage that Elixir has over Erlang?

It is mostly a matter of taste, but Elixir has pipes, decent string primitives, a bit less boilerplate, probably some edges nicer in tooling or standard library, i would say thats about it, both run on the BEAM VM and compile to similar BEAM bytecode.

The killer feature is approachability of syntax. Every single developer i talked to complained about erlang syntax unless they did prolog before or already were an erlang developer. I prefer it but me and OP seem to be the few people who do these days.

Re: Ten years without Elixir

#103

Post by jolux »

jFriedensreich wrote: post #100
jolux wrote: post #60

Earlier quoted context omitted.

Do you have actual criticisms of LiveView as a technology or are you just upset about macros?

: ) Don't get me started on LiveView, i was only talking about mimicking rails mixins with the "use" macro in phoenix. But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.…

So what should Phoenix use instead of a using macro to accomplish this?

>But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.

SPAs are hugely complicated though. Have you worked on a production React app? It's another order of complexity above anything existing in BEAM world, and the JavaScript tooling ecosystem is atrocious in comparison. Not to mention, you will quickly end up having button clicks that require network requests if you are not careful with your SPAs as well.

The whole point of LiveView is that you can develop an app with a similar amount of interactivity as a React app without having to go into the split-universe world that SPAs live in and all the attendant complexity that brings with it.

>Websockets are for things like multiplayer shooters or collaborative drawing, why would someone think it is appropriate to use it to react to clicking a button.

People said JavaScript was just for making ad banners flash 20 years ago and now it's the most popular language on the planet. I don't think a technology's current uses are a good predictor of what it is most useful for. See also: the web itself becoming an application platform, while it started off as a hyperlinked document retrieval system.

Re: Ten years without Elixir

#104

Post by jakeva »

jFriedensreich wrote: post #100
jolux wrote: post #60

Earlier quoted context omitted.

Do you have actual criticisms of LiveView as a technology or are you just upset about macros?

: ) Don't get me started on LiveView, i was only talking about mimicking rails mixins with the "use" macro in phoenix. But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.…

With respect, web sockets are a tool. If you think it is inappropriate to use a tool a certain way then your are obviously free to feel that way, but it seems a little “get off my lawn” to be upset with other folks finding creative uses for it.

My team is using live view and accomplishing incredible things with far less time and effort than we would need using other SPA technologies.

I have no idea how you can assert SSE, HTTP2 and SPAs are 1000% simpler when my experience over the last two years has been the exact opposite. Live view is exceedingly simple to work with.

Re: Ten years without Elixir

#105

Post by yen223 »

lmm wrote: post #96
yen223 wrote: post #74

Earlier quoted context omitted.

If you're interested in what the code is trying to achieve, then `map`, `filter` and the like is clearly more explicit. If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts. It depends on what what you're looking for.

> If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts. In what language? GCC will happily not just optimize away your counter variable but perhaps even replace your whole loop with an SIMD operation; I suspect the Go compiler will do the same. Also, if you're trying to optimize for performance t…

`map` can compile to wildly different things depending on what you're mapping over.

Cache efficiency is important, but so is not running O(n^2) algorithms when you didn't mean to. The latter has an outsized impact on the performance of a program, and explicit loops makes it very clear when something's up.

Re: Ten years without Elixir

#106

Post by [deleted] »

rlander wrote: post #61
Grimm1 wrote: post #7

Erlang's VM is great, Erlang the language isn't imo. Elixir just did it better imo and this person seemingly can't stand that people seem to like it more. Let people like the things they like :P I'm really not sure this needed a blog post.

> Elixir just did it better imo and this person seemingly can't stand that people seem to like it more. The post does read more like venting than a structured critique, but a few of his points are still valid. Every time I hear someone praising Elixir, it's never about some Elixir-specific feature but usually about something that Erlang has provided for ages like pattern matching, lightweight processes, supervisors,…

[deleted]

Re: Ten years without Elixir

#107

Post by lmm »

yen223 wrote: post #105
lmm wrote: post #96

Earlier quoted context omitted.

> If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts. In what language? GCC will happily not just optimize away your counter variable but perhaps even replace your whole loop with an SIMD operation; I suspect the Go compiler will do the same. Also, if you're trying to optimize for performance t…

`map` can compile to wildly different things depending on what you're mapping over. Cache efficiency is important, but so is not running O(n^2) algorithms when you didn't mean to. The latter has an outsized impact on the performance of a program, and explicit loops makes it very clear when something's up.

> explicit loops makes it very clear when something's up.

Disagree. Explicit loops hide the essence of what's happening beneath a pile of ceremony. It's easier to spot accidentally O(n^2) code in map-style code where it's a lot clearer what the code's doing.

Re: Ten years without Elixir

#108

Post by rlander »

sodapopcan wrote: post #79
rlander wrote: post #68

Earlier quoted context omitted.

Well I believe that no pipe is better than a a handicapped pipe operator. The Elixir implementation inverts the classical order of piping last in functional languages to the detriment of it. IMO a language should either support pipe last AND currying by default or supply a multitude of thread operators like Clojure does (->, ->>, as->, etc). Elixir's is just middle-of-the-road-weird.

Is it to its detriment? What's really at stake here? Elixir's pipe operator takes a stance, and I love that. It enforces consistency. I feel it's a lot better than having the "sometimes first, sometimes last" that Erlang and Clojure have.

IME it is. Many Elixir apis end up forcing an unnatural parameter order just so that the entire body can be piped through.

Clojure is way more consistent in this regard:

  - thread first (->) when operating on maps.
  - thread last (->>) when operating on sequences.
  - as-> "choose your own adventure".

Re: Ten years without Elixir

#110

Post by heleninboodler »

eterm wrote: post #25
mmcclure wrote: post #23

From the perspective of someone coming the other direction (a developer working almost entirely with Elixir that needed to jump to Erlang docs occasionally), it's interesting to see the note on docs, and honestly the vibe I get from this blog post feels related to my personal overall gripe with the Erlang community. To be blunt, I really dreaded needing to jump to the Erlang documentation, largely because of a percei…

It's like 2000's MSDN vs current MSDN. The erlang documentation tells you what you need to know and is accurate but it isn't helpful in the way it should be. If you already know what you're doing, it can be a useful reference, but it doesn't aid understanding.

> 2000's MSDN vs current MSDN

Which one is better? I've been out of that world for close to 15 years.

Post reply on HN