Zig: programming language designed for robustness optimality and clarity [video]

I think I get it now: use different types for nullable and non-nullable pointers. Only non-nullable pointers can be dereferenced, and the conversion from nullable to non-nullable must be done explicitly, with different flow in the case that the pointer turns out to be null (which is to say, a non-nullable pointer will never enter scope).

Dereferencing null is impossible, and the programmer is forced to explicitly handle null values.

This contrasts with C, where the same type is used for a nullable and a non-nullable pointer, so the compiler can't help out, the programmer is at risk of forgetting/failing to keep track of the difference between the two, and null-dereferences may occur (and give you undefined behaviour).

Java references take the same approach as C pointers, except all dereferences are checked at runtime, and dereferencing null throws an exception.

I like it! It does better than the Never null, only cromulent values approach (like C++ references), as this can be inconvenient in practice. It makes null-dereferences impossible, and doesn't do anything funky that would introduce needless runtime overhead.

> Features I want are: * pythonic indent * no trailing semicolon

I would recommend against making up a completely new syntax, since there would be no support in any existing tools (parsers, linters, IDEs, formatters, ...). Instead, I'd suggest picking a general-purpose syntax with the properties you want (indentation for grouping, newlines for sequencing). One excellent example is called "sweet-expressions", which was originally invented for Scheme but can actually be used to represent any structured data (especially code):

https://srfi.schemers.org/srfi-110

You can use tools like "sweeten" and "unsweeten" from https://sourceforge.net/projects/readable/files to convert between sweet-expressions and s-expressions. S-expressions are just raw syntax trees, so "unsweeten" is basically a ready-made parser which you can pipe into any other program you like, e.g. linters, macro expanders, pretty-printers, etc.

To make your language compile to C, you would need some way to "render" those syntax trees into C code. There are existing tools to do this, for example the C-Mera system can read in C syntax trees and write out C code https://github.com/kiselgra/c-mera

Your preprocessor could then be as simple as `unsweeten | cm c`

To add completely new features like immutable strings you would just need to define some representation for them in the syntax trees (or, if you want to make them the default for "double quotes" you should define an alternative representation for non-immutable strings), then write some find/replace macros to convert occurrences of this representation into an equivalent (but more verbose and elaborate) set of C syntax trees. Stick this find/replace step in between `unsweeten` and `cm` and you've got brand new syntax for very little work.

Have you tried Nim? It has (almost?) everything you're looking for and compiles to C, C++ or JS.

https://nim-lang.org

> It has (almost?)

No, it has all the features mentioned in GP. It's worth noting, though, that Nim is a higher-level language than Zig appears to be. Nim is garbage-collected, has an object system with multi-methods, has proper lambdas and higher-order functions, uses a kind of uniform access principle (`foo.func()` is the same as `func(foo)`, basically), has destructors and defer blocks, exceptions, iterators, generics, operator overloading, AST based (but procedural) macros and templates, a kind of type-classes (called concepts), built-in concurrency (thread pool) support, and more.

I'm not sure how well it would work on microcontroller, for example, although its garbage-collector is tunable in terms of memory and times constraints. But for anything higher-level than that, Nim is a really nice language, which reads very similar to Python but is natively compiled and much faster (among other features). A quick example to back up the similarity claim:

    proc getMem() : tuple[total: int, free: int] =
      let
        (output, _) = execCmdEx("free")
        fields = output
          .split("\n")[1]
          .split()
          .filterIt(it != "")
      return (fields[1].parseInt(), fields[^1].parseInt())

Really worth taking a look at, if you want conciseness and performance without compromising readability.

Right, he answers a question about this. His plan seems to be to pre-calculate the stack space required at compile time using static callgraph analysis.

This is not yet implemented.