Functional Programmers need to take a look at Zig

type-level hackery of the Haskell / Rust variety where the type system is an esolang that’s secretly Prolog

I feel this

In Haskell type system is a language powerful enough that Prolog can be embedded. The value level system is also powerful enough that Prolog can be embedded. In neither case do you have to embed Prolog. Some people do things along those lines. I program simply.

Agree with you that a) OP doesn't make a strong case for the claimed thesis b) the thesis isn't true, as far as I can tell. I do want to reply with a couple of things though:

[Zig] makes no attempt to give any guarantees whatsoever about memory safety

I would say that this is an incorrect characterization. Zig does provide spatial memory safety in ReleaseSafe mode, and some amount of temporal memory safety. It is, of course, far from Rust, but the distance to C is also substantial. It's unclear to me how the empirical observation about C/C++ codebases having 70% of vulnerabilities due to memory un-safety translates Zig. Has anyone pwned (lib)ghostty? It should be a juicy target by now!

Regarding the title question, I think there are a couple of things Zig can teach about PLT (and there's an ample overlap between PTL and FP). Things that I've learned personally:

The "dependent-types lite" cluster:

• The language of types is an actual programming sub-language, in any language. Before Zig, I understood that, whenever I write I: Iterator, I::Item: Clone in Rust, that's a small program in logical programming language. Now I viscerally feel that is a program.
• The language of types and the language of values can be the same, and you don't have to do dependent types for that.
• In particular, language of types can also be imperative.

The rest:

• You don't have to have HM-style type inference with unification to avoid most annotations in generic code. What Zig implements is very similar to baby's first naive type-checker, that just recursively type-evaluates a tree of expressions. But, in practice, that's enough, contrary to what you might have believed after learning HM, you don't end up annotating types everywhere. Here's a representative example. This is super-generic code that works with asynchronous iterators parametrized by items with custom comparison, and custom type-level direction of iteration. And there's just four user-specified types there, all for the literal 0. And I would have specified those types in Rust as well: even though it would work without types, it'd defaulted to i32, and I do want unsigned here. When you start reading Zig code you see a bit of type noise around functions like std.mem.eql(u8, xs, ys), but that's actually a consequence of library design. It could have been just xs.eql(ys).
• comptime is intentionally much, much weaker than macros. There's no way for Zig program to reflect on its syntax or to generate new syntax. But turns out you don't actually need to abstract over syntax for systems programming. Zig's meta programming is simultaneously significantly more restricted than Rust's combinations of traits, const-generics, and macros, and way, way more convenient in practice.

I'm actually surprised I don't see this comment more. That was my first thought as well. Once I started writing it though, my brain internalized the idea that the "weird" .s were prefixed by an invisible type that's inferred. It took maybe 2 days of writing it before it literally didn't even register to me anymore ¯\_(ツ)_/¯

I guess in practice you could have 2 less dots.

var http_client: std.http.Client = .init(gpa, io);

And if you wanna get wild,

const std = @import("std");
const HttpClient = std.http.Client;

var http_client: HttpClient = .init(gpa, io);

The .init() pattern is fairly common in other structures. I'm not exactly sure why it's not available for the standard HTTP client here.

In any case, I think we can say that syntax is subjective, and still matters. It's just up to you to say in which ways it matters. So we'll always have iterations of many "Elixirs" in response to "Erlangs" because somebody wants to express something in a different way.

I think the ergonomics/readability matter. It seems a little odd to think just because you can represent something in $LANG1 in $LANG2, doesn’t mean it will be easy to work with, be readable, or be idiomatic to the community. The ML family has ergonomics that make its style of programming the most ideomatic & readable. Compare in OCaml

let sum_list_rec lst =
	let rec loop acc = function
		| [] -> acc
		| x :: xs -> loop (acc + x) xs
	in
	loop 0 lst

let result_lst = sum_list_rec [1; 2; 3]

let sum_arr_iter arr =
	let acc = ref 0 in
	for i = 0 to (Array.length arr - 1) do
		acc := !acc + arr.(i)
	done;
	!acc

let result_arr = sum_arr_iter [|1; 2; 3|]

The ability to mutably iterate exists, but the ergonomics leans towards recursion, currying, etc. The things FP users want to do are going to be better suited in an FP-first language where features like tail recursion are often a given.