> Though it seems like the language misses on popular nowadays generators, lambdas and coroutines. So I would say give it a plus on language design, and there is a space to grow.

Lambdas are actually the only way to define functions.

    const f = {args
         /* do stuff */
    }

    use std
    const main = {
        var value = 42
        thread.spawn({; std.put("hi from a thread. I captured {}", value)})
    }

     use iter
     const main = {
          var v = [1,2,3,4]
          for p : iter.byperm(v[:], std.numcmp)
                /* use permutation p */
          ;;
      }

You can already link to C, but writing the function definitons function definitions are painful. There's ongoing work to take Andrew Chambers' C compiler implementation, and extend it so that it can automatically generate the glue code.

We had a Summer of Cod[1] person working on it, but they dropped out due to lack of time.

[1] https://myrlang.org/summer-of-cod

Oh, missed lambdas, that's great!

> You can already link to C

I mean, only on Nix-es, only in Sys-V-like ABI. What if I'm under Windows? What if it's not Sys-V? What if I want Javascript (aka emscripten)?

My use case is game development, I could have a need to ship to wide variety of platforms (for some you don't even have publicly available specs, like PS3), and this platforms only provide C/C++ compilers. Why Myrddin compiler take a burden of supporting all C ABI's out there by implementing it's own asm code generation? Easier way out code be just generating higher level code like C or LLVM IR, and using libffi to implement FFI.

I would love languages like Myrddin to succeed, but let's be pragmatic, it is nearly impossible to support asm code generation with all C ABI's without having a full time team working on it. It is a huge time investment (not even speaking of financial investment connected to it). So I find it's hard for languages to get traction because they keep getting stuck inside Sys-V/Windows realm :( While something that compiles to C somehow magically just-work on everything, even web.

> A: No. You're fucking getting paid in fish, for fuck's sake.

Thank you for the hilarious FAQ.

(read on)

      use std
      const mkincrement = {inc
           var x = 0
           /* No GC, so the upwards closures are explicit */ 
           -> std.fndup({
                x += inc
                -> x
           })
      }

      const main = {
           var g = mkincrement(5)
           std.put("{}\n", g())
           std.put("{}\n", g())
           std.put("{}\n", g())
           std.put("{}\n", g())
	   std.fnfree(g)
      }

      5
      10
      15
      20

How does that work with regards to interacting with the function? If you see that function in a debugger or print it out, do you get just a generic "lambda" name or does it do some magic to get "f" when defined and assigned straight to a name?

It does some magic to get `f` when assigned straight to a name. The magic is pretty trivial.

Total bikeshedding: why the double semicolon? It's one of the few parts of OCaml that nobody likes.

https://eigenstate.org/archive/myrddin-dev/2018-Jan/0000008....

I think there are still going to be some changes before it stabilizes, but it's currently in master.

That is, it makes non-leaky code nicer, but it does not ensure that code is non-leaky.

In go, defer appends a function call to a heap allocated list that gets run at the end of a function.

In zig, defer (and errdefer) do not allocate memory, and get run at scope exit.

I don't think it's valid comparison to Go, since that's a garbage collected language.

Overall Zig feels closer in intent to C than most "better C" languages. In its current form it has a lot of attention to detail about its behavior around common edge cases. It cares about not blowing the stack and dealing with OOM, and the default behavior of numeric overflow is a crash. Stuff that allocates to the heap is stuff that the programmer is made aware of, and "defer" is one of those little additions. It's less developed w/r to higher level abstractions, with the exception of a strong metaprogramming facility and sum types.