Hacker News

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

Do changesets incur a runtime cost?

I may be wrong, but last time I checked there was not a statically typed OTP implementation which is kindof a bummer. I think Gleam is the ideal implementation on top of the BEAM but it does just seem pretty immature.

Yeah I agree learning new paradigms can give you new insights.

There's also a balance between learning new languages for fun and for the insights they give, and wanting to ship.

As an example: Prolog was mind-bending for me when I tried it and I had a lot of fun with it, but I can't imagine using it to build a product (I'm sure other people have though).

Perhaps my first comment sounded more critical than intended. I'm really excited to see where this initiative with set-theoretic types goes, and if it leads to a fully statically typed language then that will be a bonus. If that doesn't happen, then I'm still perfectly happy with the language as it is.

Elixir taught me that I don't need static types as much as I thought.

Because the BEAM has much more to it than a terrible dynamic type system?

You are mixing runtime and compile-time dependencies. Runtime dependencies (circular or not) have no impact on compilation performance and stability. Phoenix does include one circular dependency (the layout is rendered by your endpoint and it references your endpoint) but it is a runtime one.

> ... circular dependencies ... compilation races ...

Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files. Looking around, it seems like folks running Dialyzer against Elixir code are using some "dialyxer" thing.

You talk about circular dependencies causing minor compilation troubles, so it doesn't sound like you're talking about types defined in terms of each other. I might be unaware of something important, given that I've never had the opportunity to do Erlang professionally [0]... but aren't the only "dependencies" of BEAM files the exported functions they call in other modules? If I'm not wrong about that, then what happens when you run Dialyzer against BEAM files compiled from Elixir that has circular dependencies? Do its reports become more reliable, or does the reliability of those reports become irrelevant because the transformations the Elixir build system makes to your code make the structure of the BEAM code difficult to trace back to the Elixir source code?

[0] ...and have written nearly zero Elixir in any context...

I wouldn't say it's blasphemy, but I don't really understand the argument about how this relates to 'the application crashing and causing downtime'.

I don't have your level of experience with the language, but I have a personal project written in Elixir, and I do not feel very confident about parts of it that don't have complete test coverage, due to the lack of static typing.

I'm talking about things like: Is this pattern match exhaustive or is there a possible permutation I forgot / specified wrongly, which may then cause a match error at runtime, breaking a particular feature? (of course not bringing down the whole app due to OTP!); or if I change some keys in a map / struct in refactoring, did I forget to change them somewhere else in the application, introducing another error that is only caught at runtime?

Both of these have happened to me, I can even give you examples from code that is not my own – for my project I use a snapshot testing library by an experienced Elixir developer, and while using it I encountered two runtime crashes due to data being in the wrong shape and failing a (function clause) pattern match:

https://github.com/zachallaun/mneme/issues/85

https://github.com/zachallaun/mneme/issues/105

Proper static typing would make it very hard to write bugs like this. In Gleam for example, the compiler checks the exhaustiveness of your pattern matches against the type of the data you're matching against, and forces you to handle all possible values.

> people used to write server software in compiled languages feel the need for them because any runtime bug means downtime

I keep hearing that but I don't think it's been true in many years? Whether it's Go, Java, C#, Rust... a runtime bug will only fail the request, not the whole server.

FWIW, the main reason I like types isn't for the compile-time guarantees (although they're certainly nice). It's for documenting what are the data types I'm working with rather than having to guess them from the code, it's for knowing that something is a square hole therefore I should put a square piece in.

very true; & 4 years for this niche feature, I feel like it was built for hacker news people.

But that's good! Indeed that was the most needed!

& magnificently executed - that's the craziest part - takes away nothing. The compiler is faster!! It's awe inspiring to say the least, what Jose did and still does.

> if you can use AI to achieve full test coverage, are there actual benefits in static typing for coding agents?

Full test coverage doesn’t tell you if the tests behave correctly. So you could prompt an AI agent to write 100% test coverage where those tests could be exercising all code paths yet contribute 0% to the story of what the code does. You need human understanding of what the desired contract is that the tests check.

Imagine a contract lawyer who blindly signs any contract that they are given: they aren’t doing their job. They ought to have an idea in mind of what their client’s goals and limits are so they can determine if a given contract fulfils those needs.

Types are a declarative contract, so they can be a lighter yet more limited way to enforce a contract. The compiler can verify if all the declared types across the program agree with each other. This is especially helpful with refactoring, such as ensuring the adding a field has been rolled out everywhere.

Types aren’t to be just checked by the compiler, but checked by the human authors too. That’s why explicit type signatures are valuable, especially if they are kept intelligible. They encode the different variations in state and possible branching on that state. So you can whittle your types down as a way of whittling the solution down to be more focused. The problem in your head is reflected in the types, and any simplifications in the types then simplify the problem in your head, and any tests derived from that understanding.

In my experience restricting programs that can be expressed is a good thing, even more so with agentic engineering. The more guardrails there are, strong typing/TDD/computer use/..., the solution space shrinks and chance of a robust solution increases. Sure maybe this burns more tokens going in circles but it feels less like a slot machine more like a robot searching for a solution for a well-defined problem.

Devs have very strong opinions about dynamically typed programming languages. But reasons such as "exploratory programming", "expressiveness", "taste" that makes them feel good to program in for humans does not matter for agents. Agents don't care that the language "limits them" and prevents them from expressing the code in a succint way because it would not type check.

>Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests)

This articulates a lot of my own thinking wrt type systems, speaking as a downstream user without a lot of exposure to prog language theory, and I wish this debate were more often framed in these terms.

Another reply to this comment hinted that it might be more about giving LLMs feedback loops and that to me also seems like a more likely mechanism.

I'm not an elixir user but I've watched it from a distance over the years – thank you for your efforts and your experimentation.

>Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with).

I used to hold similar opinion but D language, and this article by Patrick Li (HN JITX co-founder) who's the original author of little known but very powerful language Stanza changed my mind [1],[2].

He argued that Ruby has enabled a very expressive language that enabled RoR, and when it was originally written other languages are less capable, and accordingly the proof is in the pudding.

In his new language Stanza for his PhD thesis he has designed an optional typed system supporting both typed and untyped, it seems very similar in concept to the OP article that you've written on Elixir. Groovy also deserved a special mention, and the pudding is Grails.

Interestingly both Elixir and Stanza have GC, but Stanza also support non-GC namely LoStanza in which Stanza GC is written.

Interestingly, D language pioneered this combination both GC (by default) and non-GC more seamlessly, even before Stanza.

In addition to Ruby, these four languages namely Elixir, Groovy, Stanza and D all have similar to or better expressive power than Ruby. Notably both Stanza and D are compiled languages. Above all D is an anomaly in a good way since it's a fully type programming language. Kudos to Walter and the team for giving birth to a highly expressive fully typed modern language, very fast in compilation and runtime, truly one of a kind [3].

Regarding the issue of comparatively smaller corpus for these languages as mentioned by others, I think the new self-distillation technique for LLM and code generation as proposed by Apple, MIT-ETH and UCLA can overcome this limitation [4].

[1] “Stop Designing Languages. Write Libraries Instead” (2016) (278 comments):

https://news.ycombinator.com/item?id=46525640

[2] Stanza: People:

https://lbstanza.org/people.html

[3] Origins of the D programming language:

https://dl.acm.org/doi/10.1145/3386323

[4] Embarrassingly simple self-distillation improves code generation (201 comments):

https://news.ycombinator.com/item?id=47637757

One thing something like AutoCodeBenchmark cannot demonstrate is what happens when you have human-written type definitions defining the domain before the LLM writes a line of code.

That is something I have found very effective in F#, that I model the domain with types, I know what the type signatures of the functions I need are, and the LLM does the work of actually implementing those functions.

Here is a concrete example:

I have been playing around with a program to assist me with projects I make at home on my hobby-grade CNC router, which does not have an automatic toolchanger. I use a mix of Vectric VCarve and some older handwritten programs to generate GCode files. I end up with a USB drive with maybe 6 to 12 GCode files on it and a model in my head of "to make this product, I start with a board here, gotta install this square nose end mill and zero on this corner of the board, run files A and B. Then install a ball nose end mill and run file C. Then flip the board over lengthwise, switch to a smaller square nose end mill, zero here, run file D. etc. etc."

Although I try to name the GCode files in a self documenting way like 01_TopSide_25square.ngc, if I come back in 1 year and want to make the same thing again, I pretty much always have to open VCarve and eyeball what the hell all the files did and confirm where to zero, what size board to use, etc. So I'm making a tool where I can define those human-operator steps that go with the G-Code files, save it as a "project file", preview in 3d what each step will look like, and export to a printable PDF with screenshots and step-by-step instructions. Hopefully this will reduce the amount of rot that these projects suffer and the cognitive overhead of picking up an old one.

Modeling the steps as F# types was the very first step, like (small excerpt):

    type WorkpiecePlacement =
        {   Id : WorkpieceId
            /// Corner of the workpiece we'll attach to the machine.
            WorkpieceCorner : WorkpieceSpace.Corner3D
            /// Point in machine-space we'll anchor this corner to.
            MachinePoint : MachineSpace.Point
            /// Which face of the workpiece is on top.
            FaceUp : WorkpieceSpace.Face
            /// Rotation around the up-axis.
            Yaw : WorkpieceSpace.Yaw
        }

    type OperationType =
        | PlaceWorkpiece of placement : Operation.WorkpiecePlacement
        | InstallTool of id : ToolId * slot : int option
        | ZeroAt of point : MachineSpace.Point
        | RunGCode of source : GCode.Source
        | RemoveWorkpiece of id : WorkpieceId

    type GCodeInstruction =
        // --- Motion ---
        | G0_RapidMove of axisMoves : (Axis * float<gcodeunit>) array
        | G1_Move of feedRate : float<gcodeunit/minute> option * axisMoves : (Axis * float<gcodeunit>) array
        | G2_ClockwiseArc of ArcParams
        | G3_CounterClockwiseArc of ArcParams
        | G4_Dwell of seconds : double

        // --- Plane selection ---
        | G17_SelectXYPlane
        | G18_SelectXZPlane
        | G19_SelectYZPlane

        // --- Unit selection ---
        | G20_Inches
        | G21_Millimeters

        // --- Distance mode ---
        | G90_AbsoluteDistance
        | G91_RelativeDistance
        // ... etc truncated, more instructions in real code

So I have a ToolPath type that makes the transforms clean. It normalizes the many ways of expressing the same toolpath in GCode to a single representation with all absolute coordinates in metric units.

    type ToolPathInstruction =
        | Rapid of From : Point * To : Point
        | Linear of From : Point * To : Point * Feed : FeedRate
        | Arc of
            From : Point *
            To : Point *
            Center : Point *
            Plane : Plane *
            Direction : ArcDirection *
            Feed : FeedRate
        | ... etc truncated

Yet there is still ANOTHER level of toolpath-related operations that deserves its own type. When I'm doing simulation of material removal to check for crashes, or rendering the toolpath in 3d, I don't want to deal with arcs! The rendering/simulation is inherently an approximation. It will break down each arc into line segments. So sim code and rendering code shouldn't take a toolpath, it should take basically a line segment list, or in other words...

    type ApproxMove =
        {   From : Vector3
            To : Vector3
            FeedRate : double<m/minute>
            IsRapid : bool
        }

    type ToolPathApproximation =
        {   StartPosition : Vector3
            Moves : ApproxMove[]
        }

    parse: string -> GCode
    serialize : GCode -> string
    normalizeToToolPath : GCode -> ToolPath
    denormalizeToGCode : ToolPath -> GCode
    offset : Vector3 -> ToolPath -> ToolPath
    rotate90 : ToolPath -> ToolPath
    scale : Vector3 -> ToolPath -> ToolPath
    approximate : ToolPath -> ToolPathApproximation
    simulate : ToolPathApproximation -> MachineState -> MachineState
    renderToolPathWireframe : ToolPathApproximation -> VBO
    renderMachineState : MachineState -> VBO

I would find it quite frustrating trying to model the same domain without any types, either having all methods working on a single toolpathy data structure that's not really the right fit for any of the places it's used, or having them work on multiple data structures without any clear delineation of which layer is expecting which toolpathy-thing that are all subtly but importantly different.

> 2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about)

I am actually writing a paper on this right now so nothing I can point you to yet but yes. LLMs are better (produce working code in fewer attempts controlling for the relative size of training corpus) when using type systems with inference and global unification. It is largely about the quality of the error feedback channel so languages with very good compiler errors (accurate, localized, include the correction with the failure) can close a lot of ground.

But inference + sound type system gives you a constraint propagation that genuinely restricts the ability of the LLM to get into trouble. Type systems that require annotation give up most of the benefit, since the annotations are themselves surface area for LLM mistakes. Unification also puts heavy limits on the expressiveness of the language which is a confounder and may actually be a big part of the benefit too.

Everyone has been on the "the training data is better" thing but I actually don't think so. All of the languages that people report as being better because of good training data actually have fairly restrictive type systems. Elixir is an exception, but it has exceptionally good error messages! And also, along with erlang, pretty unique runtime semantics that may contribute but that's outside my domain I'm on type systems. Debunking the training quality thing is not what I'm working on but I have deep suspicions about that common wisdom.

> It’s pretty rare that I run into a bug in production that a type system would have caught.

Wow, how different our experiences are. In Javascript/Typescript land, so so many bugs are null/undefined-related and really should have been caught at type level.

In fact, I'd say (without actually measuring it) that _most_ bugs I've ran into in Typescript are due to someone having bypassed the typing (casting, ts-ignore...), or a type mismatch at IO boundary.

Go is pretty great - here's a list of tools I use to help me write/build Go- maybe a few of them will also be what you need: https://www.bbkane.com/blog/go-project-notes/

> It’s pretty rare that I run into a bug in production that a type system would have caught.

Well yes, surely because you’re not designing your system around the type system. You need to architect your project to lean heavily on types, pattern matching, etc to actually gain the benefits. If you move a JS project to TS and just rename the files, yeah there’s going to be no difference, you must reengineer the entire codebase to leverage the type system.

Personally, after moving to TS I’ve been completely sold on types and am currently planning to migrate my app to F# so I can gain even more benefit.

C is among the most token efficient languages out there and is statically typed.

Typescript is very verbose thus it cannot compete with much denser languages on token efficiency.

By the way, the biggest reason many love statically typed languages, especially those that are quite expressive like TypeScript is for the domain and data modelling. Makes it easier to reason about the program and to refactor.

I tried doing my side projects in Go and one thing I miss is the rails console which is so helpful. I guess I could have it write a go console or something but it’s not quite the same

> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language

The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.

> Not necessarily. Since the word "typed" language is not well-defined.

This depends entirely on context. In the Benjamin C. Pierce school of thought (a common choice in programming langauges research; see his book Types and Programming Languages, 2002), "typed" means what we typically call statically typed, i.e., the language employs a static analysis to prevent the compilation/execution of (some subset of) faulty programs. Meanwhile, languages that are commonly called "dynamically typed" are, in this school of thought, not typed (or "untyped"). (TAPL provides a more rigorous definition, but it's in the other room and I am lazy.)

As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?

Rather than having the LLM and human devs all guessing from verbose variable names, can't they both use a language server that observes the code and can surface that kind of structure info cheaply?

Part of the point of types is enforcing more of the contract at various code boundaries (function, module, etc), and that enforcement is specifically so that you don't have to keep the whole codebase in your head / context window in order to be able to work on it.

> the errors I get at runtime are almost never type-based

That surprises me, but everyone's experiences are different. I've been in the statically typed language space for so long and enjoyed it so much, I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind. I'm curious: what kinds of errors do you classify as a type-based error? I think that varies from person to person.

For example, null references. A C programmer would say dereferencing a null is not a type-based error, because it's not feasible to encode non-nullable pointers in the C type system. A Haskell programmer would say it is a type-based error because Haskell makes it difficult not to encode this in the type system, you really have to go out of your way to create a runtime null dereference error.

A C# or TypeScript programmer could answer differently depending on who you ask, because both of those languages make it possible to leverage the typechecker to prevent null-deref at compile time, but neither one makes it required (you can turn those checks off or make them warnings if you like), so it depends on the programmer's build settings and how much typechecking they personally have chosen to use.

This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".

I've been working with typescript for the past ten or so years.

A couple of years ago I did some contract work for a client who used Javascript.

I did some basic smoke testing to understand the state of the app and I was able to get lots of fun type errors on the server and client at runtime just by QAing the damn thing.

I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting.

Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.

when i was programming elixir by hand i was making typing errors about 1 every half year or so. none took production down, most were caught and corrected quickly from logs. now im doing mostly llm elixir, almost all typing errors are caught in integration tests and only one has made it to prod.

I thought a big part of the reason for type systems was a sort of self documentation/contract? Especially if you need to work on an unfamiliar system with bad documentation. Also what about system boundaries? I prefer typed languages personally.

Types always have to be checked. Either at compile time or at runtime. And if you're weakly typed you still check them to see if you use normal or backup behaviour.

If you're statically typed you can remove the actual check from the binary. They are therefore also a performance thing.

Types are useful for squeezing more performance.

Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate.

As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems.

In the half a dozen engineering orgs I have worked, each and every one became a quagmire of slow eng velocity and saw increased velocity and less bugs as they reduced context needed by teams. Separation of concerns, allowing individual services that run independently, more and better tests and observability, and, yes, better typing.

Lots buy into the view "the old system got us here and now we can afford to rewrite and do things 'right'." The real cost is, literally, moths to years of dev efforts to unwind tangled concerns. Million to tens of millions in developer salaries that are going towards keeping the ship afloat as the hull is changed out. The opportunity cost is truly mind blowing.

To avoid that cost: keep concerns separate, define data domains, and use a language that allows you to keep logic localized. If you have to jump files to understand your incoming parameters, you're gonna have a bad time when things no longer fit in your head, and esp. when new to the code as a new hire.

Elixir, I still had to know my whole call chain to know what I could do with my incoming parameters. The more call sites, the more mental context. I choose static types because I can KNOW what my function is receiving locally: it is the type signature.

I would like to validate my experience against other static typed languages like c#; so far, I have seen wins at every org that switched from dynamic languages to Go. Go seems to get a lot right for helping eng orgs move faster.

> Typing generally slows down languages, not speed them up because of all the additional checks that must be done.

Source? You seem to be talking about compile-time versus runtime, and I've not even heard of compile times being significantly slowed by type checking.

> The dynamic stuff is part of what slows down languages like Python and makes them tricky to optimize.

That seems to harm rather than help your previous claim. In untyped languages, in principle every object has to be treated as dynamic.

Yeah we’ll see how that goes when the VC subsidies run dry and everybody gets corralled into token-based pricing.

I use rails because it makes thousands of good choices that I never have to make. If build apps the rails way I don't have to deal with a mountain of tech debt (in the form bad or ever changing choices).

What lower level lang would offer the benefits the beam/otp provide? I suspect you're generalizing a bit too much and haven't thought this through :)

So the future of programming is asking an LLM to spit out the appropriate assembly?

What will you use as training data for these new languages?

LLMs are good at current programming languages because they had lots of data to train on.

theres nothing in common between humans and llms or llm training sets!

I’m so happy with switching all my dev over to rust since AI coding. Everyone is lighting fast and super reliable

i think the design can push people into writing unnecessary matches/guards just to trigger the typechecker.

that said, I'm a fan

Which models do you use for elixir?

Yes, it is what I found works so well. It is easy to write short, specific functions in Elixir and adding Typespecs to theses functions is like typing a block of code. Within the functions everything is "easily" understandable.

Input > Enumerable.Map(Input, type-speccd functionA) > Enumerable.Map(Input, type-speccd functionB)

The issue with TS is that it's not really a type system, it's mostly just comments with a linter bolted on. It tries, but it's fundamentally broken in too many ways.

Here's just one very simple example, there are many more. I've checked all the strict mode options and this appears to still "typecheck".

  var x: {a: number} = {a: 1};
  var y: {a: number|string} = x;
  y.a = 'FAIL';
  var n: number = x.a; // not actually a number

Haha, it is actually my least favorite statically typed lang for this very reason.

You didn't like Purescript? It looked pretty cool to me. Its main competition back in the day was Elm, but Typescript has now taken over. From a distance Typescript seems to have too many gaps. I haven't used it though.

Pretty weak argument as most points aren't inherent to gradual typing at all.

Once you are squarely in a Typescript program and not a "Javascript program gradually adopting Typescript", it would be a good idea to enable Strict mode which forbids implicit-any, effectively meaning the only places you can omit type declarations is where the language will infer the type. Typescript for instance does not infer types of function arguments via their usages (like Flow does), which means in strict mode you must explicitly provide a type for all arguments within a function declaration.

I used to be a bit of a pragmatist when it comes to strict mode, but over the years that has subsided, nowadays I think it is plainly obvious that all Typescript programs should use strict mode unless there's a damn good reason. And I'm not sure there are any legitimate damn good reasons.

True there is no ability to forbid an explicit-any type declaration, though.

I’ve never had a real problem with developers opting out. It’s not that hard to enforce coding standards.

The real problem with Python is the inexpressiveness of its type system and the mess of typed dicts, dataclasses and pydantic classes.

TypeScript may fail narrowing here and there or require a superfluous assert, but usually writing properly typed code, especially with zod, is the path of least resistance.

Well now Claude will add the types for me, so I don't need to use escape hatches

I keep getting baited by these comments so this is the last one I'll respond to, lol.

Elixir is always been sort of a "typed dynamic language" due to how baked in pattern matching is. Any good Elixir developer has always been thinking about types anyway, it's almost impossible not to.

To be fair I think the success of JS is in spite of it not working super well

Well, JavaScript isn't a typed language, so the answer to your question can't even be "no".

> Typescript somehow did it better

I don’t think JavaScript’s syntax was ever designed with the idea that TypeScript would one day exist. Yet somehow it feels like it left the perfect open spaces for TS to later occupy.

IMO OCaml is mind-bending (e.g. go figure out the 'in' keyword, I still don't understand it), F# is much easier/simpler.

Not really, the `any` type doesn't let you perform any operation on it with runtime dispatch like dynamic typing does. Moving logic into json isn't a language feature.

Hi, I'm the lead maintainer of Gleam.

> I don't know the current state of Gleam OTP, but last I checked it wasn't great.

Gleam uses regular OTP, it doesn't have a distinct OTP framework separate from other BEAM languages.

> But then why not just use Rust?

The BEAM?

Your last sentence is basically where I'm at, writing my backends in Rust these days. I'm interested in the BEAM promise of letting things crash but not sure how good that is in Gleam due to its OTP still being somewhat immature as the devs are rewriting GenServer as a typed library.

> writing Elixir is like writing Erlang

I wrote both Elixir and Erlang code. Erlang is just useless to me as a programming language; it has many great ideas though. I love the idea of being able to think in terms of immortal, re-usable, safe objects (Erlang does not call these objects, but to me this is OOP by Alan Kay's definition. I don't use e. g. the java definition for OOP.)

Elixir built on that and made Erlang code optional, meaning people could write more pleasent code. And here it succeeded. I am not sure why Elixir succumbed to type madness now, but the comment that "writing Elixir is like writing Erlang", is just simply not true.

Elixir is significantly better than Erlang with regard to writing code. José Valim got inspiration for Elixir from ruby, to some extent.

Last I checked there were inacuracies. I am not sure if they have been addressed!

> and being able to compile to JavaScript

Apparently it is not that difficult to add different compiler backends. There was a presentation [0] recently about adding wasm support as a compiler target. The implementation was quite far along, including support for the wasm component model.

[0] https://www.youtube.com/watch?v=UQ0--ODjiDk

Sets and types are foundational mathematical concepts so I’m looking for how elixir’s types fit in that context. Union and intersection are not something that belongs only to sets.

Unions, intersections and negations are available in types as well and are by no means exclusive to sets. The distinguishing feature of a set vs type is that a value belongs to just one type while it can belong to several sets.

OP might be referring to Jose Valim's 2023 ElixirConf talk where he's explaining why Elixir should go down the path of types.

He gives a lot more nuanced take than 'types are useless', which is more like 'types are less useful than people think in the context of Elixir development'. (Which makes sense because he's in the middle of implementing a type system for Elixir.)

https://youtu.be/giYbq4HmfGA?t=571

you succumb to the fallacy that because the compiler let it through, the code wont have any error - the erlang mentality says that the compiler/CPU/everything has errors, how do you handle errors in the general sense

The way to see if it's actually a fallacy, look for in-fighting between the two supposedly opposing camps of goombas.

I've seen internet commenters say China is overstating its economic numbers to look more intimidating, and that China is understating its economic numbers to receive more favourable WTO trading terms, but somehow these two camps never called each other out, which makes me think they're the same people believing that China is both overstating and understating.

It has heavy reliance on pattern matching. In fact, `=` isn't even technically assignment, it's the match operator. Assignment is more of a consequence of matching (though it doesn't have to happen, eg: `1 = 1`). All that to say, most Elixir codebases are written with types in mind, and many are written with pattern matching that would cause a type error at runtime. The new type system just builds off that and moves these errors to compile time (well, not JUST that but ya, this is just meant to be a quick answer).

One important thing that is often not mentioned is the lack of operator overloading. In Elixir if you have "a + b" it means "a" and "b" must be numbers for the code to succeed, which narrows down the possibilities significantly. Compare that to Python, where "a + b" applies to numbers, string concatenation, and any object that implements the __add__ or __radd__ magic methods, it becomes a nightmare to type.

The irony is that dynamic languages that predated them had optional typing.

BASIC, Smalltalk vs Strongtalk, Common Lisp, Dylan

It is the eternal September.

> some stuff being sold as "all these libs/packages that haven't had any updates for over a year is fine because Elixir" I just don't buy it

I maintain more than 20 packages and, except for the major ones, like Phoenix and Ecto, they haven't been updated in more than a year and yes, they are all fine.

The language has been extremely stable. There has been almost no breaking changes in over a decade. Case in point: we introduced a whole gradual type system without making any changes to the language surface! The language is still on v1.x!

So you prefer language communities where libraries have a constant stream of fixes, new breaking change releases every six months and entirely new framework ecosystems ascending every three years?

You can buy it if you use discernment. Obviously you'll run into compatibility issues in certain situations - like you aren't going to be able to use a library coupled to Phoenix 1.3 functionality in a Phoenix 1.8 project, but I continue to be surprised at how I can add a package like https://hex.pm/packages/deep_merge, which is 6 years old and it works just fine.

Why would packages need to be updated?

For my $0.02 - it depends where you want to put the onus

Statically typed languages put the onus on the caller to transform the data into the shape(s) required.

Dynamically typed languages put the onus on the called to handle anything.

That is, in a dynamically typed environment your function has to defensively code for every possible type it could be handed.

FYI, that’s currently available in a Humble Bundle with 16 other PragProg functional programming books: https://www.humblebundle.com/books/ultimate-functional-progr...

Yea I've worked through Elixir in Action and appreciate all book recommendations. My issue is, tutorial style books rarely cover security related concerns.

There's also the "bible": https://www.manning.com/books/elixir-in-action-third-edition

I've heard that Phoenix has changed a lot since that book was written. How relevant are those framework specific parts still?

Yea I've posted there twice as far as I remember. You will absolutely get help, whether you understand the answers is a whole different story.

Elixirs community is great. Its just hard to learn because it's not yet widely adopted, there are no (non senior) roles for it and it's a lot of work understanding all the BEAM concepts. A thing just being interesting isn't enough motivation for me to learn, I need a bigger goal but with Elixir there do not seem to be any.

My last experience with it was building something with Phoenix Liveview until I noticed how easily you can hijack the websocket and just spam random commands to your server or temper with payloads (with regular webapps ive built i never had this issue). Which made me quit that project.

I gave up on Rust even quicker than on Elixir haha.

But yea I know about Gleam and I did build some fourier transform stuff with Rust a while back. I like Gleam generally. I am just much much slower with FP and think its extremely unintuituve compared to, say, Go for example.

> But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again.

When I was in university, the introductory class was about Java, and an advanced class in the next semester was about Haskell. There were many imperative/functional newbies in both classes, but the Haskell class still progressed much more slowly. Haskell is simply much harder to grasp, independently of experience.

You can also see this in the fact that even mathematicians use Python rather than Haskell for simulations. Despite the fact that there is no population that is better suited for Haskell than mathematicians.

Even cookbooks are always written in an imperative style, never in a functional one. Why is that? Human brains find imperative algorithms simply more intuitive, and this is not explained by not being used to functional ones.

I'm working on a game engine right now (written in object oriented language, of course) and I keep itching to design a compiled functional language for games, because state spread in thousand of objects, eldritch class hierarchies, are complete hell.

Once you taste Elixir/Erlang, there is no going back to the madness.

The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.

With Elixir specifically it was the learning experience I had with Phoenix. I didn't understand how a Phoenix app booted, didn't know where to edit my config. Syntax like:

``` socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"]

```

Elixir gives you too much freedom on how to write something on a syntax level which really annoyed me.

Luck

Almost nobody uses it though, which is too bad, especially since multi-head functions sometimes make it difficult to follow the execution path.

I'd like to do step by step but I cannot plug the debugger to VScode from inside a docker container.

And CPython runs Python bytecode, which is basically running in a Python virtual machine.

I am not sure what GP is objecting to.

Read again...

Here's what you need to do for elixir:

Download and run the Erlang installer Download and run the Elixir installer

Here for Java: Download and run the Java SDK

And for Python: Download and run the Python installer

You make me laugh as well, all is good.