Criticizing Hare language approach for generic data structures • Hacker News Board

Re: Criticizing Hare language approach for generic data structures

#221

Post by pjmlp » Wed, May 04, 2022, 7:25 PM UTC

User23 wrote: post #206

eatonphil wrote: post #192

Earlier quoted context omitted.

You can't even call a non-Go library without switching to cgo, which contradictorily basically everyone says not to use. Leaving aside the GC, until Go has a real FFI it's hard to to imagine it being a really great fit for systems programming when the systems are all not written in Go.

Go is not a traditional systems programming language and calling it one is misleading at best and maybe even borderline dishonest. Two big problems are the lack of control of memory layout and the lack of some form that compiles down to a computed goto. It’s just not possible to write performant systems code without those. I’m not bashing Go though. I appreciate the focus on readability among other things. It’s a fin…

https://www.withsecure.com/en/solutions/innovative-security-...

I guess the Genera, Xerox PARC, ETHZ, Microsoft folks are borderline dishonest.

Re: Criticizing Hare language approach for generic data structures

#222

Post by ncmncm » Wed, May 04, 2022, 7:48 PM UTC

BaculumMeumEst wrote: post #209

rowanG077 wrote: post #172

Earlier quoted context omitted.

Driving also brings great value. Using C over another language "Because you can't tell me what to do" does not. The more apt comparison would be if we had fully self driving cars that are proven to make almost no mistakes. And then still wanting to drive a car yourself on public roads, endangering yourself and others.

C and C++ still see overwhelming usage in many industries because of the business value they provide in terms of performance and how quickly you can produce software in it. That does not seem likely to change any time soon- game studios are not widely adopting rust, for example, and I don't expect that to change, even though they impact a MASSIVE amount of people. Hare's value proposition is simplicity- which allows…

C and C++ are at diametric opposite ends of the scale of value proposition. Listing them side by side eliminates any credibility your argument might have had.

Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.

Re: Criticizing Hare language approach for generic data structures

#223

Post by ncmncm » Wed, May 04, 2022, 7:58 PM UTC

flyingfences wrote: post #163

rowanG077 wrote: post #152

Earlier quoted context omitted.

Because software is generally written so that people use it. Memory unsafe languages have proven it's impossible to write secure software in, even by the best of the best developers. That's why I made the comparison with seatbelts. If you want to drive your car on public roads(deliver production software to users) you are not allowed to use memory unsafe languages(you must use a seatbelt). If you just make software f…

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.

There is no such language as C/C++. Your statement is meaningless, as stated.

Re: Criticizing Hare language approach for generic data structures

#224

Post by ncmncm » Wed, May 04, 2022, 8:02 PM UTC

nynx wrote: post #40

hypeatei wrote: post #30

Earlier quoted context omitted.

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

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

Any platform that supports C supports C++. Rust might be a hard sell, but C++ offers all of its plausible benefits.

Re: Criticizing Hare language approach for generic data structures

#225

Post by CyberRabbi » Wed, May 04, 2022, 8:05 PM UTC

MrBuddyCasino wrote: post #28

formerly_proven wrote: post #2

"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…

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.

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.

Re: Criticizing Hare language approach for generic data structures

#226

Post by BaculumMeumEst » Wed, May 04, 2022, 8:28 PM UTC

ncmncm wrote: post #222

BaculumMeumEst wrote: post #209

Earlier quoted context omitted.

C and C++ still see overwhelming usage in many industries because of the business value they provide in terms of performance and how quickly you can produce software in it. That does not seem likely to change any time soon- game studios are not widely adopting rust, for example, and I don't expect that to change, even though they impact a MASSIVE amount of people. Hare's value proposition is simplicity- which allows…

C and C++ are at diametric opposite ends of the scale of value proposition. Listing them side by side eliminates any credibility your argument might have had. Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.

I mentioned performance and game development specifically. I'm sure you're aware that it's common to write C++ that's very close to C while taking advantage of few features of C++. I don't think it's fair to call that the "diametric opposite of C".

Your opinion of Hare's view of simplicity is your opinion. Any software effort has some amount of essential complexity, in my experience many languages and tools quite a bit of incidental complexity that could be avoided.

Re: Criticizing Hare language approach for generic data structures

#227

Post by ncmncm » Wed, May 04, 2022, 8:35 PM UTC

BaculumMeumEst wrote: post #226

ncmncm wrote: post #222

Earlier quoted context omitted.

C and C++ are at diametric opposite ends of the scale of value proposition. Listing them side by side eliminates any credibility your argument might have had. Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.

I mentioned performance and game development specifically. I'm sure you're aware that it's common to write C++ that's very close to C while taking advantage of few features of C++. I don't think it's fair to call that the "diametric opposite of C". Your opinion of Hare's view of simplicity is your opinion. Any software effort has some amount of essential complexity, in my experience many languages and tools quite a b…

You can write bad code in any language. (We used to say "you can write FORTRAN code in any language", back when.) C code compiled with a C++ compiler is C, and bad. With the C compiler, you had no choice. You do not get that excuse when you have a C++ compiler.

Avoiding unnecessary complexity is everybody's responsibility. Dumping every last bit of unavoidable complexity onto the programmer where it has been long demonstrated that tooling can take care of much of it is simply irresponsible, and inexcusable.

I do not excuse it.

Re: Criticizing Hare language approach for generic data structures

#228

Post by staticassertion » Wed, May 04, 2022, 8:47 PM UTC

BaculumMeumEst wrote: post #205

staticassertion wrote: post #201

Earlier quoted context omitted.

The most common for companies to have/ be required to have. > I've worked in defense and there are stringent security requirements for applications and servers. Like? FEDRAMP? The vast majority of compliance is about threat modeling and access controls.

> Like? FEDRAMP? No, STIGs. > The vast majority of compliance is about threat modeling and access controls. If compliance doesn't address security, that sounds like a bigger issue than a new hobby language existing.

The issue is that no one is taking responsibility for writing safe software. Compliance / regulation isn't, developers aren't either.

Re: Criticizing Hare language approach for generic data structures

#229

Post by gwern » Wed, May 04, 2022, 8:50 PM UTC

jmmv wrote: post #128

socialdemocrat wrote: post #100

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…

> 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,…

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

Re: Criticizing Hare language approach for generic data structures

#230

Post by tialaramex » Wed, May 04, 2022, 9:30 PM UTC

ahmedalsudani wrote: post #105

veltas wrote: post #57

Earlier quoted context omitted.

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

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-designe…

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

The STL doesn't allow the containers to be "well-designed and performant" other than std::vector which is trivial. People do what they can, but there just isn't much to work with because random coincidences about the data structures that were in mind at the time are enshrined in the C++ standard as API features.

std::unordered_map is obliged to be a bucketed map. This is a poor choice, but it's not optional because it's enshrined in the API even though you probably don't (and shouldn't) actually rely on this. Lots of the good options are drop-in replacements for std::unordered_map... unless you really depend on it being a bucketed map.

The other important thing to know if you've been relying on the standard library is that the powerful need for backward compatibility means it's not going to give you a proper hash, which is important for a proper hash map. std::unordered_map doesn't care that the standard "hash" provided isn't, but if you use a hash map written by people who explicitly told you to use an actual hash it's going to exhibit jaw-droppingly bad performance until you do so.

std::unordered_map isn't worse than a reasonably competent person's "my first hash table" but it's disappointing how little better it is than that after decades.

As with all performance, if you aren't measuring then changes are just wanking, but if you are measuring you will almost certainly find that swapping out std::unordered_map is worth doing.