I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every video I've seen with Joe Armstrong leads me to believe he was an under-appreciated genius. Isolated processes and message passing (Actors) seem a good candidate for the future of distributed programming (see this recent video from Crockford on his new Misty programming language [1] - notice how the questions were about Elixir/Erlang). I love pattern matching and elixir uses this to a high degree.

However, I am not 100% sold. Clearly this community punches above its weight, and the BEAM is obviously no slouch and is a brilliant choice for a platform to build upon. But I get concerned looking at the magic of LiveView (and LiveBook). My experience is that if something sounds too good to be true, it often is. A lot of the jargon is also totally unfamiliar to me - things like GenServers and other esoteric kinds of platform specific knowledge. It feels like stepping into a one-way portal, I'm not sure any knowledge in that universe is transferable.

There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community.

But kudos to that community. It is honestly impressive to me what they have achieved. I'm also very excited to see what happens with their type system implementation.

1. https://www.youtube.com/watch?v=R2idkNdKqpQ

Stuff like LiveView though looks like magic because it is magic. There are a lot of moving parts involved in getting it working. It’s the result of work that has been going on for the past decade across multiple communities though. The ideas are mature even if there is a lot of abstraction.

Stuff like Riak was well ahead of its time. They basically had the idea of being able to create robust distributed systems much the same way you would a GenServer.

IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)

Riak the database used Riak Core, but it could be used independently of the database.

I hadn’t thought about Core in a long time, I should take another look.

Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/

I had some similar issues with rabbitmq

On the other hand, Phoenix channels were much more flexible about membership

The key characteristic is not a state machine, but that:

- first class processes send messages to each other

- messages are queued

- each process is single execution flow. If you want to reenter code, start another process and send messages to it

- process execution can be preempted

- values passed in messages are for the most part, immutable.

- first class support for “links”, where one process gets notified when another process crashes (basis for supervision trees)

The consequences of this design are:

- for the most part, you don’t need mutexs

- spin locks are cheap

- every process can be suspended indefinitely when nothing is in the message queue. This is better than an async reactor.

- processes don’t get “lost” (I am looking at you, Nodejs)

- processes can receive control messages to suspend or shutdown, restart, etc. Most other platforms have to externalize that to say, K8S and such controls are crude.

- errors don’t get “lost” (Nodejs again …)

- repl in production, can inspect the whole system live, under load

- overloaded systems degrades gracefully instead of locking up

There is a real need to push Elixir outside its initial circles and it's being done a bit at the moment (I feel).

Both Chris & José are doing a lot of work for exposure outside the initial Elixir circles, and some people in the community are doing the same at their own levels.

Hiring is not that complicated actually, because a fair bit of people want to work in the language (I experience that first-hand), and a good developer will be up-to-speed quite quickly too.

But the "niche" aspect must be tamed in my opinion, and is both a risk (for the language itself) and a short-term reward (being proficient in a niche something is usually quite good).

It doesn't help you can define your ecto instructions in multiple flavors too (inline vs piping)

You can't mix inline with pipe operators without creating an additiona variable too hold the original query.

If we want to make it less niche, there's definitely good working points there. Once people understand how to hit a database from elixir it magically clicks and the other stuff is more trivial.

Which is great on one hand, because it means we are quite above the average stack in term of onboarding and doc.

But also really makes ecto documentation and onboarding a visible sore point in the middle of the rest.

Sadly i do not have solutions rn but if people have ideas please come offer them.

And agree that there are both excellent documentation, _and_ things that are kind of "assumed" and would need better "beginner" stuff (in my opinion).

On the point of hard to hire and hard to find tutorials. It is true. It is way harder to find for example someone that done what you wanna do in elixir vs javascript. When it comes to libaries it isnt so big problem. There are lots of libraries and so far I havent really encountered any problems. Only thing would be if you interact with an API they might provide a client library for javascript and python (but less common for Go) but not elixir. But honestly it is usually not so hard to use an API with just a http-client.

I am writing Nodejs because I have to, not because I want to. Having used it now, I will never ever start a new project with it.

Nodejs's concurrency controls, ability to scale, tools for reliability and observability are so far behind from the BEAM ecosystem. I sometimes think people think Elixir is too good to be true because they're too used to platforms not designed to be resilient.

One justification for this was that it is supposed to make it easier to reason. It made it more difficult for me to reason -- maybe single-threaded async reactor is a poor substitute for immutability.

Unhandled promise rejection is an example of a consequence of this design. That's not really a thing in Elixir by design. But in the Nodejs world, people don't even see it as a design flaw. It makes reasoning about reliability much more difficult.

It’s a valid justification because it makes it substantially easier to reason compared to mutable multithreaded languages/runtimes such as C(++), Java and C#.

Eg a semaphore in JS doesn’t exist. It’s just a boolean. Interlocked Increment doesn’t exist. It’s just someVar++. And so on, it’s very nice.

That doesn’t mean that there aren’t other setups (such as immutable data with message passing) that are even easier to reason about. Every new tech compares itself to the current mainstream.

What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch.

Liveview is incredibly straightforward.

I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be?

There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward".

This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward.

1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS...

2. https://www.youtube.com/watch?v=7yZwxsG7tVs

However, it is absolutely awesome for the "slightly javascript" case of a lot of UIs. Two examples, from my work:

Forms with "live" display of validation errors, using one single set of validation on the backend, rather than the duplicated frontend and backend having to match. It's completely trivial to implement with LiveView.

Status displays - We built some development hardware based on a Xilinx Zynq FPGA (FPGA + ARM running Linux) and used LiveView to report a lot of the hardware state - primarily the status of all of the registers. A little fiddling with HTML+CSS for the register widget, but then everything else could not have been easier - render your widget once per register, and rerun that whole thing any time pubsub provides an updated register value.

When someone says that liveview is straightforward, they aren't comparing it to stable backend languages that almost exclusively run on one operating system and one architecture and they certainly aren't referring to the many hacks every JS library incorporates to make the library more useful.

Where this gets messy is mixing LiveView and client side JS, and I need to experiment further with this (or find people who have).

https://pragprog.com/titles/liveview/programming-phoenix-liv...

People say this every time Elixir comes up, but, I would like to hear evidence of this being true.

I worked at a startup for a couple of years and had never used Elixir. The majority of the engineers who worked there, whilst I did, also hadn't. We had a few who were experts in the language and a couple who had well-known open source packages.

Genuinely from my experience, each of the things in your list are simply not true.

> But I get concerned looking at the magic of LiveView (and LiveBook).

What magic? Again, genuinely questioning this.

In fact it's kind of crazy how much of it I understand given I haven't tried. The community is just all about simple tools and understanding them.

At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I was just using Elixir instead because it would have been trivial to just spin up a Task to do it and move on.

I get it, of course, it'd be lovely if these complications didn't exist and the same framework handled everything... but I don't think a programming language or even a runtime gets you there. You also need monitoring and ops processes to be part of the solution.

Running heterogenous loads on an elixir cluster is almost trivial. Certainly trivial compared to other languages. No external deps required.

The magic of Elixir/Erlang is that all of this logic can live in one codebase and you can choose when deploying your distributed cluster of Elixir/Erlang nodes which nodes run which tasks. The nodes are all aware of each other and when something happens that requires execution of that task it happens on the correct nodes because they're the only ones running those processes. Automagically.

Not all of us can afford elaborate ops teams

But it's a lot of expense and overhead for someone closer to starting out.

I do not think it's a "home run" kind of win, but it's definitely a "nice to have" that you can just run everything in one place, and worry about splitting it up when (if) you get bigger.

What sort of state management schemes do you have to put into place yo make sure your database isn't full of corrupted data that is going to crash you later (or, worse, silently violate an assumed invariant - and maybe black hole your money or your customers money)

The nice thing is that elixir gives you this either automatically or with a line or two of code.

I do have quite extensive experience with it. And it is a difficult problem.

Lots of frameworks/languages deal with them differently (dlqs, auto-retry, etc.), and each has its pros and cons. In addition, one should have to weigh how important each task is and determine if a 1 in million loss justifies having an extensive resiliency built in.

If Elixir has done that out of the box with a few lines of code like you say, great to hear. And Id love to try it out on day.

> I want background work to live on different compute capacity than http requests, both because they have very different resources usage

In Elixir, because of the way the BEAM works (the unit of parallelism is much cheaper and consume a low amount of memory), "incoming http requests" and related "workers" are not as expensive (a lot less actually) compared to other stacks (for instance Ruby and Python), where it is quite critical to release "http workers" and not hold the connection (which is what lead to the creation of background job tools like Resque, DelayedJob, Sidekiq, Celery...).

This means that you can actually hold incoming HTTP connections a lot longer without troubles.

A consequence of this is that implementing "reverse proxies", or anything calling third party servers _right in the middle_ of your own HTTP call, is usually perfectly acceptable (something I've done more than a couple of times, the latest one powering the reverse proxy behind https://transport.data.gouv.fr - code available at https://github.com/etalab/transport-site/tree/master/apps/un...).

As a consequence, what would be a bad pattern in Python or Ruby (holding the incoming HTTP connection) is not a problem with Elixir.

> because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure.

Unless you deal with immediate stuff like reverse proxying or cheap "one off async tasks" (like recording a metric), there also are solutions to have more "stateful" background works in Elixir, too.

A popular background job queue is https://github.com/sorentwo/oban (roughly similar to Sidekiq at al), which uses Postgres.

It handles retries, errors etc.

But it's not the only solution, as you have other tools dedicated to processing, such as Broadway (https://github.com/dashbitco/broadway), which handles back-pressure, fault-tolerance, batching etc natively.

You also have more simple options, such as flow (https://github.com/dashbitco/flow), gen_stage (https://github.com/elixir-lang/gen_stage), Task.async_stream (https://hexdocs.pm/elixir/1.12/Task.html#async_stream/5) etc.

It allows to use the "right tool for the job" quite easily.

It is also interesting to note there is no need to "go evented" if you need to fetch data from multiple HTTP servers: it can happen in the exact same process (even: in a background task attached to your HTTP server), as done here https://transport.data.gouv.fr/explore (if you zoom you will see vehicle moving in realtime, and ~80 data sources are being polled every 10 seconds & broadcasted to the visitors via pubsub & websockets).

[1] https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4

My biggest joy comes from how much one can do out of the box with beam/otp. Someone in a team I worked with once said “BEAM/OTP is like k8s only without the complicated parts”.

I spent years learning Elixir but unfortunately the benefits were somewhat undermined by the recent migration to OpenShift (k8s) I had just architected.

It would have been a much more tantalizing proposition if k8s was not in the picture; instead we kept our existing dev stack and utilized k8s concepts to achieve what we would have been doing in OTP, with different trade-offs of course.

I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of things and is easier to reason about.

Dialyzer is a static analysis tool for erlang/elixir. It's part of the standard Erlang Release and stands for DIscrepancy AnaLYZer for ERlang programs. It identifies software discrepancies such as type errors, dead code, unnecessary tests, etc., in single Erlang modules or entire (sets of) applications. Dialyzer starts from a base of correct programs and infers types; it doesn't require type annotations but uses them if they are available to provide better warnings.

https://fly.io/phoenix-files/adding-dialyzer-without-the-pai...

https://elixir-lang.org/blog/2023/06/22/type-system-updates-...

So I wish I could have a generic template for a project's GenServer (for basic common registration, memory configuration, logging), that is specialized for a specific task, of which there are three flavours.

Speaking of footguns, Elixir patches this problem with macro code generation, but it is not so good. Any my GenServers are full of trivial repetitions.

And you're absolutely right about genservers being objects :)

If your boilerplate turns out to not really be that samey though, it's easier IMHO to have a template and customize it where applied.

I think this is just plain incorrect. The example given later in this paragraph is the Rails `update` method--but the approach used in all canonical Rails examples and generators is the non-exception version of `update`.

Do you happen to have an example of such control flow to link to? Not that I don't believe you but I wonder if there's a difference in what is meant by "control flow" between commenters.

  begin
    do_stuff!
  rescue MyFirstLibraryError => error
    # handle first
  rescue MySecondLibraryError => error
    # handle second
  end

It may be true in Python--I don’t use it much--but I know Ruby well. It was my primary language for 13 years, at multiple companies. I taught it to over a thousand engineers at Airbnb over the course of five years. I still disagree that it is common to use exceptions for control flow.

Maybe it’s a matter of the interpretation of the word “common.” ¯\_(ツ)_/¯

So my question is what are the main selling points of Elixir besides the Erlang environment?

In my experience they include many batteries that would be libraries in other languages, and most times those libraries add a ton of complexity, and sometimes a big learning curve; Async anything is a good example.

I think once one works with Elixir for some time, and gets to learn these builtin tools and abstractions they understand the power of the ecosystem as a whole.

Yes, it is currently dynamic and yes, that means you won't get much int he way of type information from the language itself, it's not currently a statically typed language.

I don't think it compares very well to F# types, but you can use typespecs: https://hexdocs.pm/elixir/1.15.7/typespecs.html

- the native integration of Machine Learning (including compiled to GPU) with e.g. https://www.youtube.com/watch?v=HK38-HIK6NA, Axon, Nx, BumbleBee etc (there is a real push for that in the community)

- the way LiveView works (although there is Blazor in .Net)

- the fact that Elixir can be used in a large number of contexts (including embedded, see Nerves, or scripting but F# is usable for scripting too afaik)

- overall, the BEAM and associated structures

- package manager (Hex) is really nice (but .Net has nice tooling too)

Just a couple of points from my own experience

You can go by with typespecs, pattern matching and guards but that's kind of exhaustive and not really IDE / Intellisense friendly (at least with the community-led Jetbrains plugin).

Clearly there are strong preferences among folks for static or dynamic typing, almost like vi vs emacs.

My opinion is on typing is:

Stating typing does not slow you down.

With dynamic typing while you are writing code you have to plan and remember what type a variable of some sort represents before You can act on it.

With static languages most type of variables will be known at compile time and can offer good feedback if a type is used in the wrong manner. It also makes it much easier to know what a variable is and what it might be doing if it has an official type.

Reading dynamic code I often have to search around a bit to figure out what a variable is.

I think if the only reason it is "problematic" to have static typing is because writing "int", "string" etc. is too much work then your priorities are mixed up.

Sometimes people resort to Hungarian notation to help out. (Less and less) sName,iAge,etc. That is helpful but you might as well have static typing at that point.

There has been a lot of work done to find a good way to add (optional) static typing to Elixir and I think it is on going but represents a hard problem.

I am glad Gleam is out (https://gleam.run/), it is my favorite BEAM language now.

> In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you.

I don't mean to discount the author's experiences and opinion in this post. It's a nice post with a lot of good food for thought. Likewise I want to share only my own experience here. Two months into any new programming language, it feels like a fun language. Eventually the novelty factor wears off. And then it becomes a boring language. And I say "boring" in a positive sense.

The daily driver languages should be boring. Should present no surprises. Get the job done and get out of my way. When we transistion from the fun phase to that boring phase, what matters more is how good the language is fundamentally designed. As an example in Elixir the pattern matching abilities are great but I don't know if I could justify choosing a language without compile-time type safety in this day and age!

However, I've been starting to see a lot more Elixir buzz, and I love the looks and sounds of it. Looks like I'll need to start a new side project soon to give it a try.

If you enjoy the Result/Either type and API in Rust, I made this project just for this: https://github.com/linkdd/rustic_result

I also made https://github.com/linkdd/rustic_maybe/tree/main for an Option/Maybe type.

NB: Those are not types, but I'm waiting for set theoretic types to update those libs :)

are we really at the point where rust or elixir in the title = instant karma shower?

However every Elixir job I've seen requires Elixir experience, so I don't really see much opportunity for working with it professionally.

But I do think most companies that are looking for Elixir experience would be happy with your weekend project if was actually used by people in a way where Elixir could shine.

"common"? Not IME. Certainly possible, but I don't see it a WHOLE lot. Maybe it's just $CURRENTJOB's style not to, I'll grant.

Perhaps it is possible for applications that have small set of requirements.

Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that.

But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.

Having worked with both EF Core and Ecto, I would gladly see the back of EF Core. Ecto is flexible enough to basically do everything you would with a raw SQL statement, but still use a relation mapper with it's validations. And if you have freeform output because you're doing a bunch of JOINs or querying a MATERIALIZED VIEW or whatever, you can just pipe that straight into a struct inline without having to declare a definition somewhere.

It definitely has an initial learning curve, but once you've built a small sample app, it's quite easy to move ridiculous fast.

It still provides access to raw SQL and can always add in Dapper if you want/need more complicated queries. But productivity is really, really good with very little sacrifice in terms of performance.

Edit: Probably the other good thing about EF Core is the designer, which as you mentioned is great for Rapid Application Development. Not really a time saver vs coding as the application scales, or if you prefer reasoning in code vs visually. Would like to see Ecto feature more user friendly tooling like a designer and automated migrations in the future though.

If you do that then you'll often find loads of other amazing things that are better on the other side.

For example; maybe there's nothing like the MS Entity Framework Core, but instead you'll get to use OTP that everyone's always gushing about which may solve many issues you're having with your current tech stack.

Switching languages (and frameworks and libraries) is amazingly useful because you'll get exposed to solutions you didn't even knew you wanted.

What? Why? Also, what do you mean nothing is as feature complete as Entity Framework? What about ActiveRecord, Ecto, Django ORM, Knex, even Dapper in C# itself......

Many of EF Core replacements do a handful of things well. And after that, it is a cliff.

And now point me to a graphql server that is as feature rich and performant as Hot Chocolate.

Simpler applications will not have complex needs that require feature rich libraries. But, beyond a certain level of complexity, you are on your own. And large orgs do create their own tooling and libraries. But, smaller orgs probably should stick to languages that offer large number of libraries to handle a vast number of problems. Anything else would be putting yourself at a competitive disadvantage.

I found this convenient while writing my first Elixir app with Phoenix Liveview:

https://github.com/hbcondo/last10k_liveview

>I've never written a line of Elixir or Erlang before in my life

How is this possible?

I've been hired to work in Erlang without experience (although I got typecast into php stuff because I did have experience) and although the company was dependent on Erlang, we almost never hired anyone with Erlang experience. Hire smart people that are comfortable learning new things, have a project where the strength of BEAM is compelling, buy a bunch of Erlang books.

My current job is mostly Rust and I didn't know that before I started either. And seems like the team is similar. Smaller team, so I don't know have confidence in my likely to know Rust estimate.

The pool of people who are looking for a new job, and are experienced in Erlang/Elixir, and have exposure to the business specialization, and want to work for a company is very small and hard to find. Hiring companies can ask for it, but they'll have to compromise. It almost certainly doesn't hurt to apply to a job where you don't meet the stated requirements; there's likely no real penalty for having your resume tossed out, and that happens with qualified resumes too. At worst, maybe they blacklist you and won't look at your resume again ever; that's probably ok.

Same thing goes the other way, I'd have preferred an opportunity to use more Erlang, but I didn't find one that met my other needs, so I compromised and write Rust in a cloudy environment and dream about using BEAM and dist and hotloading and all that. Maybe one day.

Maybe it's just me, and I'm not even specifically referring to this particular post ... but why is there so much "debate and discussion" (flamewars?) over static typing recently?

I am guessing this is due to a large influx of people into IT, many of whom got hired because they knew some JavaScript, "React a plus" a lot out of bootcamps and similar programs. As that sizable group ran headlong into static typing, usually via TypeScript, then the debates began.

All over Reddit, Twitter, even HN. People insisting that the verbose and confusing syntax was a "bridge-too-far" and one they would not cross, even if the reasons came down to "it looks weird" or "don't have to 'compile' JavaScript".

Maybe, spending too much heads-down time over the last ... whatever decades at this point ... I simply don't get it.

Don't get it similar to what I quoted here ... "bogged down by a static type system". "Bogged down", in what way?

I spend my days mixed between everything from C# to JavaScript, almost polar opposites. And the rest of it usually in TypeScript.

I do not get this feeling of being "bogged down" by static typing .... ever? I don't recall it being an issue, even though I spent hours in statically typed lanagues yesterday alone. Maybe if you are the author of a complex JS library that has to be shoe-horned into TypeScript ... yes, maybe.

What I did experience recently was being able to remove a parameter from a function, actually compile with the intent it will fail, see it fail, double click on some things and fix the 17 callers to that method I just changed the signature of, and then a minute or so later after fixing those call sites, I was back to work.

Yet, over on the social sites, the debate rages on. Open source projects removing TypeScript practically overnight for "reasons". Questions such as "how many type issues did you run into before switching to TypeScript", leaving me to wonder if that is even a rational question.

And then on the flipside, "TypeScript is the greatest language ever", heart emojis being sent to it, "If you are a JS dev you need to be using TS".

It's all strange to me, having used JavaScript for the first time back in 1996.

I'm convinced it was this wave of JavaScript devs crashing into new requirements to use TypeScript that started it.

It will sort itself out here at some point.

This is Rails stuff, not Ruby

I don't know anything about Elixir, but it bothers me when people claim that languages like Rust and Go are "not object oriented". If you create structs and have special syntax for defining functions that operate on instances of those structs, then those are called objects and you are doing OOP. Just because some Java people came up with a definition of OOP that says it has to have inheritance, doesn't mean you actually have to pay attention to their definition.

Are there any more?

None of the companies appear on that list, I think those kinds of things should always be taken with a grain of salt.

[0] https://elixir-lang.org/cases.html

I tried at some point to use Rust for an API but then I depended on making calls to a very complex API. In JavaScript I would have just gotten back a complex object where I can then pick whatever I want progressively through object access methods. In Rust I ended up with more than 500 lines of type definition for the API and it still wasn't enough so I gave up. It is a bit extreme but when you work with an API from an ERP for instance you can get very very complex and extensive types that are not in your control and not very well specified.

Another good example is how complex all ORM internal code get once they try to add static typing. The typing in the ORMs code feels like black magic because they would really really need types as code but don't have it so have to rely on a bunch of crazy generic combinators.

If you don't know what kind of data people give your function and you don't know what's supposed to happen, how can you write that function? I think many people use too strict of a type system. If your function works with any object that has a toString()->string function, then just write an in-line interface that defines it.

I actually love TypeScript here. It allows for `any` if you're prototyping, lazy or simply don't care. It allows mapped types, where the next dev can see how a type came into being - for example, Mutable, Readonly, Required, Partial. The names actually speak for themselves! And it eliminates the Java-style verbosity of creating classes and files all just for a type.

I'd prefer if dynamic languages would converge to gradual typing support, and static languages to gradual dynamic support. TypeScript is an example of the later, and PHP of the former.

Btw, the equivalent in Python (and MyPy/pyright) is object.

You can always deserialize things as `serde_json::Value` instead of making types for everything to get similar behavior out of Rust.

So then there’s more code for the language devs to write of course, but that’s just the cost of safety, which is highly desirable if you want the technology that you are building to be attractive for use in systems where correctness is critical, which also tend to be highly valuable. As a working professional it’s in my best economic interests to have such valuable tools in my skillset.

Couldn’t that thing be typed as the web format? A nested set of string props with either string or number types in the leaves.

Then use those types to traverse and pull into «real» types?

I like to put structured data into structs in elixir too and the above is essentially what I would do in Elixir.

I don’t know rust well enough to see if I am missing some nuance

But then, you are basically throwing out your static type checks and just using it as a dynamic language, but with much more verbosity, cruft and additional ways to should yourself in the foot.

You also lose all of the performance benefits typing brings, and gain nothing in return. In JavaScript land, V8 moves heaven and earth to guess what your types are and optimistically compile your code behind the scenes assuming its type annotations are correct. Then it dynamically deoptimises and reoptimises at runtime with that new information, while your program runs. As well as being ugly, the equivalent “dynamically typed” rust program would have none of V8’s smarts. It would run dog slow compared to normal rust and still way slower than the (much cleaner) JavaScript equivalent.

Like wood, programming languages all have a grain. If you program in harmony with the language’s design, everything will seem easy. Compiler errors make sense. The standard library will seem useful and well designed. Program against the language’s design and you’ll hate every minute of it.

In my experience, static typing seemed to lend itself to poor testing, maybe some sort of belief that static types were good enough to not need tests that can prevent regressions. So from my point of view the static typing is negative value. It prevents such a low value class of bugs while seemingly incentivizing people to be lax with the most important classes of bugs.

I am totally convinced that the advocates of dynamic programming are right, too, just possibly built differently. For example, if I had an order of magnitude more working memory than I have as an individual (I'm assuming that's neurologically plausible), maybe I'd view dynamic programming differently, too.

The way that I write static-typed code is by imagining how I would write dynamic code to solve the problem, and then additionally imagining what types and type constraints I need to add.

I honestly think it’s a kind of an instance of Paul Graham’s Blub Paradox. I know JavaScript and I spent years writing JavaScript. So if you ask me to write TypeScript, well, I write the JavaScript that I want to write and then go back and add types to make the typescript compiler happy.

There are a bunch of other things I could talk about. I should write a post.

Neither do I, but I know the compiler will check that for me so I don't need to hold all of that in working memory. I know my IDE will always be able to tell me the types too, and flag if anything is wrong immediately.

The different points of view on this are really interesting.

Personally I worked in C for the first years of my career. Then the web happened and the two languages for it were Perl and Java. No more mallocs and frees, it was so great that I kind of forgot C. Then I was assigned to higher level tasks than programming and when I came back to it almost 10 years later I refreshed my Java (I kept doing Perl for my own stuff - CLI scripts and CGIs) and discovered Ruby on Rails. I realized that I could do the same web apps I was writing in Java with much less code and without having to lose my time after obvious but nearly useless details such as specifying that a given variable is a string, or number and how big, or an array of that class of objects indexed by strings (I intentionally use generic terms), etc. It's almost always clear what it is, especially if one picks good names for identifiers. There are some hiccups but not every year.

By the way, a great feature of Elixir is pattern matching in function definitions. In a pythonish pseudocode

  def fib(0): 0
  def fib(1): 1
  def fib(n): fib(n-1) + fib(n-2)

I accept the argument that providing type information to a compiler lets it generate faster code. However none of my customers from the last 10 years care about that argument and they selected their technological stacks. Like everybody else they care about getting features done as quickly as possible. They all run their services on a single server, make enough money to pay themselves, their employees and a bunch of consultants like me.

Is that not how everyone writes static typed code? You have a need for a variable holding some data, you think about the bounds of that data, you pick a type. What other way would you do it?

The problem with dynamic typing isn't in the first-write. It's all in your head then. It's in the 2 year later bugfix, when you're looking at a function and wondering what kind of data is being passed into it. And then you find all the places that call that function and still can't work out what fields that object will have, or whether they're numbers or strings.

The 2 year later bugfix is often easier I agree. But for me by far the biggest difference is speed and effectiveness in writing new code. I'm not just much faster, but also much better with typed code probably because it fits the way my brain works better.

> Is that not how everyone writes static typed code?

For me the process is a bit opposite. I tend to write the interfaces first, usually until the entire routine of whatever I am writing is complete. So e.g. only the types accepted and returned by functions, but not the actual function itself. Then I go back and add the code itself usually at the very end.

I do agree though if I have to work with spaghetti code, I'd much rather work with a language that has a proper type system (I mean a proper one, like OCaml, Standard ML, Rust, Gleam, Etc.) I think static typing in these languages doesn't get in the way, they all have varying degrees of type inference, the type system is sound and uncomplicated. Whereas a Language like Typescript's type system (of Facebook's Flow for JS) had my head spinning, It often felt like playing a mean spirited scavenger hunt with Simon from Simon says.

As far as dynamic langs go, some languages are terrible to work in, (Perl). and other languages because of strong conventions (Ruby and Elixir,) I find very very easy to work in, write tests, create libraries that use DSLs, etc.

So I guess I'm in the middle? leaning in the dynamic langs direction though.

I still remember being quite shocked many years ago when I took a job using Java of all things, I was so fearful coding would take forever. It was my first typed language. But within months, I was faster, by a lot. I would write a lot more code before I had to test it, and once I began testing it there were few if any surprises. Now I'm working in Ruby, and without a debugger and constant tests, I feel I can't hardly get anything complex done in a reasonable amount of time. Like you I thought this was a hurdle that would pass, but while I'm far more effective than when I started, I find that its overall just mentally taxing to write code in this language.

Yet at the same time, when I pair with people who do not dislike Ruby, and watch them work, they are constantly asking "What is this" and "how does this work" and navigating parts of the codebase by grepping. They are effective, and I know its been studied a bit. But to my eyes, they would so obviously be far more effective with types, even when they state they dislike them, I just can't accept its a generally better approach in the absolute sense. I won't judge people for preferring a non-typed language. But I'll likely not accept another job where I can't use a typed language.

On the other hand, sometimes I feel like it has a lot to do with test writing. I feel people enjoy static typing, because you can get a feedback loop catching certain things without writing any tests. If you do write tests, all the type errors get caught pretty immediately anyway, so I just don't see the benefit.

Personally, the biggest advantage of dynamic typing for me is the ability to skip formalities for a time. If I want a function that can modify any struct with field "val" in (by, let's say, setting it to zero), I can - and I don't have to do multiple definitions, I don't have to define an interface. Just a function and I am done. If I want to skip error handling for now and only code the happy path, I can - and my program will work (and crash on error, but in some cases it's ok).

As the projects get more complex and require higher safety guarantees, static typing helps in ensuring nothing got broken - but nothing beats dynamic typing for prototyping.

  function modifiesValField(struct: {val: number}) {
    struct.val = 0;
  }

But I do get your point - although type systems have gotten much less annoying, its not like they're perfect.

This is basically the entire reason I am so excited about Zig.

Edit: it's also the reason I have a love/hate relationship with typescript. Typescript almost lets you do this if you try really hard, but at the end of the day it's not designed to truly test your code and requires you to "cheat" in order to make the types properly describe the situation; every time you "cheat" in order to get a more expressive type (whether that's looser or narrower), you would have been better off writing a test instead.

That's a pretty big if, though. You will never catch me in my typed backyard, writing tests that say: if typeof(arg) =! string then return error("Not a string!")

An additional problem of course is that solutions that assume extra work from people, tend to be brittle ones (also thinking about "manual backups" here) aka. those tests will end not being written at all.

And, if you do not write tests, there is a bunch of other problems that will surface, which will not be caught by the compiler itself. What I'm saying is static types give you feedback loop:

write code -> make the project compile -> fix bugs

while the dynamic ones give you:

write code -> fix bugs (including type ones).

Obviously, YMMV. For me it works. And to be honest, from my experience nothing is more brittle than a type hierarchy designed early in project lifetime and then fixed repeatedly until it "works", but again - to each their own.

This is true. But also I've noticed many less experienced TS devs end up writing types that are too specific and not utilizing structural typing enough. So e.g. writing some type and demanding a function accept it, when that function only actually needs one or two properties from it. Instead that function can inline or localize the part of the type it needs, and the original type can be unaware its ever being used by some other function.

And the other thing is trying to leverage the type system too much. For my style, if the types aren't making things easier to read, write, and maintain, they should be loosened and / or duplicated. I blame a lot of libraries here, it should never be puzzling to figure out how to type something so a function accepts it, yet that comes up quite often; I end up diving through these nested and overly DRY types trying to find what the heck even is this thing? That's crazy. If you need to cmd+click more than once or twice to understand what a type is, its way too abstracted.

I’m spitballing on the reason - I don’t know why it’s like this. But maybe it’s because static typing encourages you to write & plan your types first. When you know the data types, all the functions kind of flow around your types and everything feels like it obviously flows from that. With dynamic typing, it’s the reverse. I find myself writing my functions first (top down or bottom up) and then backfilling what arguments and data everything needs to pass around. I run my code a lot more as I develop it to stop bugs creeping in. And because I can run my code at any time. There’s no type checker stopping me from trying things out.

Lots of statically typed languages are very strict about their types and have too many of them. You have to admit, when you're trying to build something difficult and focus on getting the business logic part of your program right, the last thing you want to be thinking about is e.g. whether you need a String, ByteString, LazyByteString or any of the other types of strings, and which library decided to accept which one. At some level its definitely useful to distinguish between those, and I'm sure a lot of libraries make sensible choices. But initially in the development of the program its just unnecessary busywork that distracts you from the important bits.

In the past, typed languages also made it a bit harder than necessary to create new types, especially in situations where you have serialization and deserialization. And finally, we had to do all this work, and for what? To be unable to prevent the most basic of errors i.e. NullPointerException? You have to admit, it was a hard sell.

A lot of things have changed, however. TypeScript makes it really easy to define types, anywhere - inline on the function in the argument, or right above it. You can pretend the type is correct at deserialization time, or you can use libraries like `zod` to both define a validator and a type in the same syntax - its up to you. Rust similarly has powerful and easy to use tools like serde - structs and enums are easy to define, and easy to attach metadata to them quickly to (de)serialize them accurately. Huge differences from the old world of getters and setters and NPEs.

When using dynamic languages, there are techniques to make things easier. There is the often mentioned testing, which does help verify a large subset of code paths. Lesser known and more subtle technique is coming up with and following a strict naming convention for properties, for example, and to keep things as consistent as you can in general. This is why you often see so much focus in code reviews about conventions, linting and so on.

Nowadays I guess it mostly depends on how good your dynamic language techniques (at the team level) are, as well as what your treshold for type system annoyances is. There are still some annoyances even in the best type systems, but its gotten way, way better.

Out of curiosity, which language do you use where this kind of decision has to be made for daily programming problems?

I've wondered if that's a thing. It seems to be.

The author's joy will also be short-lived because static typing is coming and will likely win out if the implementation is solid.

I'll say types are cool again before I get routed by angry static typing zealots.

I have news for you. A lot of people, including me, do know that catching an entire class of bugs at compile time makes your code less buggy.

The trade-off as usually stated is that more things are possible with more dynamic code, and statically typed code is slower to develop with.

Elixir has much more interesting features that have nothing to do with the types/no types discussion and I 100% agree it would be more interesting to discuss those instead.

My point exactly. Sidetracking every Elixir discussion with complaints about type (especially when they are actually working on it!) gets tiring quick, when Elixir is much more than "just" a dynamic typed language. It's literally missing the forest for the trees.

With proper discipline you can get a lot of type-like behavior if you use structs to represent your data and ensure they're being passed in function args through pattern matching.

{:type_check, "~> 0.13.3"}

Enough pearl clutching. No one's mind was "ruined".

https://github.com/Qqwy/elixir-type_check

Nice to see you are a musical aficionado too. More seriously, how does this compare to other type checking alternatives for Elixir/BEAM were I to start a new project, including Gleam and Witchcraft (which at least seems to be unmaintained for now)?

Especially as you have to write the function name so copy/paste from other @spec doesn't really at least speed it up.

It is what it is I guess.

I would definitely use type safety if I had a lot of external data sources. or if there are lots of people working with me. Otherwise, I am beginning to go back to dynamic languages at least for web dev.

Typescript does not solve the fundamental problems of JS. I'm not convinced it really solved the issues related to ingesting data from many different data sources. The data quality issues were still there.

If I were rewriting the whole thing, I'd rewrite it with Elixir (of course), if only to have a sane way of handling errors.

That sounds like external data validation and I don't think a type system can really solve that. Even if you're using C#, Java, Scala, or what-have-you, you're going to have that issue. If that's what you expected from TypeScript, then yea, I can see how you'd be sorely disappointed...

Like many others, the advantage of type systems for me is in how they reduce cognitive load thanks to their explicitness, even in solo projects. I literally have a hard time remembering the types returned by a function I wrote a mere few hours ago... I have come to believe that there are two broad types of dynamic typing programmers: those who don't know better, and those who have a superior working memory, or cognitive ability, such that types hinder them rather than help them.

I wrote Ruby with duck-typing for 10 years and it never seemed to be a cognitive load for me. My working memory has been degrading as I age. My Ruby code became increasingly written in a functional style. Maybe it's in how I write? Small functions, minimal (or no) side effects, composed together with names that describe how data is transformed.

Explicating types hinder me. Where it had really started becoming more useful was explicit types in functional programming, such as defining monoids or lattices, or whatever, on those data types. My experience with Typescript and even Crystal is that the static typing only yields a fragment of the benefits without being able to define operators that go with those data types. Even the Just/Maybe monad would have helped with messy external data, since that would explicitly define ambiguous data that can be progressively refined into clean data types.

I'm excited to see the new static typing effort in Elixir. It's theoretical base is a set, which, I think, will work better with how people use Elixir in production. It'll be interesting if the Witchcraft (ML ideas in Elixir) will work with those.

For me, Typescript is more useful, the more of the codebase I "own", because it means I can be more confident that all the types reflect the true types of the runtime data, which means I can change things more confidently and quickly. Do you find that you're refactoring and changing things less with dynamic languages? For me, I think that's the number one magic feature that I miss when I use languages without explicit type systems.

I jumped into some code I haven't touched in half a year the other day so had 0 recollection of any of it, thankfully cause of the types I knew exactly what to pass where and what to expect back without even having to read any of the code other than the type definitions.

I love me some dynamic languages, but damn if it isn't nice to have that kinda power available to you.

And after all your Typescript code is compiled to Javascript.

These two patterns allow you to write most code, type free, that gracefully handles anything you throw at it while always doing the right thing.

Making changes to such a system is easy and friction free.

Not many type advocates speak of the downsides of type systems, always pitching the net win and ignoring the actual cons.

When you refactor, make a change, or try to add new functionality, and end up fighting the type checker. That's friction to change you are experiencing and that experience is optional.

I get that having discipline in code patterns and the required robustness is a difficult ask at some organizations and some devs. In that circumstance it's better to have a minder in a type system that enforces base the conventions for everyone.

I don't really see that as "fighting the type checker", I see it as the type checker doing its job and warning me of the places where my refactor broke things. The alternative isn't usually that my refactored code magically works, it's that I have to manually grep through the codebase looking for all the places where I might have broken something, and get runtime errors if I don't catch them all.

In that sense the experience of struggling to make a refactor work isn't optional—the choice you get is whether you want the compiler to assist you with it or not.

I realize there are exceptions for certain types of refactors to certain types of functions, but the vast majority of patterns I've ever seen in any codebase—static or dynamic—are patterns that are difficult to refactor without a type checker and trivial to do with one.

To be clear, there are other reasons to prefer dynamic typing, and I'm not trying to say you're wrong to prefer it, but you're not going to get very far trying to persuade a static types fan that refactoring of all things is better in the dynamic world.

I'm not sure exactly what you're saying. If your language is strongly typed, you'll get type errors no matter what. The only difference is whether the type errors happen at compile time or run time. Let's take a hypothetical example:

Let's say I have a programming language called Foo. There are two ways to run programs written in Foo, using the interpreters A and B. A and B are identical, except for that fact that on startup, A will check that the given program is well-typed (static type checking), while B defers such checks to runtime (dynamic type checking).

Given a well-typed program X, I can run X with A or B without ever encountering a type error. Now, I make some changes, like you suggest, and I attempt to run it again. If the resulting code is not well-typed, I will immediately know when trying to run it with A, but with B I have to be lucky enough to hit the specific case that isn't well-typed.

If I understand you correctly, you're saying that you can easily make changes in a dynamic language without _ever_ causing run-time type errors. If that's the case, you would have _exactly_ the same experience whether you ran your code using A or B.

That’s the same argument people always use. “If you account for every case and also have 30 billion unit tests you can avoid all the problems”. The reality is, people don’t. They cut corners, they forget, or they simply make mistakes.

Not only that, debugging a system without types is a terrible experience, and IDEs don’t offer nearly the same level of refactoring support for untyped languages bc it gets very hard or impossible to infer what’s going on.

If it’s a personal project or a small script, untyped languages are fine. Any other scenario you should be using types

The cost of this mild inconvenience is still far less than the cost of satisfying types.

This aside, I want typed elixir.

It’s happening: https://elixir-lang.org/blog/2023/06/22/type-system-updates-...

One of the best features of type systems is they make editor completions and navigation work better. Elixir's LS is pretty good, but editor support just isn't nearly as good as what you can have in a good (read: Jetbrains) IDE with a strongly typed lang like C# or Java.

the creator of the language has a fantastic talk on this https://youtu.be/giYbq4HmfGA?si=LgSHZupSuR-kMXmj

I can easily see what is passes or returned, and if I'm unsure about the details of the type the answer is a click away, or a short web search away at worst.

Significantly reduces my mental load, allowing me to be vastly more productive.

Having grown accustomed to static typing, not encountering errors until runtime, or worse having errors manifest as type-related misbehavior and potentially not be immediately apparent is much more frustrating than it used to be.

Then you of course have global inference, where you can write code as tersely as in a dynamic language, but still benefit from type checking and add annotations later as a form of documentation for readers.

It also changes the way you code. The best experiences from static typing come IMO from doing type-driven development, where you sketch out your problem first at the type level, then fill out the implementation at the value level. In dynamic languages, you can't program like that. So if you use the same mindset you will find the language limiting.

Weak typing is what causes all sorts of issues.

With dynamic strong types, you can still have a tool like dialyzer figure out potential type issues before shipping, but weak typing means anything goes.

I've seen a lot of authors do crazy type things to get around the type system (like typing out recursion to the n-th level by hand), and I think many open source projects are slowed down by the lack of a type wizard on their team.

But part of doing the correct version is clarifying spec, and prototyping can help with that - so it is a weakly held opinion.

And nothing slows a developer down more than accruing technical debt as they build. It's like having tar stuck to your shoes. You will work the fastest when you have nothing to pay back because your mental model of the application is aligned with the intention of your program.

(That said, I don't think you necessarily need a strong static type system to achieve these aims.)

But in game dev I'm often prototyping something to see if it works at all, or to check its performance. Ignoring types is faster when spending 1-2 hours/days quickly hammering out something that just barely works. On version 2 or 3, add typings.

Maybe it also depends on the timeframe of the prototyping project. After a few days it can become tech debt. (Though I still suspect there are some long term advantages to untyped.)

But once that honeymoon phase is over you usually realize that types and tests were invented for a reason and beyond a certain level of complexity they are absolute must-haves if you want to have high confidence it all works as advertised and to be able to effectively refactor your code.

No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed.

Dialyzer is great but typespecs and pattern matching only get you so far. You'll always run into situations where the shape of data is not clear, and you have to open a REPL to do an IO.inspect somewhere

* trivial errors, that still cause a crash and waste my time ("foo(:yo, 7)" but was "foo(7, :yo)") - sometimes spotted by Dyalizer

* complex nested structures. In Java I never have surprises as to what foo.bar.baz is and I can use autocomplete reliably. Expressing the same invariant in Elixir is something less straightforward

Until we have something like Set Theoretical Types, I think this is the best of both worlds.

Although few people use hotloading in code before, shapes of data can change from deployment to deployment.

If you're using typespecs, then I think the deficiency is with tooling. I think the language servers (like ElixirLS) were quite buggy for a while, but it's getting better at code completion and inspection. But if the type has no spec then you're in the same situation as any gradually typed language.