[AndyKelley]

My plan to replace C is simple and pragmatic.

1. Make a language and compiler that fills the same niche as C but does it significantly better, taking into account all the lessons we've learned in the last 44 years.

2. Make a build tool that competes with autotools, cmake, make, etc. Similar to Python build.py, you'll have a build.zig, import a library and use it. The library does everything configure/make does except better.

3. Package management on par with NPM and Cargo. Minimal overhead to publishing reusable code. Although I don't plan to have a central repository, rather the ability to put a URL or source control URL with a hash.

4. Zig can import and export .h files, and you can target .o files that are compatible with the rest of your C codebase.

5. Now there is minimal cost to replace bits and pieces of your codebase with Zig.

[paulasmuth]

All of those points sound fantastic and zig is one of the most interesting things I've seen on HN in a while.

Still I can't help but ask one question: Your points 2 and 3 (build tooling and package management) seem like they would have the biggest, immediate impact for most current c/c++ users.

Did you ever consider separating the build tooling and dependency management effort from the core language?

I, for one, would be extremely interested in sane build tooling and dependency management for c/c++ (and what you describe sounds great). I would give it a try in no time. However, I'd be much more hesitant to consider a new language for a serious project. Even if the language is tip top, I would still be concerned if it is likely too be around and still relevant in X years. I think build tooling has less of a chicken-and-egg problem to adoption because you could always switch to another tool later. And once somebody uses your build system you're already half the way there to using the full thing.

[versteegen]

Plenty of us know it can be done, and is an extremely worthwhile goal; keep up the fantastic work! Zig may be the language I've been waiting for, so I'll make it the next language I learn, although I realise it's not even reached a first release.

[ashitlerferad]

Don't forget item 6, which is quite essential:

6. Talk about Zig at conferences and promote it in other ways

[gkya]

2,3: Or just use make and use OS package managers. Don't make the users learn yet another tool.

The niche of C is Unix, which is here to stay. C is a part of Unix, it's interfaces are defined in terms of C, and plethora of libraries written in it. If a random library X is impemented in C, it is easily usable in many languages via FFIs. Programs written in C are easily portable to most popular platforms, and C knowledge is transferable from supercomputers to tiny embedded devices. C translates nicely to assembly, and it maps easily to mechanics of computing. These are the areas where languages like Zig need to penetrate.

[exDM69]

> Or just use make and use OS package managers. Don't make the users learn yet another tool.

OS package managers fulfill a different task than development package managers that are bundled with programming languages.

The OS package manager provides a consistent set of libraries that is required to run the applications that ship in the OS.

A development package manager is used to bundle all your dependencies and pin them to specific versions so the build is reliable and reproducible. This sometimes involves things like being able to have several versions of a library in your dependency graph. Or sticking to a specific older version of a library you need (because their release schedule might not align with yours).

A development package manager might also take care of the compiler/interpreter version(s) of your programming language, for languages that develop rapidly. Heck, I'd even want this for "slow moving" languages like C, where I sometimes end up requiring a recent-ish compiler version for some extensions/intrinsics I might be using.

Apart from some fundamental libraries (say, OpenSSL, Xlib, libc), you should not rely on your OS package manager if you wish to reliably and reproducibly be able to build your software. The rest you should probably link statically or bundle with your app binaries depending on how you distribute your software. If your software ends up being packaged for a distro, it's up to the package maintainers to ensure that it'll build and run with the other libs in the OS.

I do agree that it is a nuisance to have a package manager for every language, but so far no-one has stepped up to try to make a unified package manager that works with many languages.

[pjc50]

1-3 are a tremendous amount of work, especially if you want to replicate "everything" that automake does.

[IshKebab]

You don't need to replace everything that automake does. 90% of it is obsolete, and 9% only applies to weird C compilers.

[jwatte]

Automake/autoconf is terrible a and nobody really needs it these days (and, some say, never did.)

[jwatte]

Compare to the history of: - D - Jai - Rust Each of which have had a very similar pitch. How is it different this time?

[otabdeveloper1]

Points 1, 4 and 5 are exactly the same in C++ too. What makes you think you can do better than the guys who are driving C++ development? (Honest non-rhetorical question.)

Points 2 and 3 don't really belong in a programming language.

[majewsky]

To the contrary, I believe that process improvements around a programming language will be more important than bare language features going forward.

If I were to build a language, a headline feature would be a package repository that enforces best practices (e.g. it should outright refuse to publish a minor version upgrade that breaks the ABI).

[otabdeveloper1]

So what happens if you have a project that uses more than one programming language? (And what project nowadays doesn't? E.g., Python + C++ + Javascript + HTML + CSS is as simple as it gets for a larger-scale project today.)

Any 'process improvement' scheme will necessarily need to be language-agnostic to achieve popularity.