Criticizing Hare language approach for generic data structures

https://ayende.com/blog/197185-B/criticizing-hare-language-approach-for-generic-data-structures?key=37121a38a2c34d1ea56119261822ef99

by ayende • 4 years ago

151 249 4 years ago

ayende.com

formerly_proven2• 4 years ago

"Bring your own datastructures" is likely one of the C carry-overs for Hare. If you think about many "classic" C applications, a lot of them basically only exist around/for one or a few data structures (e.g. most servers, many utilities etc.). In that context BYODS is somewhat defensible: If you don't care to implement the data structure, why does your application exist in the first place?

But that's not "modern" applications, which often deal with a ton of data structures. C applications that do so usually have a few "template headers" lying around (indeed, certain operating systems ship with them), though one of the most frequently used data structures in C is of course the intrusive linked list. Which is not a good data structure to use in most cases. Why is it used so much in C? Because it is easiest to implement. Why does that matter? Because C makes implementing generic data structures tedious. Is it a good idea to replicate that model?

qed.

ddevault14• 4 years ago

Most application's bottlenecks are not their linked lists, and optimizing for anything other than your bottleneck is not the wisest use of your time. Performance is a budget, and I feel comfortable spending some of that budget on simplicity.

dathinab2• 4 years ago

but maps are simpler to use (if appropriately provided by the language).

maps/sets are also fundamentally building blocks for a lot of algorthms and structures, not having them makes it WAY harder to implement them. actually potential impossible as performance can easily degrade to a point where it's unusable when you use O(n) (or worse) lookups instead of O(1) ones.

this is not a case of premature optimizations but of missing fundamental building blocks

and if you don't want genetics, ok, do it like go did initially make the map special language thingy.

ayende4• 4 years ago

Linked list has a O(N) search time, which is atrocious.

A really common optimization is to replace a linear scan on a list with a hash table. In most languages, that is a trivial step to do, which means that it gets done.

There isn't any overhead.

With hare, you just blew your complexity budget on this thing.

usefulcat3• 4 years ago

Linked lists have generally awful cache locality. If linked lists are not the bottleneck, it's because they already aren't being used for anything where performance matters (which is generally as it should be).

MrBuddyCasino• 4 years ago

BYOD combined with "we don't need a package manager" sounds like a particularly bad combination. I understand Rust's "small stdlib but great package ecosystem", but whats the appeal of "anemic stdlib plus no package ecosystem"?

Maybe I would come up with something like this if I only ever worked on Linux software using C, but outside those niches these choices seem weird.

orthoxerox• 4 years ago

but whats the appeal of "anemic stdlib plus no package ecosystem"?

You can declare your language feature complete sooner

capableweb4• 4 years ago

Correct me if I'm wrong, but Hare doesn't say "we need no package manager" but instead "we don't need a new package manager, use the one your OS provides", at least from how I understand it.

ddevault14• 4 years ago

I question the assertion that Hare's standard library is "anemic"; it includes a pretty decent set of batteries for many use-cases:

https://docs.harelang.org

Many Hare programs will not need to have dependencies at all. We encourage a more conservative approach to dependencies than is common in many modern languages such as Cargo, PyPI, npm, Go, etc. Even dependency-heavy Hare projects will not have hundreds of dependencies, but maybe dozens at most. Think more C, not Node.

https://harelang.org/distributions/

CyberRabbi• 4 years ago

Package dependency resolution is fundamentally impossible to do efficiently and often broken (for legacy reasons) in specific implementations. Programmers are terrible at semantic versioning. Community package repositories are security nightmares. Under those conditions not including a package manager seems like a reasonable decision.

one-more-minute• 4 years ago

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances.

Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-unions being an improvement, and there's value in finding the minimal diff that makes a language better.

[1] Remember when Go called itself a "systems programming language"? Neither community seems to use this phrase any more, though.

celeritascelery• 4 years ago

Rust still considers itself a “systems programming language” . They are moving Rust into the Linux kernel and android drivers. It doesn’t get any more “systems programming” then that. But you are correct about go, it doesn’t give the programmer enough control to be used at that level.

usefulcat3• 4 years ago

there's value in finding the minimal diff that makes a language better.

OTOH, if the differences are minimal, then the benefits are likely to be correspondingly minimal. And either way, the compiler/interpreter for a relatively new language will by definition be much less battle-tested.

Practically speaking, I think if a new language is going to compete with C, it needs to offer more than a few incremental improvements.

pjmlp10• 4 years ago

Mostly because writing compilers, linkers, GC implementations, GPU debuggers, OS emulation layers, distributed orchestration systems, unikernels, isn't considered systems programming by the crowd that is allowed to judge it.

avgcorrection4• 4 years ago

No. Rust always wanted to appeal to C++ programmers moreso than C programmers.

wheelerof4te12• 4 years ago

"Because C makes implementing generic data structures tedious. Is it a good idea to replicate that model?"

A lot of so called "modern" languages make a choice for you. Here is a hash map, over there is a class, have a tuple, set, etc. And they all have a specific way to be used.

In implementing all that, many languages lose on flexibility while gaining general utility. Hare seems to go in the opposite direction, one that makes programmers think hard about the solutions to their problems.

And that is, IMHO, a good thing.

Doxin• 4 years ago

I think the main thing is that e.g. python allows you to reimplement all of its most basic data structures in python if you so desire. There's no real way to reimplement e.g. an array in C. The result being that python could still be useful if it wouldn't come with a bunch of data structures built-in.

thecompilr3• 4 years ago

That reminds me that I had to reimplement basic hashmaps in C at least three times in my career. What a waste of time.

turminal3• 4 years ago

How much time did you waste?

thecompilr3• 4 years ago

I don't recall exactly, but at least a day each I would say? They were all performance critical, so had to put some effort. Two of them were for internal nginx patches, but were storing data a bit differently so code couldn't be quite reused. In languages with generics hashmaps are trivial to reuse with zero performance cost.

gradschool3• 4 years ago

Was there a good reason not to use Judy arrays?

edflsafoiewq2• 4 years ago

Why would writing a Judy array three times have been better? Aren't they infamously difficult to implement?

samatman• 4 years ago

One of the rare HN-appropriate occasions for me to say: user-name checks out.

guerrilla• 4 years ago

What's the problem? People will just use libraries. Why does it need to be part of the base language? Seems like that made C++ quite a mess in fact, while NPM-like ecosystems have done well.

edflsafoiewq2• 4 years ago

And the design of the Hare language doesn’t even allow me to provide that as a library. I have to fall down to code generation at best.

sedeki2• 4 years ago

How is it possible that the design of a language do not allow for external code/libraries?

rootlocus3• 4 years ago

Here we go implementing Hare++!

lifthrasiir2• 4 years ago

The entire post is a reply to [1], which mentions the exact code the OP criticizes. Drew said "Hare doesn’t provide us with a generic hash map, but we were able to build one ourselves in just a few lines of code", but the OP demonstrates that hash map is incorrect.

[1] https://harelang.org/blog/2021-03-26-high-level-data-structu...

alxlaz2• 4 years ago

So... people will just use libraries that have a correct implementation?

Lots of C++ compilers shipped STL implementations with atrocious performance (and outright bugs) for like a decade. It's not like putting something in the standard library guarantees correctness or performance.

duped4• 4 years ago

The problem is that you can't properly implement data structures for a statically typed language in libraries without some kind of generics. You can try with explicit casting to void* or whatever Hare uses, but that comes at the cost of type safety.

rieTohgh6• 4 years ago

TreeMap as a fallback for bucket and/or some king of random salt for hashes had to be introduced due to security issues (DoS) - I doubt anybody would remember about such stuff when making own hashmap implementation.

eatonphil7• 4 years ago

Any links to learn more?

formerly_proven2• 4 years ago

The average performance of hashtables generally depends on collisions being rare, but if the hashed index is trivially derivable from the key, then an attacker can supply data where everything hashes to the same index, regressing performance to the point that it's a DoS attack.

This is why cryptographically secure short-output hash functions like SipHash were developed.

ddevault14• 4 years ago

https://en.wikipedia.org/wiki/Collision_attack#Hash_flooding

Note that this is only a problem when an attacker can influence your hash table usage, and can be mitigated with hashing functions like siphash. This is not necessary for the majority of hash tables in the wild.

grnmamba• 4 years ago

The primary reason I prefer working in C++ over C is that, for all of C++'s faults, it ships with a solid collection of containers and algorithms in the standard library. unordered_map may suck compared to other implementations, but it's a vast improvement over linked lists or home-grown hashmaps.

Anyone can write a hash map, in the same way that anyone can write an HTTP server over a weekend. Doesn't mean it will be production quality.

Glibc's obstack doesn't count, it's non-standard and the only type it supports is (of course) void*, which is a bad interface.

veltas4• 4 years ago

it's a vast improvement over linked lists or home-grown hashmaps.

One of the easiest things to do is write home-grown hashmaps that perform better than std::unordered_map. I suppose you have to worry more about technical debt / bugs, but yes home-grown hashmaps are feasible and I don't think std::unorderd_map is a "vast improvement".

ahmedalsudani3• 4 years ago

Easy to write, sure. But every time a developer has to look at it for the first time, they'll need to learn this hashmap's interface.

Do I need to manage memory? Does it manage memory? How do I iterate? How do I add a new key space without thrashing the original implementation and making it twice as complicated?

That's the biggest thing a standard interface gives you. Even if it's less performant and not well-designed, I'll take it.

The C++ containers are actually well-designed and performant so it's a no-brainer if you get to choose.

Almost forgot the type checking you get with C++. That's also a major factor.

ddevault14• 4 years ago

Thanks for writing this up, though I feel that it may be a bit premature since at this point hardly anyone has any real experience writing Hare code. Regardless, I understand that this is a contentious design decision of Hare, so I would be happy to explain in it in more detail.

We have discussed adding first-class maps to the language many times. We recognize the value in this feature and have tried to come up with a good way of doing it that fits within the design constraints of the language, but it has several design issues. There are three key problems: finding a good way of hashing arbitrary data structures (or arbitrarily limiting the kinds of keys the map can store), finding a good way of determining equality of arbitrary data structures, and dealing with memory allocation semantics. Hare does not have generics, and the alternative is a hands-free approach to hashing and equality, which has some troubling limitations, some of which are very unintuitive and non-obvious (which conflicts with our values for explicitness). The allocation problem is also troublesome: Hare uses manual memory management, and any hash map solution which involves magic behind-the-scenes allocations has serious design conflicts with Hare's principles.

This article criticizes a sample of a hash map implemented for the build driver. This hash map is used to store a mapping of module details keyed on the module's namespace. It is true that it is a fixed size map, and that collisions can easily be found for the fnv32 hash. These constraints limit the ability for this hash map design to generalize. However, this is not supposed to generalize. It's designed to be a special-purpose hash map for this specific use-case, and takes the simplest approach which is sufficient to this specific problem. As the author notes, there are many approaches to hash maps and there is no one-size-fits-all solution. So far as hash collisions are concerned, these are very unlikely in this use-case. This is not a hash map where hash flooding is a concern, and accidental collisions are so unlikely as to be a negligible risk. If this were not the case, it is easily fixed by just comparing each bucket entry by the namespace rather than by the hash. For use-cases where these things do matter, I would be interested in seeing something like siphash end up in the Hare standard library.

Recall that Hare is designed to be similar to C in terms of scope and goals. C also provides no general-purpose hash map, and little by way of other data structures (though some attempts exist, none of them good). Each of these approaches and concerns comes with different needs and trade-offs, and Hare places responsibility for evaluating these needs and trade-offs into the capable hands of the programmer. This is a reflection of Hare's values, which are distinct from the values of some other languages mentioned in the OP - Rust, Go, Zig, C++, etc.

Thanks for providing me the opportunity to clarify this here, though perhaps this merited a blog post rather than an overlong HN comment. I understand that this is a design decision which appears especially confusing from the outside, but know that it was made through careful deliberation and discussion.

Oh-- and a map-like thing for net::uri would be nice to have as a convenience function in the future. We need to implement the basic approach using the most fundamental design and then build the convenience on top of it, in order to accommodate all use-cases and leave the trade-offs for the user to make.

lifthrasiir2• 4 years ago

So far as hash collisions are concerned, these are very unlikely in this use-case. This is not a hash map where hash flooding is a concern, and accidental collisions are so unlikely as to be a negligible risk.

The current compiler will silently ignore colliding hashes and (I believe) result in a very confusing error. The probability of this happening is not very large, but still not small enough that someone will hit this error probably this year. At the very least you need to report hash collisions so that you can somehow rename your modules and so on.

ddevault14• 4 years ago

Checking the bucket entries based on their module identifier instead of (or in addition to) their key is a simple and obvious improvement to this code.

https://todo.sr.ht/~sircmpwn/hare/679

duped4• 4 years ago

Why not support limited parametric polymorphism for things like equality and hashing? These are well studied problems, seems a bit convoluted to reject existing solutions.

ayende4• 4 years ago

I think that there is a problem here with regards to what you are trying to do.

You are conflating the _implementation_ of a hash table with the _existence_ of a hash table.

You list a few problems:

Computing the hash for arbitrary structure & check equality of the hash is something that you can do by adding a func in the creation of the map.

That will likely add overhead (since you can't inline it, and most of them are trivial), but at least you'll have something.

I'm not sure how memory allocations for a hash table is any different than the usual. Memory ownership semantics are likely relevant, so you'll likely need to add a way provide a free() routine here, as well.

A common example may be a `map<string, file>` - where you need to deallocate the string and `close()` the file.

This gets interesting when you do a set over an already existing value, by the way. And certainly a challenge you'll need to deal with.

My issue isn't so much with the complexity of the solution. Design choices such as not having generics will have impact on performance. But having _a_ solution is still a baseline requirement in my eyes. The original post said that you can just roll your own, except that you really can't. Certainly not over & over again.

With regards to the hash table I criticized, that is exactly the point. You were able to "get away" with implementing a pretty bare bone thing, but you called it out as something that should be viable in general.

Hashtables are in _common_ use. They aren't something that you'll use once in a blue moon. Go's decision to provide dedicated syntax for map wasn't an accident.

And for certain scenarios, you may need to use a different implementation to get the best results. But for the vast majority of scenarios, you just want _something_. And whatever you have in the box should suffice.

That is because a generic data structure has a lot of work done on it to optimize it for a wide range of scenarios. Conversely, a one off implementation is likely to be far worse.

There are also security considerations to take into account. You are not likely to properly implement things like protections against has poisonings attacks, etc.

And "easy to fix" is sure, but you have to remember to _do_ that, each and every time you write this code. Because your approach is to give that ownership to the user.

And your language design means that you _cannot_ actually solve that properly. That is not a good place to be.

C was designed in the 60s, and it is very much a legacy of that timeframe. Today, there is literally no system beyond hello world you can build that won't require hash tables galore.

The web is full of those (response and request headers, query string parameters), data formats (JSON is basically a hashtable plus some fancy pieces) , caches (that are just hash tables), etc.

ddevault14• 4 years ago

You were able to "get away" with implementing a pretty bare bone thing, but you called it out as something that should be viable in general.

I can see how you had this impression from the language of the blog post, but what I meant to express is that the approach generalizes, even if this specific code does not.

The web is full of those (response and request headers, query string parameters), data formats (JSON is basically a hashtable plus some fancy pieces) , caches (that are just hash tables), etc.

The web generally falls well outside of the target use-cases for Hare.

eptcyka2• 4 years ago

There are three key problems: finding a good way of hashing arbitrary data structures (or arbitrarily limiting the kinds of keys the map can store), finding a good way of determining equality of arbitrary data structures, and dealing with memory allocation semantics.

It's not unheard of or unreasonable to have collections that have take an allocator as an argument. And a comparator and a hash function as arguments.

I think adding generic types and/or a notion of an interface might increase the complexity of the language, but it will also become far more expressive. And yes, these are tools that are sharp and require caution, especially when designing a standard library - you want to think hard about the constraints you'd impose on the consumers of your standard library when picking which interfaces require what methods etc, but I still think that there's not much to gain from a language without these features when compared to C.

ddevault14• 4 years ago

Aye, we would have probably gone with a design similar to what you suggest... if we had generics, but we do not. Generics simply don't fit with the core values of the language. I still believe that there is room for languages without them.

rootlocus3• 4 years ago

We recognize the value in this feature and have tried to come up with a good way of doing it that fits within the design constraints of the language, but it has several design issues. Recall that Hare is designed to be similar to C in terms of scope and goals.

This sounds like the language inherits all the limitations of C and isn't able to provide sufficient expressivity to solve problems that you yourself consider valuable (which aren't that many considering the niche scope). People move away from C because of these limitations, how do you expect they would choose Hare as a replacement?

ddevault14• 4 years ago

It does inherit some of the limitations of C, but in exchange, it also inherits much of the power. The trade-offs are similar to C, which is desirable in many cases. But, you may be working under different constraints, in which case you may be better off with another language - which is totally fine!

nynx5• 4 years ago

It’s unfortunate that people are trying to revive a better version of the past, when the world has moved on and the past ultimately really wasn’t that great.

C is a terrible language for building things in the modern world. Not including the progress over the last 4 decades in your new language is a mistake.

hypeatei• 4 years ago

Agreed, I don't know how writing anything in C today would be considered a productive use of time besides low level / embedded work.

nynx5• 4 years ago

Even in the embedded world, it’s becoming less justifiable to use C when your platform supports rust.

flyingfences3• 4 years ago

besides low level / embedded work

And this is where Hare is meant to be used, is it not?

turminal3• 4 years ago

Sorry, but I can't agree with the take that Hare doesn't include the progress over the last 4 decades. Sure, it doesn't include every new development, but that's impossible anyway unless you're fine with being a kitchen sink language.

nynx5• 4 years ago

It is great that Hare has tagged unions and non-nullable types, but polymorphism has been a huge part of language advancement.

duped4• 4 years ago

It's easy to flame young language projects, I don't find that compelling. I don't find the original description compelling either but that's not to say there won't be some kind of support for generic programming or correct hash tables in their standard library (with all the bells and whistles that you need, like randomized insertion order, reasonably fast performance, perhaps optimization for ordinal keys like a btree).

What does throw me off about some language projects is the rejection of "complexity" either in a compiler implementation or language feature because it is "complex" - despite decades of research and experience in other languages that some of those features are actually super useful (and also ways to get them wrong or right!). I'm not sure if this is where Hare has landed on generic programming, but it's an ethos I see in a lot of "C but not C" languages that I don't think is a sound approach to language design.

roxaaaane• 4 years ago

It's 2022

_trackno52• 4 years ago

I don't get this guy. He's just raging.

I agree a hashmap is not simple and Hare's post is a bit naive, but I don't get what's his problem with the language not providing a default implementation. It's part of the language's design. It's targeting people that most likely won't need a hash table. It's not aiming to be a high-level batteries-included language like Java.

MattPalmer1086• 4 years ago

I've been doing some work in C for the first time in a long time.

I'm constantly going back to Java to try things out, just because of the absence of convenient data structures. It's a pain to keep recreating them unless it's necessary.

AshamedCaptain• 4 years ago

I think that even the mere fact that there are a billion implementations of a hashmap kind of implies that a hash table _is_ a simple data structure, that you may complicate in a bazillion ways in order to cater for some specific usecase / requeriment. But at it's core, a simple data structure.

Chris2048• 4 years ago

Why assume that? The specific points in the post appear to be common to all implementations: implementing hashing for example.

_trackno52• 4 years ago

Fair point. I agree with you on that.

remus• 4 years ago

Maybe it's just the problems I work on and the code I write, but I use hash maps all over the place. Having to write my own sounds like a total pain in the ass, it'll almost certainly not be as performant and/or have some subtle bugs to figure out.

I guess Im not the target audience for the language, but the lack of basic data structures like this adds a lot of friction for me.

skitter• 4 years ago

The problem is less that it doesn't provide an implementation, but more that it doesn't allow anyone else to provide an implementation either (aside via code generation).

dathinab2• 4 years ago

it can't be understated how insanely hard it is to get maps right and that not getting them right (e.g. not having them or problematic implementations) is prone to produce subtle security vulnerabilities in large projects. Most times DoS attack vector not cought by normal (D)DoS protection (especially with micro services they can be nasty).

flohofwoe• 4 years ago

This reads like a rant of a person caught too much in their own bubble, a bubble in which hash maps seem to be of extreme importance. I've coded a lot of C in the past few years, and I can count the number of times when I would have actually needed a proper high performance hash map with all bells and whistles on one hand. A piece of code where hash map lookups are so frequent that it becomes a performance bottleneck is either badly designed, or a special case which needs a very careful implementation.

Builtin hash maps are convenient for "dictionary languages" like Python or Javascript, but beyond that they are highly specialized and tailored to specific data sets and hardware properties.

carapace• 4 years ago

I knew a guy who only used PHP (and a little JS) and he literally did not know the difference between hash maps, linked lists, and arrays. The SOB is a millionaire now.

BitterAmethyst• 4 years ago

The author writes database engines.

thrower123• 4 years ago

We seem to be very worked up over a virtually unknown new C-replacement language that's more likely than not to fizzle and become yet another 0.1% also-ran.

ATsch• 4 years ago

I feel like people are less getting worked up over Hare itself, and more what it represents. It is very much a reactionary language, defined less by any grand new ideas or visions and more by rejection of things that many people see as valuable progress over the last few decades. It doesn't help that it is being pushed by an already highly notable and controversial figure. The language just happens to be a convenient vehicle for arguing about these engineering (and personal) values.

tialaramex3• 4 years ago

Yesterday, while reading about Hare, I discovered the problem this blog post alludes to (Hare's own module code just assumes if the hash for two modules was identical, they're the same module) and I reported it to Hare's developer list.

https://lists.sr.ht/~sircmpwn/hare-dev/%3C20220503143516.19e...

I was sort of expecting Drew to... fix it? I mean, what you'd hope for is an updated blog post with a mea culpa in it, but I'm not setting my expectations so high. Fixing the bug seems like a pretty basic place to start though.

ddevault14• 4 years ago

Thanks for the email - yours is one of 46 emails in my Hare queue, which is why it has not been addressed yet. I agree with your comments and have filed a ticket to address them, however, and I will answer your email in time. Thanks for your patience!

urschrei• 4 years ago

Is it too late to rename the language to Ostrich?

socialdemocrat• 4 years ago

Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist.

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.

jolux6• 4 years ago

We don’t need more memory-unsafe languages with no generics and no functional programming. We just don’t. If it were a toy project for learning and pedagogical purposes that’s one thing but for code that’s supposed to be used in production it’s useless.

amelius2• 4 years ago

Not sure what you mean. Rust has no functional programming either ...

samhw2• 4 years ago

for code that’s supposed to be used in production it’s useless

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.

turminal3• 4 years ago

What, in your opinion, does functional programming bring to the table for writing things Hare is designed for?

capableweb4• 4 years ago

You sure speak surely about "us" like there is just one group of programmers out there. Some people love JavaScript, some people love C. Some people only use programming languages, some create new ones.

Live and let live, don't tell others what they need.

tayistay• 4 years ago

This point has been made so many times that it gets tiresome. Perhaps that's ok, but it doesn't really tell us anything new.

wheelerof4te12• 4 years ago

Why do you feel the need to mention functional programming in a thread about a clearly structured, systems programming language?

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.

HL33tibCe73• 4 years ago

If the author of Hare didn't want feedback on his language, or didn't want other people to use his language, he shouldn't have advertised it in blog posts and on sites like https://harelang.org/, which is clearly an advertisement for the language. As it happens, he has.

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.

lijogdfljk• 4 years ago

Also early on in the language seems a great time to respond to feedback. 3 years in when it has traction is terrible, heh.

mariusor2• 4 years ago

So what you're saying is basically: "he's asking for it", right?

jmmv2• 4 years ago

Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it.

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.

sounds• 4 years ago

But why be the one to shoot it down?

If the industry makes mistakes, that's not news.

BaculumMeumEst11• 4 years ago

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.

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.

gwern• 4 years ago

I call this 'bitcreep' (https://www.gwern.net/Holy-wars): the mere existence of a language or library will make coordination harder and gradually impose costs on the rest of the world and form a little bit of a gravity well sucking everyone towards it, for better or worse. If there are network effects and gains from networks, then there are likely anti-network effects and losses from splitting networks...

this_is_eline• 4 years ago

I don't agree with this. 'Important' software, like something you would want/need for your server, is not 'important' enough if it has a considerable amount of bugs, and therefore _will not_ be used by significant amount of people. (and will not pose a real threat to the community at large). At least not significant enough to explain all the hate authors and contributors are getting.

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.

darthcoder10102• 4 years ago

I would hate to be the creator of Hare and get so much crap for simply daring to exist.

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...

HelloNurse2• 4 years ago

A hash table that compares hashes instead of keys, doesn't support deletion, doesn't distribute keys evenly etc. is not even wrong; criticizing it is definitely not "crap for daring to exist", especially in the polite tone of the linked article.

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.

wheelerof4te12• 4 years ago

People will bash anything new that might spoil their favorite language's success.

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.

Atalocke• 4 years ago

There are probably some people who like it and find it useful.

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?

[0] https://github.com/tristanisham/color

usefulcat3• 4 years ago

The author of the TFA isn't criticizing the language, he's criticizing a particular example, and he's claiming that hash tables are generally really useful.

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.

fbanon• 4 years ago

Sounds a bit... hare-brained. :^)

jordemort• 4 years ago

I'm so bored with all this reactionary tech. I don't understand the urge to reinvent everything from first principles while ignoring the last 30 years of advances in computing. I was alive back then. Things weren't actually better.

bccdee3• 4 years ago

I think it's simple: People don't want something like Python or Java, which improves on old stuff with a big runtime, and they don't want something like Rust, which improves on old stuff with lots of complicated static checking. You can't write an OS in Python, and Rust isn't simple, which these people really want. So throw away the runtime, throw away the fancy compiler checks, and you just have a slightly nicer C.

specialist• 4 years ago

My future perfect "practical" programming language will have type inference, strong typing, and intrinsics for misc data structures. In other words, looks kinda like JavaScript, behaves kinda like Java.

This:

  foo = { "apples" : 100, "bananas" : 20 }
  bar = [ 100, 200, "oops" ] // error

Instead of this:

  foo = new hashmap<string,int>
  foo.put( "apples", 100 )
  foo.put( "bananas", 20 )
  bar = new array<int>
  bar.add( 100 )
  bar.add( 200 )
  bar.add( "oops" ) // error

I believe, but cannot yet prove, this would eliminate 98% of the (popular) pressure (desire for concision) for adding generics.

YeGoblynQueenne• 4 years ago

Is there any field or subject where people don't routinely take a dump on each other's work? Or am I just being overseinsitive, too easily vexxed?

Criticizing Hare language approach for generic data structures

Related Stories