I agree with what you say, except for "C coders like C to the exclusion of all else".

I doubt very much that there are many C coders who like the C language.

I had liked very much C around 1990, when I could use for the first time the Microsoft C compiler and the Borland Turbo C compiler.

Previously I did not have access to programming languages better than Cobol, Fortran, Basic or Pascal. In comparison with any of those, programming in C was much more enjoyable.

However, later, after better languages became available, I had no reason to continue to like C.

Despite that, I continue to program frequently in C, because there are still cases when it remains the best choice, for various reasons having nothing to do with the quality of the language, i.e. mainly for embedded computers or kernel drivers.

In any case, the C language will always remain on the list of languages important in the history of programming languages, independently of how many programmers happened to use C or to like it, because of a couple of valuable innovations: the "continue" statement and the distinct operators for the McCarthy "and" and "or" and for the bit string "and" and "or" (though it would have been better if single characters would have been used for McCarthy operators and double characters for the bit string operators).

(A few other innovations that are sometimes attributed to C had actually been introduced in the language B, the predecessor of C, or in the language BCPL, the predecessor of B, or in the language CPL, the predecessor of BCPL.)

> (though it would have been better if single characters would have been used for McCarthy operators and double characters for the bit string operators)

(It probably is better on net, but) not as much as one might think, actually. It's a clear win in terms of Huffman coding, but there's also a general principle that small infix operators have higher precedence, and large ones lower precedence, like how multiplication in math notation uses "·", or more often nothing at all, while addition uses "+". (It also shows up in natural languages; consider "Tom and Dick and Harry as well as Alice and Bob".) It's (probably, usually) worth subverting for assignment, because "=" is used a lot, but I'm not sure if it's a good tradeoff for boolean operators, eg:

  if(x == 3 & y == 5) foo(); // look's a bit too much like it's saying
  if(x == (3&y) == 5) foo(); // ie (x==(3&y)) & ((3&y)==5), rather than
  if((x==3) & (y==5)) foo();

Though, like "=", the initial misleading hueristic might wear off with sufficient exposure, and you can usually fudge it by adding spaces around the low-precedence operator.

Your examples would have looked much better and without suggestions of wrong precedence if C would not have also replaced the Algol operators ":=" and "=" with "=" and "==".

In my opinion this is one of the greatest mistakes of C, and which unfortunately has been inherited by too many other languages. Even Dennis Ritchie has admitted that this might have not been a good idea.

> if C would not have also replaced the Algol operators ":=" and "=" with "=" and "==".

That wouldn't help "!=" and "<=", and "=" is used far too often (in typical code, hence the "(probably, usually)" above) to be multi-character.

That is due to the limitation of the source code to ASCII, which I consider obsolete.

"!=", "<=" and the like were single-character operators in Algol and in many other early programming languages. They have been replaced with 2-character operators only because IBM and most other important US computer manufacturers were not willing to support character sets with enough characters for covering the needs of mathematics and of other languages than English.

The target for the US character sets was only the text that may appear in commercial letters written in English. For any other uses, like programming languages, characters have been accepted only when they could occupy one of the few vacant places in the character map.

The dominance of the US-made computer hardware forced this ugly limitation upon the programming languages. So the programming languages had to use various commercial characters, e.g. !, @, #, $, %, instead of more appropriate traditional mathematical symbols.

Now, with Unicode and UTF-8, I consider the use of ASCII for source code as stupid.

In Unicode, also the ":=" of Algol exists as a single character.

Regardless of how operators are encoded, as single- or multiple-characters, a good text editor for source code allows one to change the correspondence between pressed keys and the inserted text.

Because assignment is used more frequently, even when using ASCII a text editor can be configured to insert ":=" when you press "=", and, for example, to insert "=" for ctrl-= and "!=" for alt-=, in order to minimize key presses.

Many early programming languages were even more limited than ASCII itself, for the sake of portability. In Algol itself the operators and keywords were defined as abstract representations, with multiple possible ways of serializing those to computer-encoded text.

Agree.

It seems like it would ne more accurate to say that each C role is has skipped other languages, and thus will likely skip Hare as well. The feelings of people in that role might not have anything to do with it.

It is hard to find anyplace where you may have C but not C++. Do people still use PICs? I think 32-bit ARM chips may be had for 3 cents nowadays. For a really memory-constrained target, you might choose to turn off exception support.

They do, but personally I would be pushing for Pascal in such cases.

https://www.mikroe.com/mikropascal

Pascal lacks destructors and templates. No dice.

True, although in the context of PIC programming hardly matters.

For me no dice is being unsafe by default.

Thankfully in the context of C++ I could always fix, what from my point of view, are bad defaults regarding bounds checking.

Pascal is unsafe by default: it allows null pointers, and stale pointers.

True, but it has a much safer story than C in everything else.

C++ was attractive to me in 1993, because it offered me the safety, and modern language features I was used from Turbo Pascal and then some.

They exist, even to detriment of modern C, C89 + language extensions of their favourite embedded compiler is all they care about.

Zig is kinda awesome though, i'm not even sure what the C community thinks needing improvement with Zig, i often only hear praise with Zig.

Mind you i don't know, i like Rust - but i'm not a C-like programmer and don't want to be. But, nevertheless my opinion of Zig seems quite high. It seems Zig is the benchmark in this space.

One of the more interesting use cases I have seen for niche compiled languages is malware development. When the binary is a sort of martian to the AV scanning engines, it flies under those radars.

There's even old languages dug up for this purpose. Most pascal I have seen lately is malware samples.

Oh the woes with that. Try maintaining a legacy VB6 app. The cobol of the 90s. If you never worked in this field, you won't believe how many VB6 apps are still out in the wild, sometimes the glue keeping everything together for a multi million dollar company.

Write any trivial program in vb6 and upload it to virus total. Red alert left and right. Even Windows Defender of all things goes off for anything a little more involved. Sometimes only a couple of days after you did the initial scan. Signing the binary helps, but is no silver bullet, and sometimes companies still can't be arsed. There's an endless thread in the last remaining forum about vb6 where people try to figure out what increases chances of detection, and it mostly reads like cargo culting.

Given how much malware was written targeting the fact that you could embed it in something like a spreadsheet with full access to windows API stuff it was doomed to suffer eventually like that. The entire security model was non-existent and it just opened up such a can of worms. The funny thing is how unlikely it is someone will get hit with working malware written in vb6 today because of AV engines and how easy it is to slip under the radar just doing it in go or whatever

Given the languages all produce native instructions which then do the same job, is there really a huge difference for malware scanners? They for sure wouldn't look at debug symbols, and hope malware authors were kind enough to include them.

Weird ABIs can certainly screw up automated malware analysis, but (AFAICT) Hare doesn't have a particularly weird ABI (I believe they're aiming for low-overhead interoperability with C, which precludes completely alien ABIs like Go's).

That being said: automated malware analysis is of dubious efficacy and flexibility to begin with, so who knows.

> Hare aims to be successful within its niche for the programmers that find its ideas compelling, and nothing further. If you are using and enjoying C, C++, Rust, Zig, or any other language, and don’t find Hare’s ideas all that interesting, then I encourage you to keep using these languages.

I think they DON'T want to compete with any language nor attract C/C++/Rust/Zig/Nim/Forth/<name_your_language_here> coders.

So why does it exist?

Why not? They are not forcing you to use it.. If you don't like it, how hard can it be for you to ignore it?

Why coders code?

I'd like to know, too!

From my point of view, all languages which don't add anything new and improved are a drag on our collective computing experience.

I'd be happy if humanity had like three or four programming languages: Idris or some other better-Haskell (for guarantees), Lisp (for simplicity), Rust (for performance), and probably one or two other languages which are unique enough, Prolog or something, K?

> From my point of view, all languages which don't add anything new and improved are a drag on our collective computing experience.

I couldn't disagree more. The more people writing languages and implementing standard libraries the better.

Are these minor languages going to be used in production? An even smaller minority of them, sure.

For the majority of them it's a chance for developers to relearn data structures and algorithms and compilers. Real, hands-on practice that is hard to beat with any other method. I only got decent at algorithms and data structures by implementing languages and standard libraries.

I'd rather every developer built their own language.

I agree with everything you wrote! And yet... the endless myriad of programming languages which don't bring anything particularly new is still annoying me. Perhaps I'm just getting old :)

I think it exists largely because Drew DeVault likes making his own things from scratch and also because other people like his opinionated software development. People wouldn't throw him money for stuff like sourcehut otherwise.

> [A]ll languages which don't add anything new and improved are a drag on our collective computing experience.

If people weren't experimenting with weird esoteric languages, how would we have gotten any of the languages you list here? If I'm recalling correctly, K is descended from APL, a language you needed a special keyboard even to use. Rust synthesizes ideas from lots of small academic languages no one will ever ship software on.

I'm not against esoteric languages at all! (as long as they bring something conceptually new/different :)

I guess my main gripe is the duplication of effort: same thing with a slightly different spin, the time wasted learning different libraries doing fundamentally the same thing, etc.

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.

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.

People don't just use C because it is the most fun to program in but because it offers a unique set of trade offs that no other language (even most C-replacements) hits.

It is based on a stable standard.

It is extremely portable and not in a target major platforms way - that is much better done in other languages - but in a being able to run on nearly every OS and hardware in existence. You can feasible port your C software to you weird hobby operating system.

It is simple enough that you could write your own compiler or at least something to bootstrap a proper one.

It is the Latin of programming languages. It is the common, cultural core we have. Nearly all bigger languages have some way to interact with C. If you want to write a library that can be easily used from any language, C is the way to go.

It is (relatively) fast too compile and creates binaries of minimal size that run at maximal performance. (Yes, you do make trade-offs in some of these aspects when using Rust or C++. Those trade-offs are worth it in many cases but let's don't pretend they don't exist. C serves as a performance gold standard for a reason.)

Yes, it is also a horrible language is many ways and should not be used for most projecs but the advantages can make all the difference for certain use cases. For projects like SQLite or Lua it was for sure the right choice to use C.

SQLite and Lua could have been coded in C++ with no downside. They could be coded in Rust with some loss of portability, but nowadays anywhere you can compile C, you can compile C++. There is no difficulty whatsoever in exposing a C API from a library coded in C++.

The point is not whether they could, they absolutely could but whether C++ or Rust would have been a better fit considering the values that these projects have.

Just because you don't care about the downsides does not mean there are no there. First of all, which subset of C++ should be used? It is a huge language that only very few people can claim to master. So lot's of people wouldn't be able to understand or change the code anymore. That is quite the significant downside.

Not to mention all the other downsides mentioned in my other post, like being slower to compile, bigger binary and so on. Yes, those downsides might not matter to you and should not matter for many projects but they do exists.

C programmer often care more about building the best possible software not so much about having the best possible development experience while building.

That said, Rust has much better safety guarantees, so it DOES offer some significant upside that C can't.For more complex software it is is definitely a very good choice.

Now you appear to be parroting things you read somewhere. The statements bear only a tenuous connection to reality.

What exactly do you take offense with?

I do have experience using both C and Rust. Arguably, my C++ is very limited but things like C++ being a relatively large language are well established facts and quite uncontroversial.

There is no disagreement on what "subset of C++" is best: anywhere you have a choice, use the newest method supported on your compiler, because nothing is added to the language without compelling reasons.

It is true that some people resist using anything introduced since they first learned, with a few mired in C. But there is never any need to "agree" on that.

"Bigger binary" is scurrilous propaganda. Compilers nowadays use the same code generator for C and C++: say the same thing, get the same code. Furthermore, optimizers have to guess less at you are trying to do, in C++, so can do a better job. C++ code for the same task is often smaller.

"C programmers often care more about building the best possible software": this is just crude slander.

Finally: "Rust has much better safety guarantees": C++ offers much the same guarantees, where you choose to exercise them.

> C coders like C to the exclusion of all else, or they would have abandoned it long ago. Hare will not be picking up any substantial number of C coders.

I agree. And for that matter, see a lot of the same for Zig too. Hardcore C coders have learned to live with it or have incurable Stockholm syndrome and stay despite of the situation.

I believe it's really a matter of programmers who are newer (younger), casual, or part-time at it (like various people in IT or security) that are looking for more convenient alternatives. In that case, things are more wide open. They could pick Go, Odin, Vlang, Hare... just as easily as they could pick up Zig. There are many "better C" alternatives vying for position. It could shift so easily.

As for Nim, I think they have a certain level of guaranteed "lock-in" for being so Python-like and seen as an alternative to it. How far that will take them, remains to be seen. Same for Rust, they have "safety" to play on, and the backing of Mozilla that added wind to their sails.

> The normal fate of any new language, absent The Miracle, is to fizzle. It is the certain fate of any language that brings nothing compelling to the table.

True.

Hare is C without macros and with added namespaces. Oh, and tagged unions.

With just that, I'd say it's a win in my book. Not mentioning actual, useful strings.

That's besides the point parent tried to make.

Parent was very critical of this very new language.

I just pointed a couple of it's good sides, that make it worthwhile for myself to eventually learn.

I'm not sure it's true that C programmers usually like C? I'm writing C++ code because that's what the Arduino ecosystem uses. It's hardly my favorite language.

It seems like a lot of people choose languages due to ecosystem constraints?

Anywhere the choice of language is constrained like that, by definition the niche language will not be a viable alternative.

> C coders like C to the exclusion of all else, or they would have abandoned it long ago.

Those irrational people seem to have code that doesn't require rewrites/refactoring every few years. Switching to an entirely new ecosystem as a primary field? I leave it to the beta-testers, perhaps in 10 years Zig/Rust/Nim will be standardized languages with multiple compilers and big ecosystems supporting them, just like C and polished enough to be as easy as C to write.

You're not wrong, but I don't think they want to compete with those other languages.

> Part of our work in developing Hare is laying the groundwork for a collaborative, productive, healthy community that people want to work in, ...

Maybe that's enough? It's okay to be a niche, even toy, language. The community is the "feature" that makes it compelling, eh? Like how Gemini doesn't compete with WWW, or indeed how Sr.ht is not exactly a competitor to GitHub, but still has its value.

He certainly does want to compete. He just doesn't want people making fair comparisons.

> He certainly does want to compete.

In what sense? I mean, he's not entering contests with it? (Forgive me for being dense.)

> He just doesn't want people making fair comparisons.

I dunno, I feel like he's been pretty up front about where Hare is different (not to say inferior) to other languages. (I should mention that I'm generally pro-ddevault even though I don't agree with everything he's into. (E.g. I'm not on the Graph DB bandwagon (yet?).)

FWIW, I see Hare as a fun toy (a toy that can do real work through, to be sure.) As long as it and the ecosystem around it can attract people to work/play with it then it doesn't need to compete. (Except in the general sense of competing for time and attention with everything else.)

Very much. C coders think that C++ is not mainstream or mature enough :)

C coders, as a rule, don't think very much about languages, or they would not still be coding C. You see proof of that in languages meant as if to be a "better C" like Zig, Nim, V, and Hare, that omit almost all advances in language design from the past half century, howsoever useful.

It's hard to mature when you never stop growing.