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