It’s possible (even true in my opinion) that garbage collected functional languages and low level languages like Zig are both great, and serve different purposes. I actually ship stuff in Haskell believe it or not. I also think Zig is very cool and have played around with it quite a bit. Yes, garbage collection hurts performance, but the reality is that the overwhelming majority of all software does not suffer from the performance loss between well written code in a reasonably performant functional gc language and a highly performant language with manual memory management. It’s just not important. But not having to deal with the cognitive overhead of managing memory and being able to deal in domain specific abstractions only is a massive win for developer productivity and code base simplicity and correctness. I think OxCamls approach of opting in to more direct control of performance is interesting. I also think it’s great that many functional patterns are making their way into imperative first languages. Language selection is always about trades offs for your specific use case. My team writes Haskell instead of Rust because Haskell is plenty fast for our use case and we don’t have to write lifetime annotations everywhere and think about borrowing. If we needed more performance we would have no choice but to explore other languages and sacrifice some developer experience and productivity, that’s very reasonable. I’m also not saying performance doesn’t matter (if you’re writing for loops in Python, stop). But this read to me like “because better performance exits with manual memory management, all garbage collectors are bad, so I’ll force zig to be something it’s not in order to gain performance I probably don’t need”. Which to me is an odd take. A more measured way of thinking about this might be, it can be useful to leverage functional patterns where appropriate in low level languages, if you find yourself needing to write code in one.

io is not a monad. theres nothing stopping you from stashing a global io "object" and just passing the global wherever you interface with the stdlib.

It's dependency injection. and yes, you can model dependecies like a monad but most people, even in less pure fp langs, don't.

i don't really say this to just be a pedant, but if you're an fp enjoyer, you will be disappointed if you get the picture that zig is fp-like, outside of a few squint-and-it-looks-like things

Do you really prefer this:

  fn Maybe(comptime T: type) type {
    return union(enum) {
        value: T,
        nothing,

        const Self = @This();

        pub fn just(the_val: T) Self   { return .{ .value = the_val }; }
        pub fn nothing() Self          { return .nothing; }

      }
    }

Over this?

    data Maybe a = Just a | Nothing

  var value: ?T = null;

  value = 10;

  if (value) |x| x+=1

    enum Option<T> {
        None,
        Some(T),
    }

> Noise is anything that must be written for the program to function that is not relevant to the domain.

> ...

> What facilities does the language provide me to create correct-by-construction systems and how easily can I program the type-system.

Isn't programming the type-system orthogonal to the program's domain in the same way that manual memory management is?

I'm still fighting with Elixir and losing - for some reason I can't get my head around all the slightly different ways to initialise stuff.

A functional programmer who casts away proper sum types and pattern matching is no functional programmer at all

I don’t get it

Why write:

EqPoint.eql(a, c)

When you can write:

Point.eql(a, c)

Isn't the whole point of abstraction to not care about whats underneath unless you really have to? But ideally, you don't because the abstraction is "good enough"?

I haven't heard anyone writing code in Elixir complain about performance issues.