[HN Gopher] Zinc, a systems programming language prototype
___________________________________________________________________
Zinc, a systems programming language prototype
Author : birdculture
Score : 40 points
Date : 2025-03-12 19:35 UTC (3 hours ago)
(HTM) web link (sr.ht)
(TXT) w3m dump (sr.ht)
| 38 wrote:
| > No package manager to distract you
|
| What decade am I in? This is not optional any more. Hard pass.
| TimorousBestie wrote:
| One of the non-goals is "to be useful to anyone," after all.
|
| I like this language, it shares my aesthetics.
| philomath_mn wrote:
| 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 wrote:
| I am on the complete opposite side here. I detest language
| specific package managers for many reasons.
| kreco wrote:
| 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).
| runevault wrote:
| 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.
| __MatrixMan__ wrote:
| 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, but
| there's no need to have them waste their time with a cozy CLI
| and a bespoke lockfile format and a dedicated package server
| when I'll be automating the consumption of those things anyhow.
| parliament32 wrote:
| 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.
| jezze wrote:
| 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 wrote:
| This looks lovely, it's so readable!
| marssaxman wrote:
| 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 wrote:
| You have a lot of questions, so go to
| 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 wrote:
| this subreddit suffers from insufferable admins that purged any
| useful activity and sense of community from this sub
___________________________________________________________________
(page generated 2025-03-12 23:00 UTC)