astrowilson

You may not believe this, but there are other ways of versioning software beyond breaking things every year and doing whatever Python 3 did.

That’s precisely my point. With Rails and Ruby breaking APIs on every new minor release, the only realistic expectation is that every minor release of anything may have breaking changes, because that’s the example being set. And it just makes the experience of updating any Rails project even worse than it already is.

The language and framework, by your own statement, are pushing breaking changes at a yearly rate. That’s a horrible developer experience.

It won’t cause a uproar because Ruby/Rails changes APIs on minor versions all the time. Breaking changes are pushed at a yearly rate and everyone is just expected to cope with them.

It definitely has something to do with Ruby and Rails. Ruby and Rails introduces API changes on minor versions all the time, sometimes even without prior warnings, so people shouldn’t expect related gems to be any different.

> This type of library API breaking change on a minor version update basically never happens.

Literally happens all the time with Rails. To the point they decided to call their versioning schema “shifted semver” to afford themselves API changes on minor versions: https://guides.rubyonrails.org/maintenance_policy.html

Good luck if you are using Rails and ecosystem and you expect any sort of sensible versioning.

Not sure I agree on Phoenix. There are macros, but only around plugs and routing, not much different to what you’d find in Django and definitely less magic than Rails.

Plugs are straightforward function pipelines and a declarative DSL really helps structure your routes.

The controllers and channels, which are responsible for coordinating with your domain layer, don’t really add anything in the macro department. Plus there is no inheritance, which in my opinion is the biggest source of confusion on most OO frameworks, often requiring you to chase a behavior up and down the class chain.

That’s only an issue if you define your career by a single programming language... I don’t.

Regarding bills, I made my biggest salary bump after I jumped to Elixir, but I appreciate the concern.

You keep bringing up “Elixir has peaked” but you don’t provide any concrete evidence for that. The only mention so far is Stack Overflow, which is not used by the community, and such was explained to you on separate occasions.

Someone mentioned Elixir has just passed top 50 on TIOBE - that’s growth. It also just crossed top 20 on GitHub by number of pull requests on Q1/2021.

I am not disputing it is niche. I am not disputing the job market is tiny. But for someone who mentions acknowledging the truth, you don’t seem to be very truthful on your claims the language has peaked, especially given the last time you claimed so, you used a milestone (Top 50 on TIOBE) that has been reached since then.

So what is your action plan? To keep commenting that Elixir is niche on many threads even though most people here aren’t saying otherwise?

And even if they think that’s true, do you think being antagonistic to them on forums is what is going to change their mind?

I remember a recent comment from you saying that Elixir has probably peaked without even crossing top 50 on TIOBE... and yet here we are.

I can’t reply directly to the comment below yours, so it will be as a side comment.

I don’t think anyone is arguing Elixir isn’t niche, we are just explaining why Elixir gets attention on HN even though it is top 50 on TIOBE. HN itself is focused on certain domains and tends to be early adopters.

Not yet. It only supports Elixir for now (there is an issue for supporting other languages) and the notebook formats are different, so someone would also need to write a nbconvert to Markdown (.livemd).

I accept that my original sentence was unclear. I mentioned more punctuation characters in the context of conciseness, which obviously takes the amount of characters into account. Other than that, I don’t dispute Erlang has less syntax and I hope it is clear that Erlang is noisier (assuming the definition of noise is punctuation / character).

Regarding the compiler, most compilers have ambiguity. It is the reason why you have to put a space between = and binaries in Erlang. The question is if the compiler is going to pick a side or require the developer to be explicit. Modern compilers prefer to fail early in such cases, rather than letting a syntax error pop up later on.

Furthermore, the use of do/end vs do: is completely up to you. My original draft had only the first, which reduced the amount of punctuation in Elixir further, but I decided to include both styles because you will find both in practice. But if you want to stay consistent, you have the option.

Finally, happy to disagree on the “agglomeration of characters” in the Elixir example. The Elixir code has less punctuation and is clearer, despite the use of “do:” (which, as I said above, is optional).

The example that you picked and wrote translates to this in Erlang:

    lists:sort(
      fun(X, Y) -> byte_size(X) < byte_size(Y) end,
      [<<"some">>, <<"kind">>, <<"of">>, <<"monster">>]
    ).

I will let others decide which one is noisier.

(And no, using Erlang strings here is not the same, especially when popular libraries like Hackney and Cowboy work only with binary strings)

> Erlang is actually more terse than Elixir

Which was my point since the beginning but you quoted only part of my reply. It is clear Elixir has more syntax than Erlang. The function definition delimiters (->/.) vs (do/end) is a good example in itself of how Erlang is more compact and using punctuation.

I stand with my position that if you take actual code, a file or a project, and write it in both idiomatic Erlang and Elixir, Erlang will have more punctuation per character and will feel noisier.

Here is an actual example. I got the hex decoding/encoding code recently committed to OTP in Erlang (https://pastebin.com/qMtj8mSY) and rewrote to Elixir (https://pastebin.com/zUCLeXZG). I ran them through the Whatsapp formatter and the Elixir formatter respectively. Both snippets compile and define proper modules. If you remove all whitespace, the rate of punctuation character per alphanumeric character for Erlang is 35%. For Elixir it is 25%. And FWIW, in this particular case, the Elixir implementation has roughly the same amount of characters as the Erlang one: 718 vs 721.

I will be glad to continue this discussion if you want to use actual code instead of fictional examples.

EDIT: I fixed an error in the Erlang snippet and updated the stats.

That’s not a representative example of none of the languages. It is also just plain invalid for Elixir. I recommend checking actual code examples on their websites to form a better opinion.

Your Elixir example is literally wrong. It won’t compile unless you do many changes. You are keeping -> instead do. You are still using commas after each expression. The fn syntax is wrong and also using parens for args. So you forgot to remove most of the punctuation noise.

You are conveniently not showing many examples where Elixir is considerably less noisier such as keywords, utf-8 binary strings, etc. Module definitions in Erlang use -(). while Elixir doesn’t use a single punctuation character. Erlang has special syntax for list and binary comprehensions while Elixir has unified both and uses no special syntax. Maps in Erlang also have two syntaxes, more ways of doing try/catch, etc.

If you take examples of actual code implemented in both languages, instead of cherry-picked invalid gibberish, you will find that Erlang has more punctuation per character than Elixir.

The 3+ years ago is a good reference, thanks for sharing. The issue could also be Ecto related. Ecto 3, which might not have been out at the time, had a bunch of improvements on this front.

> and perhaps there could be a more concise enhancement of Erlang which would get the job done

Erlang already is a more concise language than Elixir but also noisier as there are more punctuation characters. I would love if Erlang would drop some of its punctuation, as some of it is frankly unnecessary.

Elixir syntax is definitely simpler than Ruby’s. Probably in the same ballpark as Python complexity wise: Elixir has less keywords and less rules thanks to the macro system but on the other hand more affordances, such as optional parenthesis.

It is still global. Typing collections and instance/class variables help, you can optionally type methods, but anything that is not explicitly typed is going to be inferred during invocation and that needs to happen based on all callers in the whole program. Reducing the amount of type variables do not eliminate the global behavior.

In contrast, local inference considers a predefined context, such as the current module or class, and is much faster, easier to cache, etc.

It depends on what you mean by mainstream and by large company but Clojure, Elixir, and Elm are all languages that are frequently on HN and they were either personal projects or backed by small companies (<40 employees). I think Julia too.

They haven’t backed off from global inference. They did move to require you to type collections, but methods are not inferred at definition but rather at invocation and it happens globally.

There is no solution really. If you want a language to feel like it is dynamically typed but actually has types, something gotta give, and in this case it is compilation times. And it gets quite high fast.