I'm going to check out Zig because of your response.

I love coming across comments like this one on HN.

I wrote about cross-compiling to a raspberry-pi and writing a barebones driver for an OLED display[^1]

That was a lot of fun despite the fact the code was incredibly basic. The interop with C was effortless.

[^1] https://www.kamelasa.dev/posts/gettin-ziggy-with-it-pi-zero....

I feel Elm's growth has been stunted because the creator is actively hostile with whoever disagrees with him. I remember the infamous "leaving elm" post which was handled so poorly by Elm's author.

If they had handled it well, elm would have definitely seen a large uptick in adoption

[0] https://www.youtube.com/watch?v=Nutcb6ao0mc&t=4508s

There's very little evidence of ongoing hostility from Evan - I pay attention to his work and writings and find he's rarely if ever hostile. In fact he's very mild-mannered, and is painstakingly detailed about explaining the reasons for why he does things the way he does, over and over again.

Perhaps that wore thin once or twice in the face of repeated criticism and demands. We've all seen way worse.

Yes, sticking to his vision has excluded ideas and contributions, and made some people very angry. There have been several high profile blogposts and twiits painting him as some kind of despot. And when other overzealous developers swooped in to defend his work, it just fed the meme, one which people on HN like to repeat every chance they get.

Well, I for one am glad he's a 'code despot' - considering how many people keep demanding that they dilute Elm's guarantees for the sake of JS library interop or marginally less boilerplate. Any bending to these demands and Elm today would be just another framework with a slightly different syntax, with none of guarantees that allow for the innovative tooling and libraries [1] we see coming out of the community.

Whether you agree with Evan's vision or not, Elm is doing just fine meeting its stated goals and is a fantastic and delightful technology and toolchain.

So please give over with trashing other people's hard work. If you don't like it, just don't use Elm.

[1] for example, the compiler's dead code elimination capabilities, elm-review's tco detection and other amazing auto-fixes, lamdera, etc.

However, elm is not pragmatic. the issues mentioned in Luke plant's "leaving elm" [0] are valid. and Evan's response to that was far from satisfactory[1] and this has affected Elm's popularity.

The disagreement between BDFL and community has happened in many other cases as well. and there is a way to solve them amicably. Most recently, Vue faced it when community caused uproar over composition API RFC. and Vue solved it nicely and amicably[2]. If Elm has followed similar approach, Elm too would be praised for it, and gained even more popularity.

[0] https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

[1] https://www.reddit.com/r/elm/comments/g070sz/evans_response_...

[2] https://dev.to/danielelkington/vue-s-darkest-day-3fgh

The criticism is valid. Haskell is painfully strict and, still, it offers various ways out of its guarantees. Rust is painfully strict and gives you `unsafe`. Neither of them break your build if you don't host your code in a specific github org.

Limiting certain kinds of js access to vetted libraries is benevolent, if that's part of the language's goals. Likewise the lack of type classes or mutability/unsafe escape hatches.

Elm's developers do not enforce constraints to be 'hostile' or 'far from benevolant'. It's a tradeoff - language power for certain guarantees, guarantees that not even Haskell can provide.

Unfortunately, this sometimes means trying to constrain access to the completely unconstrained js library ecosystem, so the solution, at least for now, is a bit of a blunt weapon.

Note that Elm doesn't 'break your build' if you don't use github - that's a constraint on linking to official libraries only. I don't use github and my code works just fine.

ahem

> Progress is zig ...

Thanks for all your work! I ported a bunch of basic data-structures from C++ to Zig very early on (right as y'all began exposing generics). Even though the code no longer compiles, still worth learning The Zig Way™.

If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a language with ambitious goals like Zig to take a stab at coming up with a grammar that's even simpler and cleaner than C.

Regardless, getting a new programming language working, noticed and used is monumental effort, so I wish you best of luck with Zig!

Relative to c, though there are imo fewer special chars:. Zig adds ! and ?, Which are there for really good reason, but subtracts for example <> and #.

The hardest thing is the . syntax for anonymous structs and tuples, but to be fair it is very consistent, and so many times I'd think,"hey I wonder if..." And then try it with the syntax and of course it works.

That is sadly my gripe with a lot of the newer languages too. I have been looking for something to replace C for a long time, something that makes it easier to not shoot yourself in the foot. I just find most of them significantly less readable than C.

Rust seems to be going down the route of C++, hence I do not deem it a safe language at all, as I have an exceedingly hard time parsing the source and figuring out what is going on.

Zig is WAY better in that regard, but as OP mentions: all the special characters make things more difficult to parse. Calls like these (taken from the introduction page) contain so much visual clutter:

  try expect(@call(.{}, add, .{3, 9}) == 12);

The only new C-like language that really nailed it for me syntax wise would be Nim. Very clean and easy to reason about, which - from a programmer perspective - makes it exceedingly safe to program in. It just seemingly lacks most of the safety guarantees that the compilers of other, newer languages provide.

To make things a little more interesting though, Zig's shape in this regard should be roughly congruent to C's, so you should be able to do anything with Zig that you can with C. This includes linking against shared objects for C libraries like, e.g., SDL2[1] or building mixed-language Zig+C projects[2].

0: https://ziglearn.org/chapter-3/#packages 1: https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf 2: https://tiehu.is/blog/zig1

https://github.com/ziglang/zig/blob/master/CONTRIBUTING.md

Though I’m interested in hearing from the creator itself as well.

How will you verify the chain of trust?