15 ms·

Zinc, a systems programming language prototype

136 points by birdculture 2y ago

38 2y ago
> No package manager to distract you What decade am I in? This is not optional any more. Hard pass.
- TimorousBestie 2y ago
  One of the non-goals is “to be useful to anyone,” after all. I like this language, it shares my aesthetics.
  - philomath_mn 2y ago
    It seems like the possible outcomes are: (a) nobody uses the language, so a package manager doesn't matter OR (b) people use the language, they will want to share packages, then a package manager will be bolted on (or many will, see python) Seems like first-class package manager support (a la Rust) makes the most sense to me.
- jezze 2y ago
  I am on the complete opposite side here. I detest language specific package managers for many reasons.
- kreco 2y ago
  Definitely a feature to me. I don't have to be worried that a 3rd party library without dependency begins to have 30 transitive dependencies which now can conflict with other diamond dependencies. I need my dependency tree to be small to avoid every single factor of friction. Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns).
  - imtringued 2y ago
    >Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns). Sounds like you're biased. https://archlinux.org/packages/extra/x86_64/gnome-shell/ https://archlinux.org/packages/extra/x86_64/gnome-shell/ gnome-shell > accountsservice > shadow > pam > systemd-libs > xz > bash > readline > ncurses > gcc-libs > glibc and I didn't even try finding the longest chain...
- runevault 2y ago
  Package managers are such an odd thing from a social perspective. You'll see cases like NPM and to a lesser degree Cargo where projects have hefty dependency graphs because it is so easy to just pull in one more dependency, but on the other side you have C++ that has conan and vcpkg but the opinions on them are so mixed people rely on other methods like cmake fetch package instead. I appreciate having tools that let me pull in what I need when I need it, but the dependency explosion is real and I dunno how to have one without the other.
  - nyanpasu64 2y ago
    If you require end users (and possibly libraries? IDK) to manually specify every transitive dependency of a dependency (but not hard-code/vendor it), this should act as a forcing function to reduce transitive dependency explosion in libraries (because it would degrade user experience). I'm not sure if users should have to update every dependency by hand (this discourages updates which can cause security bugs to persist, but automatic updates makes supply-chain attacks easier; AUR helpers generally diff PKGBUILDs before committing them, which partly protects against PKGBUILD but not source attacks, and even distros did not protect against the xz attack). Another factor is that updating C++ compilers/stdlib tends to break older libraries; I'm not sure if this is any less the case in Rust (unclear? I mostly get trouble with C dependencies) or Python (old Numpy does not supply wheels for newer Python, and ruamel.yaml has some errors on newer Python: https://sourceforge.net/p/ruamel-yaml/tickets/476/ https://sourceforge.net/p/ruamel-yaml/tickets/476/).
    - runevault 2y ago
      To the best of my knowledge (I only dabble in Rust) there aren't often too many breaks unless code accidentally relied on soundness bugs which Rust makes 0 promise of retaining to keep code working.
    - rcxdude 2y ago
      This is optimizing for the wrong metric, IMO. If I look at the dependency tree of a fairly hefty project in rust, mostly what I see is the same amount of code as an equivalent project in C/C++, just split into multiple packages instead of bundled up into one source tree. Which ironically means packages tend to be able to pull in the minimal amount of excess code through transitive dependencies. All that you'll do with this kind of incentive is push packages into effectively vendoring their dependencies again.
- __MatrixMan__ 2y ago
  I'd rather have my languages focus on being a language and use something non-language-specific like nix or bazel to situate the dependencies. Sure, the language maintainers will need to provide some kind of api which can be called by the more general purpose tool, but why not have it be a first class citizen instead of some kind of foo2nix adapter maintained by a totally separate group of people? There's no need to have a cozy CLI and a bespoke lockfile format and a dedicated package server when I'll be using other tools to handle those things in a non-language-specific way anyhow.
  - fc417fc802 2y ago
    A tool like Nix also makes for an end result that's far more auditable than the latest and greatest language specific package manager of the day.
- parliament32 2y ago
  Big feature for me. In frontend dev, 3k dependencies in a hello world app is considered normal. In systems, a free-for-all dependency graph is a terrible plan, especially if it's an open ecosystem. NPM, Cargo, etc are good examples. This is also why systems people will typically push back if you ask for non-official repos added to apt sources, etc.
- zifpanachr23 2y ago
  For recreational programming purposes (and sometimes professional depending on the domain), they really are a distraction. The existence of a package manager causes a social problem within the language community of excessive transitive dependencies. It makes it difficult to trust libraries and encourages bad habits. Much like Rust has memory safety benefits as a result of some choices that make it difficult to work with in some context, lack of a package manager can have benefits that make it difficult to work with in certain contexts. These are all just tradeoffs and I'm glad "no package manager" languages are still being created because I personally enjoy using them more.
jezze 2y ago
I think you have something promising there. I like that everything starts with a keyword, it makes the language feel consistant and I assume the parser is simple to understand because of it. I like that you distinguish a procedure from a function in regards to side-effects and that you support both mutable and immutable types. I like that you dont have to put a semicolon after each line but instead just use newline. I like that you don't need parenthesis for ifs and whiles, however I am not sure I like the while syntax. Maybe I need to try it a bit before I can make up my mind. On the other hand I think the type system could be expanded to support more types of different sizes. Especially if you are going for a systems programming language you want to be able to control that. I think you could have a nil type because it is handy but it would be good if the language somehow made sure that any variable that could potentially be nil has to be explicitly checked before use.
lpapez 2y ago
This looks lovely, it's so readable!
marssaxman 2y ago
I like where you're going with this. If you haven't looked into Zig's 'comptime' system, you might find some relevant inspiration there.
mamcx 2y ago
You have a lot of questions, so go to https://www.reddit.com/r/ProgrammingLanguages/ https://www.reddit.com/r/ProgrammingLanguages/ Some possible answers: > . Unfortunately I also designed a language with top-level execution and nested functions - neither of which I could come up with a good compilation model for if I wanted to preserve the single-pass, no AST, no IR design of the compiler. - This is the major PITA of C: Is an actual terrible target for transpilers that have aspirations and sophisticated features like Strings, some decent type system, or whatever. So, your option is to target something that is as close to semantics of your language (Basically, any other language that is not C), to the point where your target is MORE sophisticated than your own lang. - I think Zig (for speed/apparent simplicity) and Rust could be good targets instead of C (I wish Rust were way faster to compile!). Assuming Zig, it will simplify other aspects like cross compiling - I don't think is totally possible to avoid have a semi-interpreter for the transpiler, where you at most need a prelude with some hand-crafted functions that do the lifting. With this I mean things like `fn int(I:Int):Int'` so your code output is like `plus(int(1), int(2))`. Langs like APL/J use this for great effects and basically side-step the need for a vm/opcode. (see also: Compiling with closures)
- artemonster 2y ago
  this subreddit suffers from insufferable admins that purged any useful activity and sense of community from this sub
  - Alupis 2y ago
    Nearly all of reddit is presently political spam, and bot spam - often political bot spam. Every subreddit has to some degree been infiltrated by political spam - even subs that have absolutely nothing to do with politics. It's really unfortunate... reddit used to make me laugh - now it just makes me angry.
    - DaiPlusPlus 2y ago
      > Nearly all of reddit is presently political spam The good (or at least barely tolerable) sane politics/econ subs hide in plain sight. (Also, enn cee dee?)
wk_end 2y ago
Since you need to use a `call` statement to invoke a function, is it possible to invoke a function inside of a function call? I.e. can you write `call f(g(x))` or `call f(call g(x))` or something like that?
AlotOfReading 2y ago
One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice. For example, the term "side effects" has half a dozen different meanings in common use. A Haskell programmer wouldn't consider memory allocation to be a side effect. A realtime programmer might consider taking too long might be a side effect, hence tools like realtime sanitizer [0]. Cryptography developers often consider input-dependent timing variance a critical side effect [1]. Embedded developers often consider things like high stack usage to be a meaningful side-effect. This isn't to say that a systems language needs to support all of these different definitions, just a suggestion that any systems language should be extremely clear about the use cases it's intending to enable and the definitions it uses. [0] https://clang.llvm.org/docs/RealtimeSanitizer.html https://clang.llvm.org/docs/RealtimeSanitizer.html [1] https://www.bearssl.org/constanttime.html https://www.bearssl.org/constanttime.html
- DeathArrow 2y ago
  >One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice. I think he used side effect with a functional programming meaning. A pure function will just take immutable data and produce other immutable data without affecting state. A function which adds 1 to a number has no side effects, while a function that adds 1 to a number and prints to the console has side effects.
  - Someone 2y ago
    > A pure function will just take immutable data and produce other immutable data without affecting state But state is open for interpretation. If I write (making up syntax, attempting to be language-agnostic) fnc foo uses scalar i produces scalar does return make scalar(i + 1) end fnc One could argue that is not pure, and one would have to write fnc foo takes heap h, uses scalar i produces heap, integer does (newHeap, result) := heap.makeScalar(i + 1) return (newHeap, result) end fnc That expresses the notion that this function destroys a heap and returns a new heap that stores an additional scalar (an implementation likely would optimize that to modify the heap that got passed in, but, to some, that’s an implementation detail) > while a function that adds 1 to a number and prints to the console has side effects. Again, that’s open for interpretation. If the program cannot read what’s on the console, why would that be considered a side effect? That function also heats my apartment and contributes my electricity bill. Basic thing is: different programmers care about different things. Embedded programmers may care about minute details such as the number of cycles a function takes.
titzer 2y ago
As someone who has worked on a systems programming language for a long time, my strongest advice would be to avoid trying to make syntactic or semantic choices that are just different unless they're really motivated by making the systems aspect better, or to make the language more self-coherent. Having surprises and syntax to learn is a barrier to entry and probably won't impress anyone. That is to say, do focus on systems problems. Key ones I identified are efficient data representation, avoiding needless memory churn/bloat, and talking directly to lower-level software/hardware, like the kernel. Focus on systems programming and not on syntactic niceties or oddities.
- maxov 2y ago
  Yes, I also found the description a little weird because of the emphasis on linear-time parsing. It is cool theoretically, and it could be understandable from a perspective of "make the compiler fast", but parsing is never the bottleneck in modern compilers. For a systems programming language this seems to be the wrong emphasis.
  - Nevermark 2y ago
    Yes, I would go the opposite in terms of simplicity. Parse once for syntax and symbol definition, 2nd pass over parsed structure to link symbol references to their definitions. Two uncomplicated passes. That handles a general code graph - so the language can go anywhere, and never be fundamentally held up by limitations of early syntax/parsing decisions.
- muth02446 2y ago
  While working on my systems PL, Cwerg, I adopted a "syntax last" approach: For the longest time the syntax was just glorified s-exprs. This made it much easier to focus on the semantic choices and improved iteration times and willingness to experiment since the parser changes were always trivial. I highly recommend this approach for new PLs.
  - dontlaugh 2y ago
    The danger is you might decide to just keep the s-exprs.
higherhalf 2y ago
What makes this a "systems programming language", especially since it has "no pointers or references"?
- fc417fc802 2y ago
  Indeed, that makes it not a systems language by any definition I am familiar with. > Reasonable C interop, and probably, initial compilation to C. How do you achieve "reasonable C interop" without pointers, I wonder?
  - apgwoz 2y ago
    You cast integers to pointers and play with fire, of course!
    - fc417fc802 2y ago
      Void*? Int. Char**? Also an Int. I take it back. This is true systems programming - the same type safety that raw assembly is known for.
      - pjmlp 2y ago
        Ironically Assembly is safer than C and languages that descend from it, because although CPUs might have undefined behaviour when given undocumented opcodes, or operation modes, the CPU doesn't rewrite your code without telling you about it.
        AnimalMuppet 2y ago
        That's "safer" only against a very specific and limited set of dangers. But it opens the door to other dangers.
        fithisux 2y ago
        Yes it is. Great comment.
  - 2y ago
keyle 2y ago
TIL. I learnt about the owl parser generator. Looks decent. Anyone's experience?
boguscoder 2y ago
Is it called Zinc because zinc doesn’t easily corrode ;)?
DeathArrow 2y ago
I wish someone is inventing a systems programming language with a bit of safety but without a borrow checker. Is it even possible? Of course, having a garbage collector wouldn't qualify.
- slekker 2y ago
  I think thats Zig in the future - there's already allocators you can use that will detect some memory safety crimes
  - DeathArrow 2y ago
    Sounds great!
  - SkiFire13 2y ago
    C/C++ also have various sanitizers but they are generally not used in production. Is Zig's allocator usable in production or only while developing?
- imtringued 2y ago
  Already exists: https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references
- pjmlp 2y ago
  Something modern like Modula-2 and Object Pascal?
Joker_vD 2y ago
> The language splits side-effects from non-side-effecting code. Or rather would once functions and subroutines are implemented. Subroutines can have side-effects, functions cannot. Expressions can only apply functions, not call subroutines. It's like Haskell but better. You mean, "worse". There is a reason why e.g. Pascal only had this misfeature in its very first version and gave up on it in the Revised Report, at which point having both functions and procedures arguably became an unnecessary distinction without difference. > And there's always the issue of what to do about side-effects on module load. You execute them. Just be sure to only run them once, and maintain proper traversal order (that being post-order): e.g. if your main program has "import A; import B", and A has "import B, import C", and B has "import D", you first run D's init, then B's, then C's, then main's.
- duped 2y ago
  There's no meaningful order to shared dependencies or cyclic dependencies. You can pick one, but making it undefined is a lot more useful as the language implementer. As a language user, don't rely on order for your side effects. Actually, just don't have side effects on module load. You almost never need it. Lazily initialize your globals.
  - Joker_vD 2y ago
    > There's no meaningful order to shared dependencies or cyclic dependencies. Textual order. At least it's visible. > Lazily initialize your globals. What does that even mean? Something like that: size_t _fwrite__impl(const void* buffer, size_t size, size_t count, FILE* stream) { if (!__crt0_initialized) { _crt0(); } if (!__crt1_initialized) { _crt1(); } if (!__xfloat_initialized) { _xfloat(); } if (__stdio_initialized) { _init_stdio(); } // Actual implementation that touches internal FILE-tables and maybe does float/double formatting. } ? But why? > Actually, just don't have side effects on module load. You almost never need it. See above. There is a surprising amount of invisibly initialized global state in e.g. C runtime library.
    - 2y ago
Cerium 2y ago
It's called zinc because you are avoiding rust?
- vram22 2y ago
  I wonder if there are PLs named after metals, or even other elements of the periodic table, other than Zinc, Carbon and Mercury? :)
  - SkiFire13 2y ago
    Not a metal/element but there's Ruby
    - fuzztester 2y ago
      Good one, close. I used Ruby in the Web 2 days in a few dotcom projects.
    - vram22 2y ago
      Crystal too.
moomin 2y ago
Is it just me or is this sounding quite like BCPL?
fithisux 2y ago
Why not create an improved HLA - MASM? What You See is What Is Executed easy back and forth to assembly + inline assembly.
DeathMetal3000 2y ago
Starting a new language with header files (.h)? No thanks. I’d rather leave the 70s behind.

136 points by birdculture 2y ago

38 2y ago

> No package manager to distract you What decade am I in? This is not optional any more. Hard pass.

TimorousBestie 2y ago
One of the non-goals is “to be useful to anyone,” after all. I like this language, it shares my aesthetics.
- philomath_mn 2y ago
  It seems like the possible outcomes are: (a) nobody uses the language, so a package manager doesn't matter OR (b) people use the language, they will want to share packages, then a package manager will be bolted on (or many will, see python) Seems like first-class package manager support (a la Rust) makes the most sense to me.
jezze 2y ago
I am on the complete opposite side here. I detest language specific package managers for many reasons.
kreco 2y ago
Definitely a feature to me. I don't have to be worried that a 3rd party library without dependency begins to have 30 transitive dependencies which now can conflict with other diamond dependencies. I need my dependency tree to be small to avoid every single factor of friction. Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns).
- imtringued 2y ago
  >Language specific package manager is exactly what encourage the exponential explosion of packages leading to dependency hell (and lead to major security concerns). Sounds like you're biased. https://archlinux.org/packages/extra/x86_64/gnome-shell/ https://archlinux.org/packages/extra/x86_64/gnome-shell/ gnome-shell > accountsservice > shadow > pam > systemd-libs > xz > bash > readline > ncurses > gcc-libs > glibc and I didn't even try finding the longest chain...
runevault 2y ago
Package managers are such an odd thing from a social perspective. You'll see cases like NPM and to a lesser degree Cargo where projects have hefty dependency graphs because it is so easy to just pull in one more dependency, but on the other side you have C++ that has conan and vcpkg but the opinions on them are so mixed people rely on other methods like cmake fetch package instead. I appreciate having tools that let me pull in what I need when I need it, but the dependency explosion is real and I dunno how to have one without the other.
- nyanpasu64 2y ago
  If you require end users (and possibly libraries? IDK) to manually specify every transitive dependency of a dependency (but not hard-code/vendor it), this should act as a forcing function to reduce transitive dependency explosion in libraries (because it would degrade user experience). I'm not sure if users should have to update every dependency by hand (this discourages updates which can cause security bugs to persist, but automatic updates makes supply-chain attacks easier; AUR helpers generally diff PKGBUILDs before committing them, which partly protects against PKGBUILD but not source attacks, and even distros did not protect against the xz attack). Another factor is that updating C++ compilers/stdlib tends to break older libraries; I'm not sure if this is any less the case in Rust (unclear? I mostly get trouble with C dependencies) or Python (old Numpy does not supply wheels for newer Python, and ruamel.yaml has some errors on newer Python: https://sourceforge.net/p/ruamel-yaml/tickets/476/ https://sourceforge.net/p/ruamel-yaml/tickets/476/).
  - runevault 2y ago
    To the best of my knowledge (I only dabble in Rust) there aren't often too many breaks unless code accidentally relied on soundness bugs which Rust makes 0 promise of retaining to keep code working.
  - rcxdude 2y ago
    This is optimizing for the wrong metric, IMO. If I look at the dependency tree of a fairly hefty project in rust, mostly what I see is the same amount of code as an equivalent project in C/C++, just split into multiple packages instead of bundled up into one source tree. Which ironically means packages tend to be able to pull in the minimal amount of excess code through transitive dependencies. All that you'll do with this kind of incentive is push packages into effectively vendoring their dependencies again.
__MatrixMan__ 2y ago
I'd rather have my languages focus on being a language and use something non-language-specific like nix or bazel to situate the dependencies. Sure, the language maintainers will need to provide some kind of api which can be called by the more general purpose tool, but why not have it be a first class citizen instead of some kind of foo2nix adapter maintained by a totally separate group of people? There's no need to have a cozy CLI and a bespoke lockfile format and a dedicated package server when I'll be using other tools to handle those things in a non-language-specific way anyhow.
- fc417fc802 2y ago
  A tool like Nix also makes for an end result that's far more auditable than the latest and greatest language specific package manager of the day.
parliament32 2y ago
Big feature for me. In frontend dev, 3k dependencies in a hello world app is considered normal. In systems, a free-for-all dependency graph is a terrible plan, especially if it's an open ecosystem. NPM, Cargo, etc are good examples. This is also why systems people will typically push back if you ask for non-official repos added to apt sources, etc.
zifpanachr23 2y ago
For recreational programming purposes (and sometimes professional depending on the domain), they really are a distraction. The existence of a package manager causes a social problem within the language community of excessive transitive dependencies. It makes it difficult to trust libraries and encourages bad habits. Much like Rust has memory safety benefits as a result of some choices that make it difficult to work with in some context, lack of a package manager can have benefits that make it difficult to work with in certain contexts. These are all just tradeoffs and I'm glad "no package manager" languages are still being created because I personally enjoy using them more.

jezze 2y ago

I think you have something promising there. I like that everything starts with a keyword, it makes the language feel consistant and I assume the parser is simple to understand because of it. I like that you distinguish a procedure from a function in regards to side-effects and that you support both mutable and immutable types. I like that you dont have to put a semicolon after each line but instead just use newline. I like that you don't need parenthesis for ifs and whiles, however I am not sure I like the while syntax. Maybe I need to try it a bit before I can make up my mind. On the other hand I think the type system could be expanded to support more types of different sizes. Especially if you are going for a systems programming language you want to be able to control that. I think you could have a nil type because it is handy but it would be good if the language somehow made sure that any variable that could potentially be nil has to be explicitly checked before use.

lpapez 2y ago

This looks lovely, it's so readable!

marssaxman 2y ago

I like where you're going with this. If you haven't looked into Zig's 'comptime' system, you might find some relevant inspiration there.

mamcx 2y ago

You have a lot of questions, so go to https://www.reddit.com/r/ProgrammingLanguages/ https://www.reddit.com/r/ProgrammingLanguages/ Some possible answers: > . Unfortunately I also designed a language with top-level execution and nested functions - neither of which I could come up with a good compilation model for if I wanted to preserve the single-pass, no AST, no IR design of the compiler. - This is the major PITA of C: Is an actual terrible target for transpilers that have aspirations and sophisticated features like Strings, some decent type system, or whatever. So, your option is to target something that is as close to semantics of your language (Basically, any other language that is not C), to the point where your target is MORE sophisticated than your own lang. - I think Zig (for speed/apparent simplicity) and Rust could be good targets instead of C (I wish Rust were way faster to compile!). Assuming Zig, it will simplify other aspects like cross compiling - I don't think is totally possible to avoid have a semi-interpreter for the transpiler, where you at most need a prelude with some hand-crafted functions that do the lifting. With this I mean things like `fn int(I:Int):Int'` so your code output is like `plus(int(1), int(2))`. Langs like APL/J use this for great effects and basically side-step the need for a vm/opcode. (see also: Compiling with closures)

artemonster 2y ago
this subreddit suffers from insufferable admins that purged any useful activity and sense of community from this sub
- Alupis 2y ago
  Nearly all of reddit is presently political spam, and bot spam - often political bot spam. Every subreddit has to some degree been infiltrated by political spam - even subs that have absolutely nothing to do with politics. It's really unfortunate... reddit used to make me laugh - now it just makes me angry.
  - DaiPlusPlus 2y ago
    > Nearly all of reddit is presently political spam The good (or at least barely tolerable) sane politics/econ subs hide in plain sight. (Also, enn cee dee?)

wk_end 2y ago

Since you need to use a `call` statement to invoke a function, is it possible to invoke a function inside of a function call? I.e. can you write `call f(g(x))` or `call f(call g(x))` or something like that?

AlotOfReading 2y ago

One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice. For example, the term "side effects" has half a dozen different meanings in common use. A Haskell programmer wouldn't consider memory allocation to be a side effect. A realtime programmer might consider taking too long might be a side effect, hence tools like realtime sanitizer [0]. Cryptography developers often consider input-dependent timing variance a critical side effect [1]. Embedded developers often consider things like high stack usage to be a meaningful side-effect. This isn't to say that a systems language needs to support all of these different definitions, just a suggestion that any systems language should be extremely clear about the use cases it's intending to enable and the definitions it uses. [0] https://clang.llvm.org/docs/RealtimeSanitizer.html https://clang.llvm.org/docs/RealtimeSanitizer.html [1] https://www.bearssl.org/constanttime.html https://www.bearssl.org/constanttime.html

DeathArrow 2y ago
>One of the issues with systems programming languages is that the definitions programmers use for "well-understood" terms vary wildly in actual practice. I think he used side effect with a functional programming meaning. A pure function will just take immutable data and produce other immutable data without affecting state. A function which adds 1 to a number has no side effects, while a function that adds 1 to a number and prints to the console has side effects.
- Someone 2y ago
  > A pure function will just take immutable data and produce other immutable data without affecting state But state is open for interpretation. If I write (making up syntax, attempting to be language-agnostic) fnc foo uses scalar i produces scalar does return make scalar(i + 1) end fnc One could argue that is not pure, and one would have to write fnc foo takes heap h, uses scalar i produces heap, integer does (newHeap, result) := heap.makeScalar(i + 1) return (newHeap, result) end fnc That expresses the notion that this function destroys a heap and returns a new heap that stores an additional scalar (an implementation likely would optimize that to modify the heap that got passed in, but, to some, that’s an implementation detail) > while a function that adds 1 to a number and prints to the console has side effects. Again, that’s open for interpretation. If the program cannot read what’s on the console, why would that be considered a side effect? That function also heats my apartment and contributes my electricity bill. Basic thing is: different programmers care about different things. Embedded programmers may care about minute details such as the number of cycles a function takes.

titzer 2y ago

As someone who has worked on a systems programming language for a long time, my strongest advice would be to avoid trying to make syntactic or semantic choices that are just different unless they're really motivated by making the systems aspect better, or to make the language more self-coherent. Having surprises and syntax to learn is a barrier to entry and probably won't impress anyone. That is to say, do focus on systems problems. Key ones I identified are efficient data representation, avoiding needless memory churn/bloat, and talking directly to lower-level software/hardware, like the kernel. Focus on systems programming and not on syntactic niceties or oddities.

maxov 2y ago
Yes, I also found the description a little weird because of the emphasis on linear-time parsing. It is cool theoretically, and it could be understandable from a perspective of "make the compiler fast", but parsing is never the bottleneck in modern compilers. For a systems programming language this seems to be the wrong emphasis.
- Nevermark 2y ago
  Yes, I would go the opposite in terms of simplicity. Parse once for syntax and symbol definition, 2nd pass over parsed structure to link symbol references to their definitions. Two uncomplicated passes. That handles a general code graph - so the language can go anywhere, and never be fundamentally held up by limitations of early syntax/parsing decisions.
muth02446 2y ago
While working on my systems PL, Cwerg, I adopted a "syntax last" approach: For the longest time the syntax was just glorified s-exprs. This made it much easier to focus on the semantic choices and improved iteration times and willingness to experiment since the parser changes were always trivial. I highly recommend this approach for new PLs.
- dontlaugh 2y ago
  The danger is you might decide to just keep the s-exprs.

higherhalf 2y ago

What makes this a "systems programming language", especially since it has "no pointers or references"?

fc417fc802 2y ago
Indeed, that makes it not a systems language by any definition I am familiar with. > Reasonable C interop, and probably, initial compilation to C. How do you achieve "reasonable C interop" without pointers, I wonder?
- apgwoz 2y ago
  You cast integers to pointers and play with fire, of course!
  - fc417fc802 2y ago
    Void*? Int. Char**? Also an Int. I take it back. This is true systems programming - the same type safety that raw assembly is known for.
    - pjmlp 2y ago
      Ironically Assembly is safer than C and languages that descend from it, because although CPUs might have undefined behaviour when given undocumented opcodes, or operation modes, the CPU doesn't rewrite your code without telling you about it.
      - AnimalMuppet 2y ago
        That's "safer" only against a very specific and limited set of dangers. But it opens the door to other dangers.
      - fithisux 2y ago
        Yes it is. Great comment.
- 2y ago

keyle 2y ago

TIL. I learnt about the owl parser generator. Looks decent. Anyone's experience?

boguscoder 2y ago

Is it called Zinc because zinc doesn’t easily corrode ;)?

DeathArrow 2y ago

I wish someone is inventing a systems programming language with a bit of safety but without a borrow checker. Is it even possible? Of course, having a garbage collector wouldn't qualify.

slekker 2y ago
I think thats Zig in the future - there's already allocators you can use that will detect some memory safety crimes
- DeathArrow 2y ago
  Sounds great!
- SkiFire13 2y ago
  C/C++ also have various sanitizers but they are generally not used in production. Is Zig's allocator usable in production or only while developing?
imtringued 2y ago
Already exists: https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references
pjmlp 2y ago
Something modern like Modula-2 and Object Pascal?

Joker_vD 2y ago

> The language splits side-effects from non-side-effecting code. Or rather would once functions and subroutines are implemented. Subroutines can have side-effects, functions cannot. Expressions can only apply functions, not call subroutines. It's like Haskell but better. You mean, "worse". There is a reason why e.g. Pascal only had this misfeature in its very first version and gave up on it in the Revised Report, at which point having both functions and procedures arguably became an unnecessary distinction without difference. > And there's always the issue of what to do about side-effects on module load. You execute them. Just be sure to only run them once, and maintain proper traversal order (that being post-order): e.g. if your main program has "import A; import B", and A has "import B, import C", and B has "import D", you first run D's init, then B's, then C's, then main's.

duped 2y ago
There's no meaningful order to shared dependencies or cyclic dependencies. You can pick one, but making it undefined is a lot more useful as the language implementer. As a language user, don't rely on order for your side effects. Actually, just don't have side effects on module load. You almost never need it. Lazily initialize your globals.
- Joker_vD 2y ago
  > There's no meaningful order to shared dependencies or cyclic dependencies. Textual order. At least it's visible. > Lazily initialize your globals. What does that even mean? Something like that: size_t _fwrite__impl(const void* buffer, size_t size, size_t count, FILE* stream) { if (!__crt0_initialized) { _crt0(); } if (!__crt1_initialized) { _crt1(); } if (!__xfloat_initialized) { _xfloat(); } if (__stdio_initialized) { _init_stdio(); } // Actual implementation that touches internal FILE-tables and maybe does float/double formatting. } ? But why? > Actually, just don't have side effects on module load. You almost never need it. See above. There is a surprising amount of invisibly initialized global state in e.g. C runtime library.
  - 2y ago

Cerium 2y ago

It's called zinc because you are avoiding rust?

vram22 2y ago
I wonder if there are PLs named after metals, or even other elements of the periodic table, other than Zinc, Carbon and Mercury? :)
- SkiFire13 2y ago
  Not a metal/element but there's Ruby
  - fuzztester 2y ago
    Good one, close. I used Ruby in the Web 2 days in a few dotcom projects.
  - vram22 2y ago
    Crystal too.

moomin 2y ago

Is it just me or is this sounding quite like BCPL?

fithisux 2y ago

Why not create an improved HLA - MASM? What You See is What Is Executed easy back and forth to assembly + inline assembly.

DeathMetal3000 2y ago

Starting a new language with header files (.h)? No thanks. I’d rather leave the 70s behind.