We are building a new systems programming language | Hacker News Reader

We are building a new systems programming language

drewdevault.com

72 pointsals035 comments

People always talk about syntax rather than what really matters about a new language. However, I wish we didn't have to use iteration indexes just to access elements:

  for (let i = 0z; i < len(greetings); i += 1) {

  for (let greeting in greetings) {

My bet is that there's no notion of iterator (or generics, for that matter) so at best that would be like Go's loops, very limited in purpose.

For a language that specifically says it has manual memory management, it makes sense that there are no implicit iterators. I guess what you want can be done at compile time and work without them, but probably it's a lot more work than what manual indexing requires.

    for i := 0 to len(greetings) do

and if bigger increments are desired, e.g.

    for i := 0 to len(greetings) step 2 do

That's a lot of extra keywords.

I suspect the bigger point being made by GP is that languages with manual memory management and iterators are not an incompatible concept. Given pjmlp is the commenter I suspect the language he's using is Pascal or another Wirthian language. See also Ada for another example of a language with manual memory management and iterator constructs.

It may introduce some extra syntax/keywords though, which could be against what seems to be a minimalist approach (from the sample).

Code is read more than written, readability matters.

If readability matters, there shouldn't be an extra counter variable for the reader to keep in mind.

    for greeting in greetings do

is more readable if nothing interesting is done with the counter itself.

Ada does this. Offering both styles:

  for x of Some_Array loop
  for i in Some_Array’Range loop

Allowing you to do the appropriate thing for your situation.

Indeed, I just wrote the version where the counter matters, because it was used as such on the original examples.

As a matter of fact, Object Pascal/Delphi uses the for in syntax when it doesn't matter.

Not really, iteration requires the existence of interfaces, requiring two methods (or one, if optionals are supported). Iterator semantics are orthogonal to memory management.

The transformation into a while loop is a handful of lines of code (unless your implementation language sucks). It's not difficult for simple iterators (but can get dense for more generic constructs like generators).

> I guess what you want can be done at compile time

Yes.

> but probably it's a lot more work

No, at least not if you want to limit yourself to arrays, this is a trivial thing for a compiler frontend to handle. For example, the parser could already translate the "iterator for" loop syntax into exactly the same representation as it would produce for the "counter for" loop syntax.

The javac compiler for java does this: It transforms loops over arrays using iterator syntax into "normal" counter loops. Loops using iterator syntax over non-arrays are compiled to use iterator objects.

As an example of this: https://doc.rust-lang.org/stable/std/iter/index.html#for-loo...

I don't see iterator syntax being desugared to a counted loop there. I don't doubt that the Rust compiler eventually produces a counted loop when iterating over a vector, but this link doesn't demonstrate that.

It’s not a counted loop, it’s true. for loops are sugar for iterators and an infinite loop + break. My point is that it is not a particularly complex transformation, as you said. I thought the complexity (or lack thereof) was the high order bit. Sorry I should have been more clear!

Wadler's Law :)

Curious to hear why this exists when Zig is further along (and more promising imho)

And similarly, the D language. Is there space between/around C, D, and Zig for another?

I think the answer is probably yes until such time that people choose a language over C as the default for those use cases.

It still hasn't happened although C++, Rust, and even Go are chipping away at it.

Rust does not intend to be a replacement for C though, while Go does (partially).

Rust is used in places where C is used though. For example it is used for Python cryptography where C was used before https://lwn.net/Articles/845535/. I doubt Go could be used this way. What do you mean exactly by "does not intend to be a replacement for C"?

Rust was developed to replace (parts of) C++, initially. C++ has a different niche than C.

Rust doesn't "intend" to replace any programming language because we don't really believe programming languages get replaced.

Rust does want to be useful in the same niches where both C and C++ are useful, among other niches and languages in those niches.

It sure can,

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://tinygo.org/

I was talking specifically about the cryptography part, sorry if I wasn't clear enough. I don't deny that Go can be used for "low level" or embedded development. But, I don't think Go can be used to create libraries used in other languages easily.

Go can do this easily - you just do `go build -buildmode=c-shared` and put a magic //export FuncName comment before any function. This produces a C ABI .so (Linux) / .dll (Windows).

Although the resulting library is a little bit heavy (1-2MB) because it bundles the Go runtime and GC, and initializes it on first load.

Thanks, that's something I didn't know about.

Rust is a No true Scotsman of programming languages.

Probably Drew wants to try his hand at a compiler and has the time to do it. Does it really need to be more than that?

The post refers to an existing team -- "we" used for everything -- so he's presumably convinced other people to work on it as well.

Unless they're all on the same page (because why not?), there must be something compelling about it.

I always wonder if "we" spend too much time on new languages and not enough on good libraries in existing popular languages.

They’re really not that different — a language is essentially a library, but at a lower level of the stack (the hierarchy being OS > language > framework > library > application)

From that perspective, it makes about as much sense designing a framework versus a language, relative to a library.

The question then to justify a new language is to justify whether it could have been done with about as much benefit, but on a higher tier (thus, lower effort, for both the developer and the user)

Drew did take an interest in zig for a while. It does look awfully like zig. I think I see two major differences:

First:

> we want the first release to be a complete, stable, production-ready programming language with all of the trimmings

so arguably drew is ahead of zig. My understanding is that Zig is being open now (there's a major breaking syntax change in the pipeline), but will be very conservative about what goes into 1.0, so there is a lot of tying off loose proposals and finishing out the language, and documenting everything ahead of getting to 1.0. That's going to a while with such a large community as zig's.

Second:

I'm guessing this new language will have less complexity in the "comptime" space. The syntax is really close. If I had drew's ear, I would almost have him write the spec to match Zig and market it as Zig--.

Coda

I'm a huge zig fanboy, and if it is up to being a "competition" I would guess that zig will do better. 1) Andrew is extremely skilled at figuring out? (marshalling?/delegating?/not overdoing?) the social/branding/growth of the language. 2) having had a more open initial design, Zig will cover far more interesting ground than drew's language. 3) I don't know if this is deliberate or accidental, but it seems to me Zig is following microsoft's "Embrace, Extend, Extinguish" philosophy quite well, with a holistic view of not just building a better language, but also replacing C toolchain components: killing make/automake/cmake, replacing cc, and now replacing ld, these are huge painpoints in the C ecosystem... On the other hand maybe it's not best to think too hard of programming languages as 'competing entities'.

I have high hopes for the zz language. Especially the fact that it outputs C code. So interop is seamless.

https://github.com/zetzit/zz

For any systems language, interop with C is the litmus test.

With that in mind, this new language should not require 15,000 lines of standard library. A type-safe wrapper for libc should be enough...

> A type-safe wrapper for libc should be enough...

The standard C library is not great. There's a lot of dangerous cruft in there (gets), as well as cruft with various gotchas (sscanf; see the recent hoopla about it being linear in the length of the string even if you just want to read a fixed-length prefix). It absolutely makes sense to design new, safe, consistent libraries along with a new language.

THAT SAID, I shudder at the idea of people writing yet another library for "Hashing • encryption • key derivation • TLS • etc".

It looks very promising. I will have to play with it when I get a chance.

The syntax has a very Golang flavor and looks very clean.

A strange question though: Would those of us who are bald (like me) be eligible to contribute?

Reply on news.ycombinator.com