rlander

Except const is not sufficient. It will prevent the reference from being reassigned but the const can still reference a mutable object.

Maybe you haven’t seen this yet, but there is a (recent) option to fork a conversation when you click on the thee dots of a reply.

True, but GDP is often a decent proxy for material living standards, especially across countries and over time (so long as we note what it leaves out).

That’s not a small cycle count for a normal household. 90 × 24 = 2,160 total hours.

I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week. That works out to roughly 15 years of usable machine time for the average person.

Not bad at all.

> if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead.

Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.

> I just wonder, whether a new language is necessary to achieve this.

To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.

I feel like you missed the point of Imba. It's not solely focused on code compression (although that does appear to be a secondary objective). Instead, Imba is all about empowering developers to create declarative user interfaces without the typical complexities that often accompany such tasks, like dealing with reactivity, signals, custom directives, v-dom, and so on.

Opa was ahead of its time by at least 10 years. Have you seen Electric Clojure [0]?

[0] https://github.com/hyperfiddle/electric

What an amazing story! I have to admit, I was a bit apprehensive while reading through it.

Does that apply to neutered males?

That’s weird. We moved to a new house and I was surprised one morning to see the cat scratching the upper balcony door, waiting to be let in, even though he’d never used that particular door until that day. He seems to always wait by the door that’s closest to the nearest awaken human, regardless if he’s ever used that entrance.

How is Elixir’s design different from Erlang’s? Semantically they’re pretty much the same language.

A better example would be Java/Clojure.

> Elixir code out there is much cleaner than erlang code bases.

You do understand this is just your subjective opinion and not a universal truth, right?

You are basing your argument as if it was a fact that Elixir is “cleaner” (whatever that means) and that there was a thing called “software-testing-revolution” which Erlang was never a part of. Both are subjective and, frankly, plain BS.

> if you are truly dedicated to the craft of software you probably should want them to learn Elixir

Oh boy, I don’t even know where to start... so you’re basically implying that Erlang programmers are not “truly dedicated to the craft of software”? It would be laughable if it wasn’t just sad.

This is the Ruby world mentality that just rubs me the wrong way. Not even worth carrying on with the discussion.

You’re missing the crux of the argument: auto-currying. In languages like Elm and Ocaml all functions are single arity which means a multi-arity function is just a partially-applied single arity function thus you can treat all functions as being single arity. This also means the pipe operator can be implemented as a higher order function being, as such, first class. Languages without auto-currying have to resort to macros.

Clojure also doesn’t have auto currrying, but makes up for it by giving you 6 variants and creating a consistent default library for sequences and associative structures.

So, the pipe first operator is just a dirty hack.

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".

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.

> 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, the preemptive scheduler. Given this, I'm sure you can appreciate how bittersweet this can be for an Erlang developer.

To me Elixir is just a more complex, verbose and less elegant version of Erlang so it kinda frustrates me when newcomers would rather learn Elixir than plain Erlang.

Why I choose Erlang:

- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.

- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).

*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).

> adds a tons of complexity over just using JS.

What "tons complexity" are you talking about? Clojure is a much simpler language (in the decomplected sense) than JS. Less syntax, better build tools, uniform stdlib, no webpack/babel nonsense. This sentence makes no sense.

> interacting with the JS ecosystem is painful cause of its reliance on the closure compiler.

Again, what? With tools like shadow-cljs, requiring JS libs and using them in you project is trivial (just require and import like you would any cljs library).

> In Clojure, is almost the same, most Java libs are over-engineered and horrible to use but you need to reach for them because Clojure lacks an ecosystem.

I've been writing Clojure for 10 years and rarely have I had to reach for Java. This is absolute rubbish.

You seem to hold strong opinions about a language you barely understand.

Edit: reading you comment history, you seem to have an axe to grind with Clojure.

Please don’t listen to the peanut gallery. The re-frame docs are in a league of their own and most of us appreciate the enormous effort put in to make them awesome. Keep rocking.

*Edit: Let My People Go Surfing is the name of the book.

(Couldn’t edit the original)

Yes! Btw, the founder, Yvon Chouinard, a renowned mountain climber, wrote a great book about the story behind the company which is regarded as the “philosophical manual for the employees of Patagonia”. Awesome read imo.

Thanks, already subscribed to those channels. Thing is, much like a lot of comments here where devs want to learn new tech but struggle to come up with a side project idea, I can’t really think of anything useful that’d be within a beginner’s skillset. Anyways, thanks for the thoughtful reply and maybe watching a few videos will spark my creativity!

That side table is amazing. How did you learn woodworking? I’ve been meaning to get into it but have no idea where to start.

I’m just finishing Eiger Dreams, what a great book! I wish Krakauer would write more recent mountaineering books.

Basically anything that is protocol-oriented like WhatsApp. A lot of people will say fault tolerant, low latency, highly available and massively concurrent systems, and they’ll be right, but I think that’s only half the story. You also get a battle-tested blueprint for building these kinds of distributed systems. You will find a pattern here and there in other languages and VMs, but the cohesiveness of the package (language + BEAM + OTP + observability + patterns) is something really unique. Compare this to the Java ecosystem, where there are dozens of concurrency primitives and an even greater number of distributed systems libraries and frameworks like Akka, Mesos, Zookeeper, Storm, Flink, Samza, Heron, Helix...

To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.

I have my own share of objections, mainly concerning the over-engineered nature of RabbitMQ, but most of the “huge learning curve” items that you’ve described can be learned in an afternoon by a motivated software engineer. Besides, she will have to learn those concepts anyway because they apply to most brokers.

Thank you, good sir. Those’d be parts 2 and 3 of the business plan, with 4 and 5 being “???” and “profit”.

In all seriousness, I’m just hoping to revive a simple (and awesome) game.

I'm working on a browser-based MMO based on Game Neverending [0] (the game that eventually morphed into Flickr):

[0] https://www.giantbomb.com/game-neverending/3030-48604/

Do you have any links to resources or blog posts explaining how to do web dev in Arc? A cursory google search turns up ArcGIS stuff.