Heresy: Hare programming language an alternative to C On Monday, software developer Drew DeVault announced a systems programming language called Hare, describing it as "simple, stable, and robust." We've all heard that before – but there may be something in this. More than 400 programming languages have existed at one time or another. Hare aims to serve as an alternative to C – …
The language is designed to stabilize and remain largely unchanging
That is a very good thing; one of the issues with some languages is they are continually changing. One of the strengths of C (I am aware of the many pitfalls) is that it is not being 'updated' every few years (I'm looking at you, C++).
I will have to take a look.
This post has been deleted by its author
Well, quite.
The evolution of programming languages seems to go like this:
1. Initial reasonable idea
2. Acceptance
3. Flurry of "wouldn't it be great if we have $feature like $otherlanguage"
4. Bloat to the point of incomprehensibility
5. Someone proposes another language. goto 1.
When I largely stopped coding and took up drawing pictures full time, C++ was pretty nice. We had templates and exceptions. When I look it at now, it's like WTAF?
If a library is useful enough to you that you'll include it but can't understand its code, then you might as well treat it as any other binary blob. How often do you *actually* audit a library's code from top to bottom, or create a patch to upstream? For an immature project you're taking a chance on, it would be worth being able to work with it, but for a mature project even if it's bog standard C it's going to be complex enough that spending days to learn it and try to pinpoint and correct an issue might not be the best use of your time, assuming you ever run into one at all at that stage.
The thing is, most of the new stuff was added because real people were using crazy workarounds to achieve what the new features add (if it could be done at all).
C++ long ago gave up the philosophical purity of being small and clean; instead it takes the pragmatic approach of identifying what users are trying to do, and providing features to enable it. No doubt it would be an easier language to use if it could be started again from scratch, but that comes with its own costs (and those are recurring costs, because I'd bet that the new language would wind up in exactly the same situation in 20 years).
*The thing is, most of the new stuff was added because real people were using crazy workarounds to achieve what the new features add (if it could be done at all).*
That's a clear cut case of using the wrong tool for the job. This is because too many people do not have more than one tool in their tool box.
The pattern I have noticed is
1) Everyone uses programming language pLangX. It's a job requirement. But bloated or ill suited to many tasks.
2) Someone decides to clean up the situation and comes up with pLangX++ which works as intended.
3) Early adopters who understand the intent like it and begin promoting it.
4) As it gains adoption it shows up in job requirements books, training courses etc. begin to appear
5) Schools start teaching and managers hearing success stories begin requireing it.
6) pLangX++ gets pushed into areas it wasn't intended for and so new features are added.
7) eventually it becomes a bloated mess.
8) repeat cycle.
It's not like we are talking about turning it into a scripting language or something. Many of the best new features in recent C++ revisions have revolved around making templates more powerful, and I think it would be absurd to claim that C++ is not the right language for writing high-performance templated code.
Unless you are denying the very concept of a general purpose programming language.
Surely if we completely stopped using general purpose programming languages, there would be significantly more languages floating around...and you would have to learn a new one every time you wanted to jump domains...
And I still don't believe that this says much about the growth of C++, as I hardly consider std::filesystem to be the kitchen cabinet.
My various greenhouse environments haven't changed since I built my first one, a hair over 50 years ago. That's kind of the point of a greenhouse. The current code in the one that hasn't been updated to AtMega 328 yet is still running code I wrote about 40 years ago. I think I got my money's worth out of the original Z80 & S-100 bus ...
There are many other systems out there that have aims and environments that haven't changed appreciably in decades. Some for over half a century. Upgrading these systems just for the sake of upgrading them is asking for trouble.
"More than 300 programming languages have existed at one time or another. Hare aims to serve as an alternative to C"
Sometimes it seems that there have been more than 300 programming languages just in the "alternative to C" category or even in the "alternative to alternative to C" category.
Oh, look! Another!
Especially since a lot of the potential "customers", i.e. big companies will be running Windows on the majority of their company computers, and programming languages tend to need a big push from industry to become even remotely relevant.
The other thing is, this just seems to be revamped C, like what does this actually really add other than maybe a little tidying up and not having so many imports? At least with rust they have valid benefits over C, like being safer with memory and suchlike. Hare just seem like cut down tidier C and that alone isn't going to give C programmers a reason to switch.
I too am genuinely interested. I sometimes feel a little skeptical about the proliferation of languages to make up for a shortcoming in some other language...is the amount of effort that goes into creating a new language significantly less than working out how to overcome the shortcoming in the original language?
Or maybe I'm just an old fart / failed programmer who should just shut up and go back to drawing diagrams...
Hare looks like the possibility of being an excellent new language, but let's wait and see how it goes ... what will appear first, a new version of Linux or some new Malware? It looks excellent for both areas - I'm not complaining, it's just a very advantageous new language for these environments.
"is the amount of effort that goes into creating a new language significantly less than working out how to overcome the shortcoming in the original language?"
The same applies to the effort of everyone else in learning the new language.
I can't speak for Hare as I have no familiarity with it beyond what I read in this article, but I can say with confidence...
...C prevents buffer overflow exploits
...C++ prevents buffer overflow exploits
...PERL prevents buffer overflow exploits
...probably all languages prevent buffer overflow exploits.
Careless/lazy programming does not prevent buffer overflow exploits.
Like an earlier comment says, the trick is learning to overcome problems in the existing language, not creating a new one in the false) hope it'll be some sort of panacea
In an object orientated language where basically a procedure is used to add data to a storage structure that can check how full it is. That would throw an error rather than over fill it. In C you create a memory area with memory allocation or a static and then pass the pointer to this. There is nothing about the pointer which says how big the memory area is therefore no way to ensure you don't over fill it.
C is a stupid language in this respect.
From The Ten Commandments for C Programmers:
5 Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
I have never found it particularly difficult or onerous to check against the actual size of any container in C; admittedly it does require one to do it oneself.
I've just started looking through the tutorial and, while you can turn off bounds checking, it looks like it's on by default.
Somebody else mentioned tagged unions - they seem to be there. The `use` syntax that's being objected to is the equivalent of `#include <x>` not C++ style namespace inclusion.
It's got type checking and type inference. So it's a simple, non-OO language with modern features.
It looks nice rather than Koitlin. But probably not enough to displace the copy of tcc in my path.
“Does it prevent buffer overflow exploits?”
It’s up to the programmer to avoid buffer overflow exploits. No technical solution can fully protect against human incompetence.
If you are writing code that runs off the end of your buffers then you need to go back to school. That would help much more than blaming your tools
AFAIK a 'buffer' is not a fundamental type in 'C', its a construct that we often make from a row of char that we define as a buffer. If we wish to give it properties such as overflow protection then we need to make a synthetic type with those properties (which leads in the general direction of C++).
This underscores a very important property of 'C' and similar systems programming languages. Their support libraries are not part of the language.
This. It feels weird to read an article that purports to introduce a new language, where "alternative to C" is in the title even - and then find out that there's absolutely nothing in there that describes a feature it does better than C.
Yep, as far as I can tell there are zero people saying "I'd use C if only it supported more features in the runtime so I didn't have to link with other libraries" and many many people saying "I'd use C if it was more idiot proof against programmer errors like buffer overflows while still prioritizing performance".
From their blog...
https://harelang.org/blog/2021-02-09-hare-advances-on-c/
I can see how the error handling approach could help but only if every function adopts it. Which, to my mind, isn't really any less tedious than having to put try...catch around every function call in other languages.
And in the first example on that page: (a) what happens to the value of 'sum' if the function errors out and (b) why isn't 'sum' used in the happy path processing? I must be missing something.
Lastly, the requirement to test every possible error return in the match statement could result in pretty large code: the C socket() function has 90-odd possible ERRNOs. Usually you only want to test a couple that are potentially recoverable otherwise it's abort time and write the errno to the log file. Hare looks like you'd have to have a match statement for all 90.
It seems to be too obvious a failing so I must have missed something?
Thanks for the link, 2+2=5
Key takeaway:
"A complete lack of memory-safe features and a miserable error handling experience both make it pretty easy to make mistakes in C that are not possible elsewhere."
...
"In summary
"Hare makes a number of conservative improvements on C’s ideas, the biggest bet of which is the use of tagged unions. Here are a few other improvements:
* A context-free grammar
* Less weird type syntax
* Language tooling in the stdlib
* Built-in and semantically meaningful static and runtime assertions
* A lightweight system for dependency resolution
* defer for cleanup and error handling
* An optional build system which you can replace with make and standard tools
"Even with these improvements, Hare manages to be a smaller, more conservative language than C, with our specification clocking in at less than 1/10th the size of C11, without sacrificing anything that you need to get things done in the systems programming world."
"To a man with a hammer, everything looks like a nail. To a Computer Scientist, everything looks like a language design problem. Languages and compilers are, in their opinion, the only way to drive an idea into practice.
My early work clearly treated modularisation as a design issue, not a language issue. A module was a work assignment, not a subroutine or other language element. Although some tools could make the job easier, no special tools were needed to use the principal, just discipline and skill.
When language designers caught on to the idea, they assumed that modules had to be subroutines, or collections of subroutines, and introduced unreasonable restrictions on the design. They also spread the false impression that the important thing was to learn the language; in truth, the important thing is to learn how to design and document.
We are still trying to undo the damage caused by the early treatment of modularity as a language issue and, sadly, we still try to do it by inventing languages and tools."
--David L. Parnas
Nobody "writes new Linux Distributions" ... Linux distributions are assembled from already written code, kind of like using Lego. That's why any idiot can, and seemingly does, do it. No coding required.
pace minor scripting as glue to hold it all together, of course ...
If you think modern Lego is bad, it's nothing compared to what it used to be.
I'm particularly thinking of the old wheel blocks and wheels, where the wheel plugged into the wheel block using what I can only describe as a pin.
If one of these was pin upwards and you stepped on it, you really knew about it, and may well have ended up bleeding as a result as well!
I see your Lego stub axle and raise you an eight-pin DIP ... The venerable 555 has a habit of landing pins-up just exactly where my heel is going to come down. I've stepped on 6 of the damn things over the years ... all drew blood, two of them left bits behind in the bone, requiring removal by a surgeon. No other IC has ever assaulted me, just the 555. Is it paranoia when they really are out to get you?
Of course. Any reasonable programmer probably will. I plan to do so in my !copious free time.
And then it'll likely sit, unused, like the cheap knock-off tape measure at the bottom of my toolbox.
I'll give it an honest shot ... it's nice to be pleasantly surprised occasionally!
This is what I see from their example compared to C and its offspring :
use instead of #include
addition of unnecessary "export fn" to function definitions
move return type so it's after function name instead of before it
addition of unnecessary "=" after return type
have to specify fmt:: namespace explicitly (which is the exact opposite of C++'s "using" keyword which lets you omit namespace prefixes and keeps code tidier)
I don't see any productivity gains at all from these "improvements", it looks more like changing things around just for the sake of being different, and will of course be a source of errors when people used to C/C++ try to adjust to it. They really need to better explain in some detail why they consider their code examples to be better than other languages, because this example doesn't do that at all. And even worse, their website insists you watch videos, rather than read some text as an introduction to the language. Any "how to" meant for programmers that's done as a video is an instant avoid flag for me.
It rather depends what their import/includes look like, as well as things like pre-processor behaviour and namespacing. C's nasty behaviour around delicate build structure and rug-pulling for IDE inference systems are not exposed by a short hello world example.
Frankly if you're judging a language on whether it makes you type an extra character, you'd better go back to C.
That's the OP's point.
The example just says "Hare has a different syntax for these common tasks".
Different syntax for the same thing is harmful.
Different syntax for a thing that is actually "sufficiently" different, is a good thing as it helps you keep the concepts separate in your head.
However, there's no indication as to why the syntax is different. What meaning do these convey?
> What meaning do these convey?
Nothing.
Frankly, this project looks like some grad student's idea of writing some syntax wrappers around Standard C to make C look "modern" - whatever that means.
Hare function declarations need fn. Why? What language problem does fn solve for function declarations?
If I wanted to, I could add fn to C:
/* fn.c */
#include <stdio.h>
#define fn
fn int main()
{
(void) fprintf(stdout, "Hello, World!\n");
return 0;
}
%> gcc -g -O2 -std=c99 fn.c -o fn
%> echo $status
0
Did that do anything useful?
Hare function return type is to the right of the declaration. Why? What is the semantics being conveyed here?
Yes, I went through the hassle of cloning the Hare source code and reading some of it.
If you're going to go through the trouble of inventing a new programming language, at least make an effort to add something more than meaningless cosmetics.
fn makes the job of parsing much easier. C and C++ are notoriously difficult to parse and the lack of any concrete "markers" for function declarations is a big contributing factor to that. Any language whose goal is to be easy to parse will have a fn or similar marker for function declarations. See Lua and Rust (whose ease of parsing makes for writing declarative and procedural macros a very nice experience)
I don't see the point in complaining over a 2-letter keyword that makes the language itself easier to develop.
You missed my point - the post I was responding to is focusing on syntax, I'm talking about compiler behaviour.
C's dependency mechanism exposes developers to ordering problems that *the code you write* cannot meaningfully express, because the build system and pre-processor independently impose their own semantics.
Compare this with more modern languages where a dependency does not change it's behaviour based on the order in which it is encountered in a build. Not only does this reduce errors, code smells and improve comprehension, it allows tooling to perform dramatically more sophisticated analysis, introspection and refactoring.
It doesn't matter what word or syntax you see in an example hello world program - the significant improvement comes in how it is processed by the compiler.
(This is one of those blind spots for long suffering C developers - they're so used to being kicked in the butt that they complain that the boot's the wrong colour when someone suggests they stop the kickings).
> It doesn't matter what word or syntax you see in an example hello world program - the significant improvement comes in how it is processed by the compiler.
Bullshit.
In C's case, fn in my example gets tossed out entirely by the preprocessor, because it doesn't do anything. It's pointless.
In Hare's case, either the language, or the compiler, or both, suck.
Hare needs fn to be told that something is a function, because it can't figure it out on its own. Either because (a) there is a semantic ambiguity in the language that cannot possibly be resolved otherwise, or (b) the compiler frontend implementation is so sucky that it can't figure out when a function is a function without crutches, and ends up going into the weeds and emits the wrong AST.
Having the function return type to the right of the function's arguments might have something to do with that. But I don't have the time to spend pinpointing where exactly the problem is.
In the end, in both languages, the function written by the programmer is lowered to assembler. Claiming that fn in Hare is necessary because it's a significant improvement [ ... ] in how it is processed by the compiler is pure bullshit.
I write compilers for a living, and I'm not the only one around here doing that. Metaphors about C developers and boot colors, or mystic references to compiler internals - woo-hoo! - don't work that well around here.
C is only one of my languages. As a C guy, I find Hare's syntax for function declarations and function calls very clumsy compared to C.
Oh dear. If you can't keep a discussion civilised, I'd rather stick to the commercial compiler projects I've worked on than whatever you're being so precious about.
The discussion kicked off about dependency declarations and exporting functions - both of which are well established as being one of the clunkiest parts of C, and a serious restriction on tooling compared with modern languages.
Now you've moved the goalposts to not liking where they've put the return type of a function (hint: take a look at Go, Swift or a dozen other languages that do this), and objecting to the use of an extra token for identifying functions.
My point stands - if the OP's original analysis of the language is limited to looking at small syntactic changes, they are going to miss features that other, more modern languages have introduced that absolutely do improve developer efficiency, code quality and reliability. Whether Hare meets those standards is another question that neither you nor the OP have meaningfully addressed...
I was wondering if they used it for macros like Rust... but no, apparently they decided that statements with a trailing ! immediately crash on any failure code, rather than relying on error handling. (So basically equivalent to Perl's "or die") And they use a ? to specify to return on error, equivalent to just not handling an error in C++ and letting it propagate up.
There's no explanation of what no suffix means. I guess just keep muddling on?
I... just what?
I never even noticed it - not a good sign, especially as it is of course also the sign for 'not'. Now that I spent a bit more time looking at the language spec, it's a real horrid way of dealing with function failures, basically a sort of crash or try and plow on regardless indicator (you use '?' instead to in effect throw a kind of exception if a call fails, and mingle handled exception types with return type). And of course they've reversed type and name for parameters
fn writehello(path: str) (fs::error | io::error | void) = {
const oflags = flags::WRONLY | flags::TRUNC;
const file = os::create(path, 0o644, oflags)?;
And then there's this horror :
for (let i = 1z; i < len(items); i += 1)
That's enough for me I'm afraid, it appears to be the language equivalent of a stroppy teenager who's dyed their hair in order to look different.
will of course be a source of errors when people used to C/C++ try to adjust to it
Fortunately the world will ignore this idiotic new language and this will be the only time we ever hear about "Hare", so no one will have to adjust to it.
I hadn't heard of qbe before, so followed that link, so I went and read https://c9x.me/compile/
"QBE is in constant change. It is a young project "
Now this stuff looks fascinating, but it seems a paradox to rely on a self-confessed unstable compiler backend when the design goal is stability of the language. One wonders if LLVM would have been a better choice. Or GCC, or transpiling to C99? Genuinely I don't know the plus and minus points here.
I agree 100%, it would be a real good idea for them to use LLVM backend. LLVM is even used to compile shaders and by AMD's stack to run CUDA-type code on the GPU. I'm pretty sure it's not tied to using libc in any way. You'd then have Hare being able to build for many types of CPU, and (from what I've seen) the way LLVM is designed (it's designed so new frontends, backends, and optimizations to the byte code can be "easily" added... I mean, working on a compiler can't be easy but you know what I mean.) if QBE has any nice optimization features that LLVM doesn't do, they can be added to LLVM.
Always fun to explore something different. The standard libraries are of course every much a part of C and C++ as the language. More often than not they do things better than you could code them yourself - with the minor caveat that you need to know where to look for the library contents in of itself.
I'll have to have a play round to see how I get on, and decide if I have a project suited to it (I mostly want UI gubbins and data interfaces so chances are Hare doesn't really add anything)
The reason C and C++ are still top dogs after all these years, I know that any code can be supported by anyone with the skills and there are plenty out here with them. I wish Hare well but they got an uphill struggle against the current top players looking to seal the deal on systems langs.
Let's face it, who's going to a use a baby language that's only 2 years old to code up an entire new O/S or even put it into an existing O/S. Can't see Linus or Bill's bods recoding their respective kernels and drivers in Rust or Hare for the foreseeable.
Linus has warmed to Rust for specific uses. They're not going to wholesale rebuild the entire Linux kernel in some doomed enterprise project, of course, but Rust does coexist with C/C++ nicely, one of it's biggest selling points. No VM, no special linking and marshalling, just builds down to plain native libraries that can be called from C, or that can call C. So a handful of drivers and some new kernel code have been done in Rust and blessed.
The practical reality is that not that many things need to be *absolutely* performance oriented at all costs, which is one place where you absolutely cannot replace C (and ASM), just reasonably performant.
It took a decade of proving its worth first, though, and no other upstart language has even come close to core Linux approval yet.
"Linus has warmed to Rust for specific uses."
Has he? Are you absolutely certain of that? He use words like "we might" and "maybe we will" and "perhaps" and "eventually", and "drivers, probably" etc. etc. Nowhere does he say "Let's do it" or "We are going to" or "It will be soon".
He also is on record as saying ""I don't think Rust will take over the core kernel, but doing individual drivers (and maybe whole driver subsystems) in it doesn't sound entirely unlikely." ... but again, he's not entirely enthusiastic. He has also said "It might not be rust", which to me is a death knell.
I've been reading the LKML for as long as it's been around, and from my perspective it looks like Linus isn't really interested in any language that isn't C for kernel use ... not C++, just good old C ... and seeing as Rust is being positioned as a replacement for C++, not C ... well, do the math.
I think he's throwing the yowling, baying fanbois a bone just to shut them up. We might get a few drivers & the like written in rust over the next few years, but the vast majority of the kernel will still be in C long after the next language du jour takes the place of rust in the fanboi's fancy.
It seems that the authors spent two and a half years building a new programming language designed to replace C and yet didn't address the biggest failings in C. Hare does offer bounds-check arrays to stop you writing beyond the ends, and tagged unions to give a little help in avoiding writing a pointer as one type and reading back as another, but it still has manual memory allocation and manual memory ownership management. This means it's still possible to have memory leaks, it's still possible to have use-after-free bugs and it's also still possible to have stack corruption bugs.
Switching programming language is an effort and people don't do so without a compelling reason, usually that the new language addresses some existing pain point. Memory-related bugs are one of the biggest sources of pain when writing in C. I'm not sure that people are going to be keen to move to Hare as opposed to, say, Rust, if it does nothing to ease that pain.
Problem with new languages is that however slick the syntax is, it will be competing against a language with 1000's of libraries, a huge user and knowledge base, and massive processor architecture support.
For a new language to succeed, being better is not enough. It has to be markedly better or solve a problem that the original language cannot.
Good luck, but I don't think I will be burning my K&R yet
Back in the day, systems analysts used to use a pen to fill out coding sheets, passed to the key-punch operators to type out. Hence, languages like COBOL.
But c programmers didn't have to do that. They could hunt-and-peck directly on their dedicated serial-terminal. Hence languages like c, which saved keystrokes by using single symbols like }, found on the edges of the keyboards they were using.
And languages like Hare, using contractions like "fn"
Rust is actually buffer overflow safe, memory safe, fast, and the syntax is no more different than C than this is (and Hare has some really awful syntax). Rust has far more libraries available. Yes, the default statically linked Rust binaries can be huge, but that's a linker issue (as with gcc/glib) - if you use the right flags Rust will happily spit out a 300 byte static binary by having the linker toss anything you're not using.
Hare might end up being a bit faster if you're really leaning on things that take more time in Rust (like dynamic memory management), but if I really need that extra 5% performance for tiny tight loops I'll just write it in C. I always write in the laziest possible language for some bit of code because it's faster to write, much easier to maintain, and the big gains are all algorithmic.
Remember D? That was better designed, and I'd use that over this too.
Already in 1966, Peter Landin wrote a paper called "The Next 700 Programming Languages" (read it if you haven't), citing an estimate from 1965 that 1,700 programming languages were in use at the time. I seriously doubt that this number has declined to 300 by 2022. Rather, I expect there are at least 17,000 languages by now. Granted, some of these are domain-specific languages used exclusively in-house by some companies or educational institutions or experimental languages under development (I would categorize Hare as one of these). But even the number of languages used for serious development in least a double-digit number of places would still exceed 300.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
