[pjmlp]

That is why when comparing languages we should always look beyond grammar and semantics.

This is nothing new, it is also a reason why languages like C and C++ won the systems programming wars from the 1990's.

After a while one gets tired to write wrapper libraries, or having to pay extra for an additional compiler that isn't part of the platform SDKs.

Hence why successful languages always need some kind of killer feature, or a company with deep enough pockets willing to push it into the mainstream no matter what.

Same applies to new OS architecture ideas as well.

[int_19h]

It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block.

These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax:

https://ziglang.org/documentation/master/#Import-from-C-Head...

[pjmlp]

Yes, a lesson that TypeScript also took into account.

[dleslie]

Nim does it better, it can be used anywhere C can; zig cannot.

[kaba0]

Why wouldn’t Zig be applicable anywhere where c is applicable? Afaik it can also compile to C as a target other than the many architectures it supports.

[dleslie]

Zig did not compile to C, yet, and so is restricted to llvm's targets.

[jedisct1]

Zig's stage2 compiler has a C backend https://github.com/ziglang/zig/blob/master/src/codegen/c.zig

[dleslie]

That's not released or finished, last I checked a few weeks ago.

Edit: Oh, looks like it was released just a few days after I last checked; ha. Although, it's not clear to me whether it's intended for end-user use yet.

https://github.com/ziglang/zig/releases/tag/0.8.0

[Zababa]

I think you can compile Zig to WASM, and then it's just a matter of finding a WASM interpreter/JIT in C.

[dleslie]

... That would be terrible on, say, the Sega Genesis or 32X.

[Zababa]

As I've said somewhere else, don't think in terms of languages but in terms of use cases. Nim can make a lot of sense for some cases where C is used, and not much for others. The same is true for Zig. There is no and there will never be a "C replacement", just other options depending on what you are doing.

[FpUser]

The first thing I look when working with any language excluding shell scripts is interactive debugging from IDE.

[southerntofu]

My two cents as a non-professional programmer: i've found hacking on someone else's codebase to be very hard with/without a debugger in dynamic languages like JS/Python where most things are untyped and you get runtime exceptions upon eg. trying to call a method on a nil object.

BUT back on the thread's topic, since i started programming in Rust, the only time i've felt it was hard to wrap my head around the compiler's output was with complex async programming. Otherwise, every single time i felt like a simple text editor was more than enough with rustc's output to understand what's going on, because in Rust everything is very explicit and statically typed with clear lifetimes, and the compiler has very helpful error messages often including suggestions on how to fix the error.

For me, everything (non-async) Rust is a clear win in terms of understandability/hackability, compared to all other languages i've tried before (admittedly not a lot of them). I think complex IDE tooling can ease the pain, but proper language design can help prevent the disease in the first place.

EDIT: i should add, since i started programming in Rust, i've only once or twice seen a runtime panic (due to array indexing error on my side). Otherwise, literally all of the bugs i had written were caught by the compiler before the program ran. For me it was a huge win to spend one more hour to please the compiler in exchange for spending days less debugging stuff afterwards.

[FpUser]

While I use scripting languages when needed my main languages were always compiled with static typing. And I did not need debugger for hacking code. I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me.

I did not program in Rust so I can not really judge the language but I doubt that it is so nice and expressive comparatively to modern C++ that suddenly the types of bugs I am hunting will magically disappear.

[southerntofu]

> I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me.

Then you're a much better programmer than i am! :)

For algo debugging i just use pen and paper. For more surprising results, print statements are usually all i need.

> suddenly the types of bugs I am hunting will magically disappear

Maybe not, but i'd recommend to give it a try, if only to offer a different perspective. For me personally, strict and expressive enums, mandatory error handling and Option/Result types as language core features (among others) have definitely eliminated most bugs i write. Well i still write those bugs, but at least the compiler doesn't compile like everything is fine, and instead lets me know why my program is flawed.

[pjmlp]

And in languages that try to replace C++, better offer nice IDE tooling as well.

https://devblogs.microsoft.com/cppblog/edit-your-c-code-whil...

https://uecasts.com/courses/unreal-engine-5-introduction/epi...

With VC++ and Unreal catching up with Lucid Energize[0], others will have to up their game.

[0] - https://www.youtube.com/watch?v=pQQTScuApWk

[int_19h]

Can you give some specific examples?

[dleslie]

SH2, which lacks llvm support but has C compilers available.

[int_19h]

Oh, you mean target architectures. But stuff like SuperH is used only for embedded these days, where even C is often rather idiosyncratic. For most coders, Zig is comparable to other mainstream languages in terms of supporting mainstream platforms.

Anyway, this is really a matter of implementation, not a language issue. There's nothing about Zig that makes it inherently impossible to support SH2 or any other platform - indeed, as others have noted, they already have a C backend in the works, so the endgame is to support everything that has a C compiler.

Also, as far as C interop goes, if I remember correctly, Nim can't just take a C header and expose everything declared in it - you still have to manually redeclare the functions and types that you want in Nim, no? You can use c2nim, of course, but that's not really any different than generators for other languages, and requires extra build steps etc. Zig handles it all transparently.

[Zababa]

> Anyway, this is really a matter of implementation, not a language issue.

I think separating the two is a bit artificial. Python being slow is partially an implementation issue but the fast implementations can't run everything. When you compare languages, you have to compare implementations, otherwise it's meaningless.

[kjeetgill]

> Anyway, this is really a matter of implementation, not a language issue.

That's kind of what people are getting at in this whole conversation though isn't it, ecosystems around languages matter. They can't be an afterthought.

[davidw]

I wrote about the economics of programming languages a while back:

https://www.welton.it/articles/programming_language_economic...

[pjmlp]

Thanks for sharing, spot on.

I like the Tcl example, that is how we worked at a .com startup I was part of.

[emodendroket]

> Hence why successful languages always need some kind of killer feature, or a company with deep enough pockets willing to push it into the mainstream no matter what.

There's a third strategy: hitching your wagon to an already-successful ecosystem, like languages such as Kotlin do.

[pjmlp]

That strategy always falls apart when the ecosystem goes into a direction that the guest languages did not forsaw, or already created incompatible concepts, and then get the dilema of what to expose from the underlying ecosystem.

Using Kotlin as example, its initial selling point was Java compatibility, now it wants to be everywhere, and its Java compatibility story is also constrained for what Android Java is capable of.

So the tooling attrition increases, with KMM, wrapping FFI stuff to be called from Java like coroutines, and everything that is coming with Loom, Panama and Valhala.