Hacker News new | past | comments | ask | show | jobs | submit login

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might each be better than c as a language-that-you-use-for-everything, but for a given use a 'lighter' language like python is frequently even better. And it gets to the point where the only languages that allow you to program anything (lisp and perl6, really) are garbage collected and have heavy runtimes, so they won't be taking over games or the os.

C might die, but there's no replacing it. Sorry.

I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers the barrier significantly.

The hard part is build tool compatibility but I think there are a lot of good ideas being worked on actively, Zig and Rust being two examples of advanced programatic control over the build process. With a reasonable linker, it should be possible to combine these and more languages today.

An interesting counter example to the binary interface compatibility story has been Go, which seems to let cgo become less and less functional in each release. The pressure to keep everything in Go is an interesting trade-off. I wonder if certain kinds of systems will be paying for this lock-in later down the line while other languages give much easier ways to gradually evolve and reuse code or adopt libraries from multiple communities removing the need to do yet-another-rewrite in language X kinds of projects. Or perhaps this kind of interoperation is overrated? Time will tell.

> The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions)

That already works, not a hypothetical. I can write, right now, a zig function, call it from rust, slap the whole thing into a library and wrap it with d. It hasn't taken the world by storm because these languages provide support the system c abi and calling convention, but do not embrace it. If I write a fancy templated function in zig, d, or rust, the name mangling, type-information, templating, maybe even call conventions -- are all different. This is why I have been and continue to be disappointed that things like COM or the jvm or cli aren't more popular, because they actually work that way. I can write, right now a clojure function, call it from java and then pass it into kotlin. Effortlessly, it's just an import away. Sure there are, for example, stdlib conflicts in scala but overall it's a much more frictionless experience. The problem? COM is windows-specific, jvm and cli are managed runtimes and people don't like managed runtimes.

Another place I look for a solution is racket, but again it wants to manage too much of the runtime to be practical. What zig is doing with the build system is great, the fact that the build script is actually a fully customizable script means it has a much better chance of taking off, but until I can import a jai module from d and call it in zig, we're gonna have problems.

EDIT: something which possibly almost could have had a good chance of pulling this off is llvm. Except that llvm comes too late in the compilation process to be used to resolve imports and symbols. Something like libclang, maybe, except not specific to c and c++.

Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.

C also has a runtime, that is what takes care of calling main(), handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ...

Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.

The operative word here is managed runtime. Jvm wants to completely own your program, heart and soul. You can also write freestanding code in c (and rust, d, zig I assume although I don't know enough about it). I believe there is a dialect of c# that allows you to write freestanding code, but it's not really c# so much as c#-flavoured c with some extra features, so it's inferior to other c alternatives.

As for type safe system languages, ada?

I feel much of the negativity that you like to express towards C is unwarranted. Fact is, it's both very easy and efficient to interface with "C" or more specifically, platforms' standard ABIs.

On platforms written in C.

As for the negativity, Morris worm is now 30 years old and the CVE database gets C derived exploits every month.

You can interface with Object Pascal (which you frequently advertise) just fine.

(That doesn't make Object Pascal a practical language, though).


Another fact is, startup times alone make JVM impractical for many endeavours. For each task an appropriate tool I'll say.

That Quora post is really only relevant when using Java applets. If you're running a local program, you're faced with similar vulnerabilities as with any other language with a managed runtime. Still doesn't make it relevant as a competitor to C or C++.

JVM startup times are only an issue for those that don't want to buy a commercial JDK with AOT compiler support.

Good news, now OpenJDK and GraalVM offer it for free, gratis.

Object Pascal/Delphi is quite pratical on Windows.

> Object Pascal/Delphi

It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times.

On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings, 101 different dynamic arrays, and about 5 (really) incompatible object models with different kinds of memory management. Programmers with many years in the language don't really understand all the ways memory is managed in this language.

Now try writing something on top of the broken RTTI for that. Even official guides basically concede the fact by writing quirky code that easily breaks.

Also you have to declare typealiases for every little thing like pointer-to-types, before you can use that type in a function signature. This alone renders it almost completely unusable for my purposes.

It has a culture of goto-considered-harmful where people like to indent 13 times instead of using return/continue/break, which would yield readable control flow. If you want to return something, you need to write two lines - assigning to the result and calling exit(). You can't call exit() though when the current class has a method called exit(), since that method is closer in scope (REALLY REALLY WEIRD).

I know what I'm talking about. I've been paid to work in it, and refactored a subsystem written in idiomatic Delphi to be halfway maintainable, achieving real speedups of 100-1000x by following a straightforward "data-oriented" approach, just like I would write it in C, writing complicated code only where the straightforward approach was not feasible in the language. Despite completing the project successfully (there hasn't been a single problem since the rewrite), in the end I was burnt out due to having to work with the original code. Didn't work for 5 months afterwards.

Ah, one of those USENET posts.

Except for when I write Assembly, the last time I used raw goto on an high level language, my MS-DOS 5.0 box was still relatively new.

System.exit was always a thing to avoid namespace clashes and since Delphi 2009, you could have used System.exit(value) instead. Next time better read the docs.

Regarding strings, you mean like 8 bit, 16 bit, wchar_t, DBCS, GString and many others used across C libraries?

Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.

> System.exit was always a thing

Do you suggest I should use System.exit everywhere (even though all the code you find on the net uses just "exit")? Just to be sure that Delphi will never ever choose the wrong function to call WHICH IT SHOULD NEVER HAVE DONE IN THE FIRST PLACE OMG IT'S TOO FRIGGING COMPLICATED PLEASE DELPHI APPLY SOME COMMON SENSE.

It's beyond me why I should write a function call and incur symbol resolution for such basic control flow in the first place.

> the last time I used raw goto

I was mainly speaking about return, break, continue, which don't seem to be popular in Delphi. Examples of Delphi code that isn't a messy nesting fest? As for goto, there are perfectly valid uses for it, in fact some where goto is the clearest and most maintainable choice when you simply skip downwards over a chunk of code without requiring an extra flag.

> Regarding strings

I'm talking about the culture. The culture around C is not one that makes anti-modular "abstractions" (at least if you stay away from MS). You will never see me using wchar_t, GString or any of that god-awful Microsoft string mess. I get along just fine with only char. In fact, the string handling I get by using C is the most painless, most modular I've ever gotten in any language. (No, I don't want to use split() or use any other high-level stuff that would do allocations when that isn't necessary).

In Delphi, different story. Everything you find in this culture is built around String and AnsiString and UnicodeString and WideString and what not. Try googling how to access command-line parameters. The stuff is pervasive. Entirely different story.

> Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.

Exactly, typealiases are bad. And now explain to me why Delphi forces me to make a type alias (for use in function signatures) when that is worse than immediate Pointer syntax in every conceivable aspect? (Having written a compiler I know the answer: because it requires less code in the compiler to check for type equality).

So I guess I should just avoid pointers altogether and use only GC'ed boxed OOP NOMINAL types. And finally have some time for coffee again while my application takes 5-10 minutes to start up (as it did before I reworked the thing), instead of 1 sec.


I could go on, but I don't miss the bygone USENET C vs Pascal flamewars, so let's leave it here.

COM is not windows specific any more! Or rather there is a portable COM-like thing which looks like a good fit for cross language development https://github.com/Microsoft/xlang

It's from the team who delivered cppwinrt (aka moderncpp). So the C++ projection doesn't have all the nasty baggage one usually associates with COM. https://msdn.microsoft.com/en-us/magazine/mt745094.aspx?f=25...

On build processes, it's surprising to me that the Rust community hasn't developed its own linker. I suppose LD works fine.

On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI.

Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate.

Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.


Assuming with COM/UWP you mean "UWP's flavor of COM" instead of "COM and/or UWP", is anyone actually using that outside of mobile trash and game engine backends for XB1?

All the Windows software i use and see people make are either Win32 or (much more often) built on top of Win32 (well, UWP is technically also built on top of Win32, but you are supposed to ignore that and act as if it isn't the case).

Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not.

Win32 is slowly being migrated into sandbox model with each Windows 10 release and hasn't seen any big update since Vista. All major APIs introduced since then are based on COM.

I believe Windows will sooner become completely irrelevant than UWP becoming the dominant API to write Windows applications. Also seeing how MS is switching the system browser to Chromium, and kills the UWP version of MS Office, it looks like most people in Microsoft have lost faith in UWP too.

Microsoft didn't kill the UWP version, they merged it. Office is only becoming increasingly a hybrid. An increasing number of the controls are becoming UWP XAML-based.

It doesn't look like Microsoft has lost faith in UWP, only that they gained faith in UWP/Win32 hybrids (and all the complicated engineering work to make that happen), and Office seems to have helped lead the way there. For instance, Office is way more sandboxed than it has ever been before. (Office's own App-V work as far back as Office 2010 helped prototype the sandboxing approach Microsoft is applying to all of Win32 with the now focused opt-in MSIX installer.)

It's probably still too early to tell exactly how much UWP Microsoft will add to their Chromium mix, but there's already some bits there. For instance, the Chromium-based Edge still supports Netflix because they already integrated a UWP Island to (UWP API) Windows Media Foundation to support hardware-accelerated PlayReady DRM.

Based on previous history, chances are Microsoft will first abandon UWP (but leave its zombified corpse in Windows for backwards compatibility) and introducing something new-but-incompatible-with-anything-existing before Windows become irrelevant. Actually, they might do this 2-3 times before that.

What?!? Office was the team driving the new UWP Fluent components and happy early adopters of the new C++/WinRT framework and XAML Islands on Win32.

The year of desktop Linux is just around the corner. /s

> Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not.

Well, i don't, but my two main gripes is that it seems to be an evolution of WPF which i never liked and that it is tied to a more locked down mobile-like approach that i abhor.

> Win32 is slowly being migrated into sandbox model with each Windows 10 release

What are you talking about?

> and hasn't seen any big update since Vista.

I'd say that it hasn't seen any big update since Windows 98 :-P but as long as it works i do not care.

> All major APIs introduced since then are based on COM.


I am talking about MSIX and the sandbox evolution model from Project Centiped, with the new Win32 project format for store deployments.

Based on COM, and UWP, which is nothing more than a saner COM, now being internally widespread via C++/WinRT adoption.

That is for store stuff though, not Win32 itself and the vast majority of applications are not written for the store nor distributed through it (some do use it as a secondary means of distribution but from what i've heard the limitations are not worth it and the store itself is bad from a UX perspective).

Win32 is going into the store, that is the whole point of MSIX.

Maybe I'm a bit of a rust fanboy and a bit of a skeptic but

Zig and Jai aren't going anywhere. Zig appears to be a largely single contibutor (https://github.com/ziglang/zig/graphs/contributors the creator has < 2/3 of commits). Jai does not have a public compiler and is not likely to get a public release anytime soon.

As for rust we don't know yet how big of a chunk of marketshare it will take from new c and c++ code.

Not many people still use c code for "everything", most have already switched.

What is the actual argument that you support with pointing out that Zig is "largely single contributor"? Linux was largely a single contributor up to a point.

There is nothing wrong with single contributor languages. But for every C there are thousands of flatlined github repositories of single contributor languages. Building a language is a marathon, not a sprint. It takes years and years to grow something worthwhile, and this requires a lot of persistence. In the meantime, technical challenges, finances, family, and even busses get in the way of languages being fully realized. Having a team rather than a BDFL increase the chances of a language flourishing and persisting.

Fun fact, I'm also training for a marathon! https://twitter.com/andy_kelley/status/1109906861241847816

There are 8 people on the Zig team, all with significant contributions and deep understanding of the project. https://github.com/orgs/ziglang/people

> Zig appears to be a largely single contibutor

Aside from starting Zig as his personal project, Zig is also Andrew's job now. As far as I'm aware that is not true of any other contributor, so it makes sense he'd have the lion's share of contributions.

> Zig appears to be a largely single contributor

That's a good thing. The less contributors, the better the project usually.

Rust is especially attractive because of no-GC. Systems, embedded, performance oriented projects have real reasons to adopt this language.

so does zig and jai tho..

C was largely a single contributor.

I feel like C hasn't been a "language-that-you-use-for-everything" for some time, so it's more about replacing C in the situations where C is currently a reasonable choice for new development.

C has been and continues to be a general-purpose language people use to write all kinds of things; just, fewer things are being written in it.

Just like when it was born, for C to die, UNIX has to die, that's the only reason it will be an herculean task to ever replace it.

Naïve thought of the day: What if instead of replacing c with another c-like language, there was a c library that you included in your code that overloaded operators and functions into safer ones? You would gain some of the benefits and retain the ubiquity.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact