1. 64
  1.  

  2. 4

    My personal split of languages by how quickly I was able to have something working, with no specific order:

    Couple of hours

    • PHP
    • Javascript / Node.js
    • Go
    • Zig
    • Prolog
    • Erlang
    • C#
    • Kotlin
    • Swift

    Years of going back and forth with little success

    • Lisp
    • Haskell
    • C / C++
    • Java
    • Python
    • Ruby
    • Scala
    • Objective-C
    • Typescript
    • Rust

    There is one general and one specific reason for that; both personal.

    The general one is the balance of language, standard library, tooling, community, etc. It is what made me happy and productive in the former list. And it was the opposite for the latter.

    The specific one, as far as I see, is macros/templating provided in the language. The more powerful it is the less comfortable and productive I felt. It was harder to learn the syntax and semantics. It was harder to go through standard library and to make sense of how language features are used. Finally, it was much much harder to read other people’s code and to not feel falling behind.

    1. 5

      I suddenly see so many programming languages popping up. Zig, Inko, Janet, crystal etc. each tailored to solve a problem. Seems like people are done with interpreting and in some cases GC as well. Renaissance of compiled languages folks!

      1. 2

        Seems like people are done with interpreting and in some cases GC as well. Renaissance of compiled languages folks!

        Aren’t Janet and Inko interpreted?

        1. 2

          It’s a good time!

          1. 1

            I don’t see it that way, interpreted languages will be the next phase, but for now we know we have not seen awesome enough things from the current compiled languages, so are trying to fill that space out.

          2. 1

            Great talk. I have a couple questions that weren’t answered in the Q&A and I don’t see answered on the Zig website.

            Does the Zig frontend compile-to-C under the hood? This is something that irked me about some other newer modern languages in this same space like Nim due to the inadvertant undefined behavior that it could create rather than going directly to IR (which to be clear could also create other UB, but at least it could be well defined for the language instead of being a bug introduced due to the C conversion).

            How is cross-compiling support for other OSes? In the shown slide, all of the targets were Linux on some arch and libc, but is it just as easy to cross-compile from one OS to another? Actually, this looks supported according to the website!

            1. 12

              Does the Zig frontend compile-to-C under the hood? This is something that irked me about some other newer modern languages in this same space like Nim due to the inadvertant undefined behavior that it could create rather than going directly to IR (which to be clear could also create other UB, but at least it could be well defined for the language instead of being a bug introduced due to the C conversion).

              This is a fallacy, “compiling to X” doesn’t mean you inherit its flaws, that’s the whole point of compiling. UB is a worry when you’re writing C manually, but when compiling to C it’s only a problem if there is a bug in the Nim compiler.

              Asm has an “unknown opcode exception”, C doesn’t. And C compiles to asm.

              1. 7

                Does Nim put checks in place for things like signed overflow? If so, how does it affect performance?

                1. 2

                  Yeah, it does. Haven’t benchmarked it personally so not sure. This is of course all customisable, so if you’re feeling brave you can disable these checks.

                  1. 2

                    Thanks for the response, and doing overflow checks really does seem like the right thing. I remain curious about the effect on performance, as in my opinion this is a serious drawback of C as a compilation target.

              2. 5

                Does the Zig frontend compile-to-C under the hood?

                LLVM-based (like Rust and Crystal), from the looks of it, though Zig’s written in itself now.

                1. 22

                  though Zig’s written in itself now.

                  Clarification: the self-hosted compiler is not able to build anything beyond hello world yet. However the zig compiler that is shipped on ziglang.org/download is in fact a hybrid of C++ and Zig code. It’s actually pretty neat how it works:

                  1. Build all the compiler source into libstage1.a, and userland-shim.cpp into userland-shim.o.
                  2. Link libstage1.a and userland-shim.o into zig0.exe. This is the C++ compiler, but missing some features such as zig fmt, @cImport, and stack traces on assertion failures.
                  3. Use zig0 to build stage2.zig into libuserland.a.
                  4. Link libstage1.a and libuserland.a into zig.exe, which has features such as zig fmt, @cImport, and stack traces on assertion failures.

                  Think about how cool this is, in step 4, the exact same library file is linked against a self-hosted library rather than a c++ shim file, and therefore the re-linked binary gains extra powers!

                  1. 1

                    I love PLs but I’ve rarely sat down and done the work to piece through how magical this stuff is. Thanks!

                2. 4

                  I’d say the Zig cross-compilation story is even better than Go’s. And that’s a really hard bar to meet.

                3. 1

                  This got me interested enough to invest some time in trying a port to Zig of some C – the examples given were incredibly pertinent. Thanks!

                  1. 1

                    I laughed much harder at that 666 reference than I should have. Definitely on the line of what was ok, but that’s what makes a good joke after all :P.