Why do people keep choosing :: over simply .? How does adding more visual noise help anyone?
The Hare programming language
51–60 of 323 posts
Re: The Hare programming language
#52I can't find any information about concurrency. Do you plan to support async/await?
No. We prefer a more traditional style with event-driven I/O, e.g. via unix::poll. This should be more familiar to C programmers than to those coming from higher-level languages with async/await constructs. https://docs.harelang.org/unix/poll You can see a small event-driven server example here: https://git.sr.ht/~sircmpwn/himitsu/tree/master/item/cmd/him... https://git.sr.ht/~sircmpwn/himitsu/tree/master/item/cmd/hi…
FWIW, frequently I've wished that languages had a version of https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html built-in for implementing iterators, like Python generators, or somewhat similar to async/await. Porting the macros to C++ suffers because switches can't jump past declaring local variables with required constructors, and my hacks around this issue were ugly and error-prone. I haven't learned C++ coroutines yet, but they seem confusing.
Re: The Hare programming language
#53I see that Hare exposes itself via the hare module in stdlib. Is there any plan for metaprogramming/macro (not preprocessor) in Hare?
No, there are no plans for first-class metaprogramming. The purpose of exposing the parser, type checker, module system, etc, in the standard library is to allow for users to more easily build custom Hare tooling. The closest thing you could get to metaprogramming with this is some assistance with code generation.
Re: The Hare programming language
#54Earlier quoted context omitted.
Not in mainstream languages. There's a lot of ongoing research in the space. Otherwise, Rust is probably the most mainstream language that achieves your goals. Games are a bit different imo. While they're often networked they tend to not get attacked the same way as other software for a variety of reasons (though some games become so popular that it becomes worthwhile, like Minecraft). If a language set out to be "sa…
Thank you for all of your feedback, I hope you end up at least trying Hare for the use cases that feel right to you! :)
I appreciate that. I really do hate to be critical of open source work. I just feel this is an important issue.
Re: The Hare programming language
#55I see that Hare exposes itself via the hare module in stdlib. Is there any plan for metaprogramming/macro (not preprocessor) in Hare?
> Is there any plan for metaprogramming/macro (not preprocessor) in Hare?
We don't plan to add anything like that. Hare strives to be simple and straightforward. Metaprogramming would not fit it well.
Closest thing in this direction that we tried was reflection, but that didn't turn out to play along with the rest of the language either, so it was removed.
Re: The Hare programming language
#56Earlier 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…
Thank you for the resources, I'll look into these details in more depth!
Re: The Hare programming language
#57lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…
While any modern operating system is the living counter point, so far it's manageable.
Re: The Hare programming language
#58Earlier quoted context omitted.
No. We prefer a more traditional style with event-driven I/O, e.g. via unix::poll. This should be more familiar to C programmers than to those coming from higher-level languages with async/await constructs. https://docs.harelang.org/unix/poll You can see a small event-driven server example here: https://git.sr.ht/~sircmpwn/himitsu/tree/master/item/cmd/him... https://git.sr.ht/~sircmpwn/himitsu/tree/master/item/cmd/hi…
FWIW, frequently I've wished that languages had a version of https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html built-in for implementing iterators, like Python generators, or somewhat similar to async/await. Porting the macros to C++ suffers because switches can't jump past declaring local variables with required constructors, and my hacks around this issue were ugly and error-prone. I haven't learned C++…
We do not have first-class iterators, but we do have an iterator pattern which is common throughout the Hare standard library. As an example, here's how you can enumerate the nodes in a directory:
let iter = os::iter("/")!;
for (true) {
const entry = match (fs::next(&iter)) {
case let ent: fs::dirent =>
yield ent;
case void =>
break;
};
fs::println(entry.name)!;
};Re: The Hare programming language
#59lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundati…
Maybe be less zealous and aware of your assumptions?
Your assumption is that memory safety has to be baked in the language. It could be baked into proof assistants that are part of (optional or add-on) tooling, like what sel4 does. A simpler language makes this more possible, and the things that a proof assistants can do go far beyond what rust is able to provide, without sacrificing compilation speed or other forms of optimality (e.g. avoiding the heap) when you don't want or need such a high level of security guarantee (e.g. writing a cli tool that never sees the internet)
As for me, I'm terrified that rusts complex macro system will hide/obfuscate discovery of other forms of security regression, like timing or energy side channels.