14 comments

  • spijdar 9 hours ago ago

    I know it's such a cheap thing to say, but this could really use a description/web page that wasn't written by an LLM.

    What came to mind while reading through it is that all of the information and details appear to be technically correct, but they don't really communicate much about the project to someone who knows nothing about it.

    It's weird. I feel like this could maybe be interesting, but also... huh?

    I feel like the idea is to produce a small, self-contained compiler with simple semantics that generates simple executables with a simple runtime model, and a basic supervisor model for scheduling tasks. Okay, that's cool.

    But "vibe coded mass of JavaScript running in node.js" doesn't really mesh well with that vision, at the least to me.

    Also, as whatever LLM that generated that table says, the code it generates isn't "seriously optimized". I don't buy the idea that compiler optimization is something you can bolt on to a project like this later, after you've written the IR and all the platform porting code and whatever.

    It's so hard to tell what the real goal is from the page, that I'm suspecting maybe the author doesn't really know either.

  • manoloesparta 9 hours ago ago

    why javascript for implementing this? i mean you can use whatever language you want but i find it surprising lol

    • pepa65 an hour ago ago

      That drastically reduces my level of interest (in spite of the write-up sounding very intriguing).

    • undefined 2 hours ago ago
      [deleted]
  • forlorn 9 hours ago ago

      op describe {name, role} (
        print "user: " + name + " (" + role + ")";
      )
    
    Strange choice of brackets usage
    • undefined 2 hours ago ago
      [deleted]
    • pepa65 an hour ago ago

      But then the call makes more sense: `describe {role: "admin", name: "alice"};`

  • MobiusHorizons 9 hours ago ago

    Sounds very similar in its approach to magic or hiding as golang. Also the no libc approach is similar, although I believe go was forced to use libc on the BSDs and maybe osx due to the syscall interface not being a stable public interface on those targets

  • souvik1997 9 hours ago ago

    Not sure what is the aversion to libc? The code only supports Intel macOS, seemingly because Apple Silicon (arm64) macOS does not support this.

  • q3k 8 hours ago ago

    slop