Because this language isn't made by a nobody. It's made by a popular person with a following, so the language _will_ get used by a non-insignificant number of people. And those people _will_ (re)implement all the things that you want a language to have (database connections, networking libraries, (de)serialization libraries, etc.). And these things, which can be performance/security-critical, will be impacted by the issues people are pointing out.
Once we reach this plausible scenario, it's likely that some software that you want to use on, say, your server, will depend on those libraries. And _then_, like it or not, _you_ will be impacted by the choices of the language and be subject to whichever bugs all those people made when reimplementing (in this case) hash tables.
We could assume that everyone writing libraries in this language will be an expert and not make mistakes, but that is just a non-starter. In a sufficiently-large ecosystem, the people writing code will come from all sorts of backgrounds and have all levels of expertise, so you _will_ get buggy code in important libraries, and those bugs are the stuff most CVEs are made of nowadays.
I get with what you are saying that people are free to develop a language as they choose, and I agree with you there---I'm building my own and it's _not_ a modern language---but there can be consequences in the larger industry, and that's the "scary" part.
This language is only available on platforms where you are free to choose whatever software you want. If you think a Hare program is insecure, don't use it.
Let's say it's 2030, and I want to host my own matrix server. I would first compile a list of all matrix server implementations, and filter out those with confirmed bugs, and only then choose one (at random or some other criterion). The ones with bugs introduced by some library written in Hare/C/Rust/C++/X language will never be popular enough to even end up on the starting list cause people don't want to use buggy software (at least if there are options and in sufficiently-large ecosystem, there are options). And you might say that those bugs will go unnoticed - yes, but no more unnoticed than any other bug introduced by faulty logic but written in, say, Rust.
Also:
> so the language _will_ get used by a non-insignificant number of people
Hare is fairly opinionated (e.g. it mainly targets FOSS operating systems) so saying that it _will_ be used _just_ as a result of being related to ddevault (a person with a following), is a _wild_ guess. It does not matter how big of a following the author has, if the language itself is bad, it will not get used, or at least, it will get forgotten soon enough.
>In a sufficiently-large ecosystem...
In a sufficiently-large ecosystem, performance/security-critical software will be created using a language that is used not because of the author's following… Again: if the language itself is bad, it will not get used, or at least, it will get forgotten soon enough.
You can write buggy code in _any_ language.
If the industry makes mistakes, that's not news.
If Drew and Co want to make Hare the way it is, awesome! If you don’t want to use share and prefer something else, great!
I understand some people will not want or value any given piece of software or infrastructure, but the blanket pessimism is not proportional to the alleged detriments proposed by Hare’s mere existence.
Maybe I am just being overly sensitive to what I see as over reaction to someone’s programming language preference, but this is the reason I have never, and probably will never, release the language I made and use day to day to the public.
Hare's problems are much deeper. They stem directly from Drew's fundamental misunderstanding of the nature of software development. Drew is correct that managing complexity is central to the problem of software development. He is 100% wrong on how a programming language can contribute to solving that central problem.
There has been a great deal of progress, in the past five decades since C burst on the scene, on managing complexity in programming tasks, with programming language design taking a big bite. Hare adopts exactly none of that success, setting users straight back to the 1970s again. That might have been fine if demands on programmers were no greater than in the 1970s (although the bugginess of software coded then argues otherwise), but anyway we do not live in that world anymore. The programs we want to run don't fit in 64K of RAM and run single-threaded with no network connections, anymore. Where a 1970s language is used for programs today, we all suffer from the failings the language almost unavoidably invites into them.
The fundamental insight that Drew has wholly missed is that essential complexity demands more attention to get right than is typically available for one use case. We have learned that pulling complexity into a library component, or (better) a Standard Library component, or failing that a programming language feature, enables attention to be paid to it amortized across all the programs and libraries that depend on it. All the meaningful progress in programming languages since been in finding ways to bring more of what must be expressed into one place so it may be more widely usable, and able to command correspondingly more attention to its performance and correctness. Standard library components in our modern languages successfully remove their complexity from what programmers must manage.
The ways we have discovered to help with this process include powerful type systems that have been put to work doing heavy lifting far beyond mere "type checking". We have generics to work with types the way types work with values. Certain languages provide extra tools such as destructors/Drop traits that enable automating resource management. Many languages assert direct responsibility for pieces of that task, imposing borrow checking or GC. There is much left to do.
Hare provides exactly none of the tools that have been discovered to encapsulate complexity into carefully correct and generally useful components, or to enable using such a component in all the different places and ways it would be useful. This failing is painfully evident in the library components it does attempt.
In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy. Evaluated as a toy, there is nothing wrong with it. But it is not presented as a toy. As a tool for programming in the modern world, it is sorely lacking everywhere that C is sorely lacking, that make C directly responsible for the massive suffering documented in the litany of CVEs, botnets, database exposures, and ransom events.
I would be very cautious when calling anything that encapsulates complexity "carefully correct" or "generally useful". Hiding such complexity behind language features is how we ended up with new generations of programmers who have no idea how to code anything themselves.
If generations and generations of stack overflow copy-pasters are the future of programming, then I don't want to be a part of it.
"In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy."
Excuse me? The most useful, the most endured, the most sane and the most understood coding paradigm is a toy to you? You know, some of us really like to think of our programs as many procedures being called one after the other.
That's the most logical way to think about them, because it's the exact way the CPU sees them.
CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'. A rudimentary feature, true, but one identically the same as is found in modern languages, among their more powerful features.
I am, indeed, always cautious about calling things "carefully correct and generally useful". Still, I am aware of many language features and standard library components in modern languages that fully satisfy those criteria.
Who pastes code copied from stack overflow? I assume that was a ham-handed attempt at an insult. You are welcome to continue fooling with toy languages, old and new. Pretending they are adequate tools for serious work says more about you than about them.
Can you explain what you mean here? In the context of structured programming.
"CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'."
That's right, CPUs execute instructions. Those instructions are executed one after another, with jumps when a certain operation should be repeated or skipped. This is the definition of structured programming. Structured programming is a simple abstraction over how CPUs execute machine instructions.
I don't see any objects with methods there. Nor do I understand how would a CPU understand a lambda function or care if something is immutable or not.
"I assume that was a ham-handed attempt at an insult."
No insult there. It is just a sad reality how many developers rely on Stack overflow instead of using their own head a little.
Structured programming was defined by Edsger Dijkstra, and consisted originally of a model of programming with restrictions on where branches may go. Later programming language constructs if/then/else and while implemented this model. It does not address subroutines.
I describe C and similarly primitive languages as toys because they do not provide the expressive power needed to enable the levels of productivity and reliability demanded of serious work.
It's a very young language. One might consider that early mistakes can be addressed, but only if somebody speaks out about them.
I question framing this question as "shooting it down." The project will clearly survive this criticism. The article is by somebody who took the time to learn the language, and will probably continue to invest their time into the language. Criticism of this kind is a gift.
You might think "nobody will use the language", but if nobody pushes back and says why people shouldn't use the language, perhaps people will start to. It's really important that people do write feedback pieces like this, because it helps other people be informed about their choices.
And I will assume that your next comment will be about how the two don't compare. And I am in full agreement with that, except for the fact that trivializing abuse is another element that people use in this type of debate, and I believe that abuse is abuse. It might not have the same emotional impact on the victim, but the abuser psychology is similar in all cases, and the slippery slope of losing sensitivity to it begins with accepting discussion board bullying as normal.
PS. However this discussion is at least an order of magnitude removed from TFA, which is not abusive, merely presumptuous and premature.
I've really been enjoying Hare. As a primary Go/Rust developer its syntax and limitations feel like what I've been looking for and it's youth predicates plenty of opportunity to work on new project. When I was working on a ANSI Colors lib [0] last night I spent a lot of time in the community IRC. Your post is basically what everyone's feeling. This is a language designed for people who like it's style. It doesn't need to have this or that feature. And if the community changes their mind, what better candidate than an open source tight-knit young language?
Live and let live, don't tell others what they need.
> but for code that’s supposed to be used in production it’s useless
This isn't about doing what you love - it's about engineering a product, a product that needs to have certain safety, security, and stability guarantees. That's the context of this conversation, and for that purpose, Hare isn't suitable.
It has nothing to do with anything you do. It has everything to do with the impact it has on everyone but yourself.
Hare's value proposition is simplicity- which allows you to better reason about the software you write, for one thing. We are each entitled to our own opinion about how valuable that is.
Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.
Your opinion of Hare's view of simplicity is your opinion. Any software effort has some amount of essential complexity, in my experience many languages and tools quite a bit of incidental complexity that could be avoided.
Avoiding unnecessary complexity is everybody's responsibility. Dumping every last bit of unavoidable complexity onto the programmer where it has been long demonstrated that tooling can take care of much of it is simply irresponsible, and inexcusable.
I do not excuse it.
It's not really relevant.
Besides, none of those have to do with software engineers. Compliance doesn't imply any individual responsibility.
> I've worked in defense and there are stringent security requirements for applications and servers.
Like? FEDRAMP? The vast majority of compliance is about threat modeling and access controls.
No, STIGs.
> The vast majority of compliance is about threat modeling and access controls.
If compliance doesn't address security, that sounds like a bigger issue than a new hobby language existing.
And we're telling them they shouldn't.
That's pretty rich
I'm not saying that memory unsafety isn't a problem, but if you really want to make software better, you should address the biggest problems first.
Then ... don't use it. Others can use it and see what they learn from it, or even whether they find it productive to build stuff with. Even Brainfuck and Malbolge have devoted users who enjoy the challenges they pose, so I can promise you there's room enough in the world for this language. Let's just have some camomile tea and calm down a little.
Furthermore, it could be argued that our time could be spent more productively than on a language like Hare.
As for whether our lives could be used better, well, let's leave that to each individual. I heartily encourage you to live your life as I do, worrying about what I myself am spending time on (currently: this inane conversation), rather than whether other people might be spending their own time in some supposedly-slightly-suboptimal manner.
It is literally everywhere. Your kernel, your networking stack, your interpreters, your office suite.
Almost everything you use has some roots in C, a memory unsafe language that "messed up" and still became the most widely used language ever.
Software will always mess up, regardless of language it's written in.
Do I really have to guess the order that my procedures are called? FP zealots say that I do.
What makes generics and functional programming style mandatory for any given language?
These things just add complexity and philosophy to a field that values pragmatic thinking.
Functional programming is not pragmatic. And neither are thusand ways to handle generics.
It doesn't have in-built immutable data structures, most basic data structures and types are mutable and have mutate in place methods as their primary way of interaction. Struct fields being private by default is a dead giveaway (unnecessary in an FP language). Closures and functions are not the same thing and you cannot do much with them except calling them and passing them around.
I would rather describe it as an imperative language with lightweight OO (via traits) and some FP sprinkled on top. Note I'm not saying you cannot write FP code in it or that Rust doesn't have great unique benefits.
Immutable data structures by default would involve avoidable overhead, so that's why they aren't a built in. There are well-known crates that do provide persistent data structures in Rust.
> Struct fields being private by default is a dead giveaway (unnecessary in an FP language).
Data hiding is just as useful in functional programming; in particular, it enables you to expose an interface to data that stays valid under any isomorphism, while preserving desired invariants. Structs with generally accessible and updatable fields are a special case.
Certainly.
Since the announce of Hare I've seen __too__ much criticism IMHO.
I think the authors have stated clearly the intentions and the features of the language: They just want a slightly better C. Of course you may not like it, but no need to be that harsh...
If Hare is intended to be a deliberately Spartan C replacement, so be it; but pretending that writing a hash table is easy looks like the immature and arrogant opinion of someone completely unaware of his ignorance.
I agree, that implementation is definitely flawed. Probably the author do not consider that important a proper hashtable.
> looks like the immature and arrogant opinion of someone completely unaware of his ignorance.
This is what I'm referring to when I say "harsh" criticism. Maybe he is wrong, but I think there are better ways of saying it: "Hey, maybe a proper hashtable is not that easy.. have you consider [insert here improvement proposal]?"
Wrong questions (focusing on the narrow case of unique, overspecialized application-specific data structures), not only forgivable wrong answers (that hashtable from the Hare compiler, after all, could be close to good enough for its specific usage).
Personally, I think abstract data types based on some kind of macros or templates would be a valuable feature for Hare, even if their use in the standard library is limited, because someone will want to write reusable libraries.
Even within the confines of an application, there is a practical need to deal with different uses of a data structure in the same way and make changes in one place (e.g. "the generic hashtable in our ORM" ) rather than in possibly numerous quasi-duplicates (e.g. 250 different struct to struct hashtables representing database query results in a large business application).
C++ templates, a good example of what could be realistically offered by Hare, allow to upgrade a definition from "do X with one type" to "do X with any suitable type", which is a useful abstraction even without reuse (what's actually expected or not of the type parameters becomes explicit), a technique to write general libraries "for free" (e.g. you can put whatever you want in our hashtable), a technique to define general language foundations (e.g. you can have smart pointers to anything).
So far, not many languages measured up to C. Hare just might, with it's right amount of simplicity and C's footguns gone.
So it's small surprise to see The Rust's Evangelist Strike Force in action on these threads about Hare.
A huge potion of the criticism at this point towards Hare has been summed into three points: no ‘generics’, no memory safety, and small stdlib combined with no package management.
But, I can imagine that if Hare had generics using template metaprogramming then people would complain about how language design has shown that templates are not good enough, so it needs to be not just a way to have compile time type specialization of data structure, but enable ad hoc polymorphism as well and of course that needs traits or typeclasses.
Further, if Hare used testing and fuzzing and modeling, then claimed to be within the bounds of some error percentage ‘safe’ from leaks, use-after and double free, out of memory conditions; the counter claim would be that you can not be safe, for ANY usage of the word unless you have ownership and borrow checking.
And finally, without a centralized, language committee backed and certified web based way to store and access libraries Hare will never be able to make usable and fit for purpose software, so a package manager is a must have to be worth even considering.
All that said, I don’t think it is exclusively users/promoters of Rust that are complaining/disparaging Hare’s very existence. But it certainly seems like many, many people seem to be convinced that their use case/product goals/preferences are the only considerations for any individual of group making engineering decisions.
And those are the very same reasons Hare should remain a simple language.
You can never please the crowd, but you can please yourself and a couple of your friends.
In the example, maybe the static size of the table is fine, and maybe not being able to remove items from the table is fine, but unless maybe it's some sort of cache, it's almost never ok to assume that there will never be any hash collisions.
I mean, if you don't want to include hash tables in your language or library, fine, but using a bad example to attempt to justify it after the fact is.. not good.
He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions and people are just lining up to be Debbie Downers.
Now I almost feel like I need to learn more Hare to give the guy some encouragement and positive feedback on things done right. Be the glass half full guy.
Well I won’t. I think Zig will be the last C-like language I invest time in. It is so easy to get sucked into something new that will never go mainstream.