181–190 of 272 posts
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…
Earlier quoted context omitted.
I agree with all your points except "are actually well-designed and performant". I mean they perform well enough but when I write simple hashmaps that perform better than libstdc++ (yes with the same hash) anecdotally I don't have a lot of confidence.
Keep in mind that - those hash maps are optimized for large sets - they work around several edge cases - they implement way more features than an in-house implementation - they need to support many types of hardware A decent engineer can beat the std collections in a day on performance. But to do that in production over a decade with shifting requirements is a different ball game.
But I do believe in edge cases, I'm sure there are some pathological edge cases (that don't usually matter, but deserve consideration).
I'm interested to know what 'way more features' are for hash maps/sets, because AFAIK C++ just supports the basic features you'd expect of the abstract data structure of a "map" with the algorithmic guarantees you'd expect from a hashmap.
And nothing I did was aimed at 'specific hardware' other than it vaguely benefitted from memory locality / avoiding thrashing the cache.
Earlier quoted context omitted.
It’s also massively unsafe to drive in general, so we should probably ban the usage of cars wherever possible.
We license people to drive and have a legal system for dealing with irresponsible drivers.
Earlier quoted context omitted.
I can assure you, the automotive industry uses more C/C++ than you've ever seen. C is used precisely because it's a mature and verifiable language.
I'm not sure what your point is. I didn't claim memory unsafe languages aren't used, they obviously are. C is in fact not an easy language to verify. There have gone trillions of dollars into that and it's still not solved. You can't verify C. You might be able to verify a subset of C. But if you are in any position to choose any other language you should run, run, run quickly and far away from C.
Earlier quoted context omitted.
> 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...
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 so…
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]?"
"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" app…
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-…
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.
Earlier quoted context omitted.
Not sure what you mean. Rust has no functional programming either ...
Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.
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.
"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" app…
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.
Earlier quoted context omitted.
There is a distinct difference between PHP, JS and Hare. Hare is being developed and designed with a particular point of view by a developer and early adopters who are passionately supportive of that POV. PHP and JS were both thrown together with minimal direction and to achieve specific goals in as fast a time as possible (if I am remembering both languages begins correctly). It could be possible that another langua…
Simply, it is a bad point of view, and deserves discouragement in exact proportion to the amount of promotion it gets. He wants it both ways, and does not deserve that.
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.
Earlier quoted context omitted.
Not sure what you mean. Rust has no functional programming either ...
Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.