[HN Gopher] We are building a new systems programming language
___________________________________________________________________
We are building a new systems programming language
Author : als0
Score : 45 points
Date : 2021-03-19 17:15 UTC (5 hours ago)
(HTM) web link (drewdevault.com)
(TXT) w3m dump (drewdevault.com)
| thesuperbigfrog wrote:
| 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?
| karmakaze wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hctaw wrote:
| 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).
| pjmlp wrote:
| 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 wrote:
| That's a lot of extra keywords.
| Jtsummers wrote:
| 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).
| pjmlp wrote:
| Code is read more than written, readability matters.
| tom_mellior wrote:
| > 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.
| c-cube wrote:
| Curious to hear why this exists when Zig is further along (and
| more promising imho)
| karmakaze wrote:
| 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 wrote:
| Rust does not intend to be a replacement for C though, while
| Go does (partially).
| Zababa wrote:
| 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"?
| pjmlp wrote:
| It sure can,
|
| https://www.f-secure.com/en/consulting/foundry/usb-armory
|
| https://tinygo.org/
| Zababa wrote:
| 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.
| rhabarba wrote:
| Rust was developed to replace (parts of) C++, initially.
| C++ has a different niche than C.
| steveklabnik wrote:
| 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.
| nick_ wrote:
| Rust is a No true Scotsman of programming languages.
| mariusor wrote:
| 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 wrote:
| 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 wrote:
| I always wonder if "we" spend too much time on new
| languages and not enough on good libraries in existing
| popular languages.
| dnautics wrote:
| 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'.
| [deleted]
| jpfr wrote:
| 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...
| tom_mellior wrote:
| > 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".
___________________________________________________________________
(page generated 2021-03-19 23:03 UTC)