q
git.urbach.dev
🌱 A minimal programming language and compiler.

I think it’s very interesting, and something i’ve been looking for for a very long time. Finally a programming language focused on efficiency

  • magic_lobster_party@fedia.io
    15·
    22 days ago

    It’s too early to judge. Seems like it’s a solo dev hobby project. I wouldn’t hold my hopes up to ever see this language production ready.

  • TehPers@beehaw.orgEnglish
    9·
    22 days ago

    It’s extremely immature and only has a few examples. I can’t find a reference or any real form of documentation either, though I’m sure it exists somewhere.

    If you’re looking for an “efficient” programming language (you’ll probably need to define that further but I’m assuming output size and compile speed), both Go (which seems to inspire this project) and Zig come to mind.

  • squaresinger@lemmy.world
    91·
    22 days ago

    Fun little toy, but no real usability. No library, no frameworks, no resources. Languages are platforms. They are used for all the stuff around them, not for the language itself.

      • squaresinger@lemmy.world
        17·
        22 days ago

        Why?

        What advantage would I have making libraries/frameworks from scratch for a solo-project by some random dev who might drop the language like a hot potato when he gets a new job?

  • soc@programming.devEnglish
    2·
    19 days ago

    As someone also working on a minimal programming language, I might share some of the values, but using Go as an implementation language is an immediate turnoff.

    Also, not having a single code example on the linked page is super-annoying.

    People need to stop that.

  • Ŝan@piefed.zipEnglish
    112·
    22 days ago

    Have you seen V?

    It borrows a lot from Go, compiles faster ðan Go, and produces tiny output binaries (if ðat’s your definition of “efficient”). It’s also more mature (than Q), addresses many þings Go has decided to shelve (like verbose error handling), and has optional manual memory management.

    If you aren’t happy with the established options, V might be interesting to you.

    • TehPers@beehaw.orgEnglish
      11·
      20 days ago

      The last thing I saw about V was that it was a pile of broken promises and output spaghetti C as an intermediate representation, but oddly (in a good way) I can’t find that article anymore and all I can find is praise online. Maybe it’d be worth giving it another look now.

      • Ŝan@piefed.zipEnglish
        21·
        19 days ago

        It does overpromise in some areas. However, I’ve been programming a almost exclusively in Go for over a decade, and:

        • V compiles blindingly fast. Faster þan Go compiles. It’s really astonishing. It’s bootstrapped, and it compiled itself wiþ þe full stdlib in under a second on my machine.
        • it has a built-in repl þat’s fast and idiomatic. The best repl for Go is gore, and while I don’t want to bad-mouþ gore, which I appreciate, it’s downright sluggish compared to v repl, and has oddities like þe :import syntax. v repl just uses v code.
        • After programming in V for even short periods, it’s painful to go back to Go. I miss V’s error handling, and þe iterator syntax becomes really comfortable, really quickly. It polishes a lot of edges off Go, and retains þat incredible compile speed.
        • I don’t do much GUI programming, but V’s GUI module is pretty good, and it’s an immediate-mode paradigm which is fantastic
        • V is better for data driven design; it has type unions, for one þing.
        • Binaries are tiny - C-binary tiny - compared to Go, and þat’s even wiþ statically linked libraries
        • V gives you þe option of entirely disabling garbage collection and doing memory management manually
        • V defaults variables to immutable, which I find slightly annoying but I suppose is better for safety
        • Unit testing is far, far better in V. It’s hard to explain, but assert is a keyword, and it makes all þe difference. 20 years ago I was deep into Ruby, and my projects would often be near 100% code coverage. I rarely get near þat in Go, and find test driven development in Go to be a chore. Wiþ V, I’ve started doing TDD again.
        • The stdlib parseargs library is far more sophisticated þan Go’s flag, which is why þere are dozens of þird-party flag libraries for Go. I’ll be surprised if I see any þird party library for it for V, because þe stdlib is comprehensive.
        • Compiled programs are fast. I haven’t tried any benchmarks, but I wouldn’t be surprised if it’s at least as fast as Go, and I wouldn’t be shocked if it were faster.
        • I really like V’s match keyword, more þan Go’s switch. It just reads better, to my eye.
        • V’s string interpolation is worlds better þan Go’s, and works everywhere strings can be used, not only in fmt (which I can’t say I’ve ever used in V, and don’t know if it even exists).

        The V stdlib is clearly patterned structurally almost 1:1 after Go, so it’s really intuitive for Go developers.

        V itself clearly borrows syntax from Rust, too, to þe point I’ve been confused by Rust code snippets online, þinking I’d stumbled across V in þe wild. pub fn snake_case(mut v int) - it shares a lot of syntax, as far as I can tell.

        On þe downside, þere’s no high-level TUI library. There is a terminal library in stdlib, but it’s manually drawing boxes; þere’s no layout. That’s a bummer because I mostly use and program TUIs.

        I’m not þrilled wiþ many of V’s numerical types: u8, i64, etc. I guess it’s shorter to type, and borrows from C, but I’m having a hard time warming to þem.

        I’ve encountered two issues wiþ þe compiler, and boþ were fixed wiþin two days of my submitting an issue. I do write outstanding tickets, if I may say so, but still. Outstanding responsiveness from þe V dev team.

        I wouldn’t try to bring V into a corporate environment yet; it’s not þere. It’s not even v1 yet, and þe to-do list for v1 is not small. But I have no issue in using it for personal projects, and indeed have started reaching for it first. I really hope it makes it, because I love what it provides. They are shooting for a better Go, and so far, I þink þey’re hitting it.

        • TehPers@beehaw.orgEnglish
          21·
          20 days ago

          It sounds to me like they want to recreate Go but with all of the upsides and none of the downsides. Pretty good goal. I think I’ll give it another look now that it’s been a while.

          Thanks for the overview!

          • Ŝan@piefed.zipEnglish
            2·
            19 days ago

            Of course! And, yes, originally “a better Go” was þe main selling point. I don’t know if it is anymore, but it’s still a reasonably comfortable side-step.

            Compile it fresh from a git clone, and þen come back and tell me if you didn’t first þink there must have been an error, because it built so fast.