Will Hare replace C? Or Rust? Or Zig? Or anything else?

Re:Will Hare replace C? Or Rust? Or Zig? Or anything else? by throwaway17_17 on Tuesday May 03, 2022 @12:03PM (#31249942)

I think you are correct for a large portion of this, however, I will remain hopeful for a different viewpoint winning in the end. I tend toward evaluating a language's usefulness exactly in respect to the individual using it.

I understand the network effects and 'community' benefits of large/non-fizzled languages, but I want to believe that a language that makes an individual programmer happier, more productive, better able to meet engineering goals, or whatever metric they seek to increase through choosing one language over another, is the language they should be using.

I remain hopeful for a heterogeneous approach to language usage in the future, where multiple engineers working on those applications can utilize a language which they determine is best for them. I think this could results in multiple languages which all compile to a well defined target language, via well specified semantics for the source language transformation. I know this is almost the idea behind the JVM or CLR, and is similar to many languages transpiling to C. I would like to see an environment cultivated to support this from the ground up and grow from there.

[ Parent | on HN ]

Re:Will Hare replace C? Or Rust? Or Zig? Or anything else? by ncmncm on Tuesday May 03, 2022 @02:51PM (#31252016)

Organizations would deeply resent being saddled with code in a dozen different languages for one application. When some bit of functionality straddles two parts in two different languages, they need somebody skilled in both languages to work on that. Even for a free-software project, the chief maintainer really needs to understand all the languages used in it, and the number of people skilled enough to contribute to a part will often be severely limited, if one of the languages is obscure or if it needs work in two or more.

Thus, there are very powerful organizational forces pushing for a single implementation language. A practical exception to this is that there are plenty of programs coded in a systems language providing a scripting language (e.g. gdb in C++ with Python scripting, Emacs in C with Elisp, Vim in C with Vimscript) made tolerable by the scripting language being extra-easy, very widely known, or known to all users of the program, so familiar to any contributor.

But the need to learn another language, or two or three, just to contribute to a project will turn away people not able to spare that much attention. Businesses would need to pay for the time all the developers need to learn all the languages. And, languages will be at multiple levels of maturity and stability. What do you do when 10% of your system is coded in a now unmaintained language? When you want to port to a new target execution environment, does each language not ported there get to hold you hostage?

This is why languages with a wide range are attractive. C++ and Rust aim for this wide range, providing for both bit-twiddling optimization and system architecture organization. Supporting a wide range is a big burden for a language maintainer, so there will never be very many like that.

[ Parent | on HN ]