"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?
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.
"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.
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.
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.
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.
> 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.
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.
> 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?
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.
> 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...
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.
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.
> 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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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).
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.
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.
> 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?
> 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.
> 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.
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.
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.
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.
[+] [-] formerly_proven|3 years ago|reply
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.
[+] [-] one-more-minute|3 years ago|reply
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.
[+] [-] wheelerof4te|3 years ago|reply
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.
[+] [-] MrBuddyCasino|3 years ago|reply
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.
[+] [-] ddevault|3 years ago|reply
[+] [-] socialdemocrat|3 years ago|reply
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.
[+] [-] jmmv|3 years ago|reply
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.
[+] [-] HL33tibCe7|3 years ago|reply
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.
[+] [-] Atalocke|3 years ago|reply
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
[+] [-] jolux|3 years ago|reply
[+] [-] darthcoder1010|3 years ago|reply
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...
[+] [-] usefulcat|3 years ago|reply
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.
[+] [-] grnmamba|3 years ago|reply
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.
[+] [-] veltas|3 years ago|reply
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".
[+] [-] nynx|3 years ago|reply
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.
[+] [-] turminal|3 years ago|reply
[+] [-] hypeatei|3 years ago|reply
[+] [-] thecompilr|3 years ago|reply
[+] [-] turminal|3 years ago|reply
[+] [-] samatman|3 years ago|reply
[+] [-] gradschool|3 years ago|reply
[+] [-] flohofwoe|3 years ago|reply
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|3 years ago|reply
[+] [-] BitterAmethyst|3 years ago|reply
[+] [-] rieTohgh6|3 years ago|reply
[+] [-] eatonphil|3 years ago|reply
[+] [-] _trackno5|3 years ago|reply
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.
[+] [-] jordemort|3 years ago|reply
[+] [-] bccdee|3 years ago|reply
[+] [-] thrower123|3 years ago|reply
[+] [-] ATsch|3 years ago|reply
[+] [-] tialaramex|3 years ago|reply
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.
[+] [-] ddevault|3 years ago|reply
[+] [-] dathinab|3 years ago|reply
[+] [-] guerrilla|3 years ago|reply
[+] [-] ddevault|3 years ago|reply
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.
[+] [-] rootlocus|3 years ago|reply
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?
[+] [-] lifthrasiir|3 years ago|reply
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.
[+] [-] eptcyka|3 years ago|reply
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.
[+] [-] duped|3 years ago|reply
[+] [-] ayende|3 years ago|reply
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.
[+] [-] specialist|3 years ago|reply
This:
Instead of this: I believe, but cannot yet prove, this would eliminate 98% of the (popular) pressure (desire for concision) for adding generics.[+] [-] YeGoblynQueenne|3 years ago|reply
[+] [-] roxaaaane|3 years ago|reply
[+] [-] urschrei|3 years ago|reply
[+] [-] newaccount2021|3 years ago|reply
[deleted]
[+] [-] bjarneh|3 years ago|reply
[deleted]