Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hare programming language

harelang.org

Post reply on HN
Print view View original

281–290 of 323 posts

Re: The Hare programming language

#281

Post by nine_k »

wheelerof4te wrote: post #275
throw10920 wrote: post #203

Earlier quoted context omitted.

> they don't seem to have any form of comptime logic Or macros, not even textual C-style ones. Non-starter for me.

Macros were one of the biggest mistakes that C allowed, along with the undefined behavior. Not allowing macros means a more standardized reference implementation, which translates to a more readable code overall.

Simple textual substitution macros are indeed pain.

Nicer, AST-level macros can be better, but can also be a pain (see Lisp, C++ for examples of either).

Re: The Hare programming language

#282

Post by nickitolas »

wheelerof4te wrote: post #274
Shadonototra wrote: post #257

Earlier quoted context omitted.

>> Not supporting Windows and macOS will likely hurt the adoption of the language. > Not among our target audience it won't. No gamedev?

You can develop games just fine on Linux.

Yes, by targeting wine/proton/win32

Re: The Hare programming language

#283

Post by astrange »

nyanpasu64 wrote: post #44
vladharbuz wrote: post #33

Earlier quoted context omitted.

I think I understand your view better now. Are you aware of any current memory management strategies (implemented as part of a language or otherwise) that perform well in situations with high performance requirements? For example, as someone who works on video games and real-time audio, most options seem non-starters to me aside from Rust, even if I decided to make sacrifices for the sake of security, and I at least…

Not staticassertion, but I'm a hobbyist in real-time audio. I like Rust as a vocabulary for describing/teaching safe programming (&/&mut/Send/Sync). I find that multithreaded programs written in Rust are usually correct while multithreaded programs written in C++ are usually wrong, because Rust encodes the rules of shared-memory threading in its type system (&T: Sync objects are thread-shared, but are either immutabl…

> On an aesthetic/principled level, I'd rather punt alias analysis to the programmer (pointer/restrict or &/&mut) rather than compiler complexity/magic (TBAA and provenance checking).

That would certainly be nice, but the state of the art on what problems even are is far ahead in optimizing compilers than anyone else - "having a restrict keyword" doesn't solve every aliasing problem afaik, and nobody respects the performance people when they tell you undefined behavior in C is actually useful. So nobody has come up with a simple solution for a better language that solves problems like pointer provenance and yet is "faster than C".

Actually most people's ideas of how to make programs faster are complicated things like autovectorization that don't work and would make it slower.

Re: The Hare programming language

#284

Post by astrange »

AnimalMuppet wrote: post #218
throw10920 wrote: post #210

Earlier quoted context omitted.

"How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." It's much better to push logic from being manually re-written over and over by tens of thousands of different programmers, to being built into a language/tool/library by a team of a few hundred experts and then robustly tested.

> "How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." Nope, doesn't work. Then you have to trust that the programmer who wrote the assembler didn't make any mistakes. Real programmers program in octal.

> Then you have to trust that the programmer who wrote the assembler didn't make any mistakes.

This is true, but the actual solution is safer assembly. ARM is heading in this direction with PAC/BTI/CHERI. Intel, being Intel, tried adding some and it was so broken they removed it again.

It could go much further.

Re: The Hare programming language

#285

Post by astrange »

the_duke wrote: post #102
turminal wrote: post #34

Earlier quoted context omitted.

> I think developers should feel a lot more responsibility in this area. I think most programmers would agree with that sentiment. Getting everyone to agree on what is "responsible" and what isn't however... Hare is a manifestation of the belief that in order to develop responsibly, one has to keep their software, and their code, simple. An example of what I mean by this: An important feature of Rust is the use of co…

Single threaded development seems a noteworthy goal, and I partially agree that it often leads to much simpler code and works well in systems like Erlang. But it is also a questionable focus in the days of barely increasing single core performance, especially in a systems language. I believe one of the reasons Rust got so popular is that it made concurrency much easier and safer right at a time where the need for it…

Unfortunately you can't make things faster by making them concurrent, at least not in the way computers are currently designed. (And they're probably designed near-optimally unless we get memristors.) In my experience it's the opposite; you can make concurrent programs faster by removing it, because it adds overhead and they tend to wait on nothing or have unnecessary thread hops. And it makes them more power efficient too, which is often more important than being "faster".

Instead you want to respect the CPU under you and the way its caching and OoO instruction decoding work.

Re: The Hare programming language

#288

Post by astrange »

ddevault wrote: post #238
boardwaalk wrote: post #234

Earlier quoted context omitted.

Honestly that really kills my interest I have in the language. That’s not realistically going to happen (a reimplementation) or go well (maintaining a fork) with a (frankly) niche language. I suspect the pool of people who develop locally (on Win or Mac, and need something functional if not optimal) and deploy to Linux is not small. Is there a particular reason? io-uring?

As other commenters alluded to, it's an ideological and practical decision. We simply prefer free software operating systems. We do not care to legitimize nonfree platforms, and we prefer to be able to read (and patch) the code to understand the tools we depend on. If that's a deal-breaker for you, no worries - Hare does not have to appeal to everyone to achieve its goals.

This may lead the design to be inappropriately coupled to ELF, which isn't the best binary format in the world or anything. There are real differences in MachO and PE.

Re: The Hare programming language

#290

Post by bscphil »

metaltyphoon wrote: post #176
ddevault wrote: post #28

Earlier quoted context omitted.

> Not supporting Windows and macOS will likely hurt the adoption of the language. Not among our target audience it won't. > Anyway, is it possible to target bare-metal with Hare? Is it possible to use it without the standard library? Yes. Here are two kernels written in Hare that don't use the stdlib: https://git.sr.ht/~sircmpwn/helios https://git.sr.ht/~yerinalexey/carrot

> Not among our target audience it won't. Yes it will. I have no interest in using Linux as desktop but I do use it for deployments. If there is one trait of major PL is the adoption of the big 3 OSes. This is Hare’s biggest flaw right now.

> I have no interest in using Linux as desktop

It sounds like you're not the target audience then?

Post reply on HN