5 ms·

We are building a new systems programming language

72 points by als0 6y ago

deleted 6y ago
[deleted]
c-cube 6y ago
Curious to hear why this exists when Zig is further along (and more promising imho)
- karmakaze 6y ago
  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.
  - rhabarba 6y ago
    Rust does not intend to be a replacement for C though, while Go does (partially).
    - Zababa 6y ago
      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/ 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"?
      - rhabarba 6y ago
        Rust was developed to replace (parts of) C++, initially. C++ has a different niche than C.
        steveklabnik 6y ago
        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.
      - pjmlp 6y ago
        It sure can, https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://tinygo.org/ https://tinygo.org/
        Zababa 6y ago
        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.
        mappu 6y ago
        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.
        Zababa 6y ago
        Thanks, that's something I didn't know about.
    - nick_ 6y ago
      Rust is a No true Scotsman of programming languages.
- mariusor 6y ago
  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?
  - setr 6y ago
    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.
    - hackerbrother 6y ago
      I always wonder if "we" spend too much time on new languages and not enough on good libraries in existing popular languages.
      - setr 6y ago
        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)
- dnautics 6y ago
  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'.
karmakaze 6y ago
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) {
- c-cube 6y ago
  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.
- mariusor 6y ago
  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.
  - pjmlp 6y ago
    for i := 0 to len(greetings) do and if bigger increments are desired, e.g. for i := 0 to len(greetings) step 2 do
    - mariusor 6y ago
      That's a lot of extra keywords.
      - Jtsummers 6y ago
        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).
thesuperbigfrog 6y ago
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?
jpfr 6y ago
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 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...
- tom_mellior 6y ago
  > 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".

72 points by als0 6y ago

deleted 6y ago

[deleted]

c-cube 6y ago

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

karmakaze 6y ago
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.
- rhabarba 6y ago
  Rust does not intend to be a replacement for C though, while Go does (partially).
  - Zababa 6y ago
    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/ 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"?
    - rhabarba 6y ago
      Rust was developed to replace (parts of) C++, initially. C++ has a different niche than C.
      - steveklabnik 6y ago
        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.
    - pjmlp 6y ago
      It sure can, https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory https://tinygo.org/ https://tinygo.org/
      - Zababa 6y ago
        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.
        mappu 6y ago
        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.
        Zababa 6y ago
        Thanks, that's something I didn't know about.
  - nick_ 6y ago
    Rust is a No true Scotsman of programming languages.
mariusor 6y ago
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?
- setr 6y ago
  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.
  - hackerbrother 6y ago
    I always wonder if "we" spend too much time on new languages and not enough on good libraries in existing popular languages.
    - setr 6y ago
      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)
dnautics 6y ago
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'.

karmakaze 6y ago

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) {

c-cube 6y ago
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.
mariusor 6y ago
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.
- pjmlp 6y ago
  for i := 0 to len(greetings) do and if bigger increments are desired, e.g. for i := 0 to len(greetings) step 2 do
  - mariusor 6y ago
    That's a lot of extra keywords.
    - Jtsummers 6y ago
      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).

thesuperbigfrog 6y ago

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?

jpfr 6y ago

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 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...

tom_mellior 6y ago
> 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".