I don't see any explanation of why this language exists. Does it do something better than any other language?
[deleted]
The Hare programming language
11–20 of 323 posts
Re: The Hare programming language
#12Earlier quoted context omitted.
Hare is much simpler than Zig and has a much different design, things like Zig's comptime is absent in Hare. Hare also has, in my opinion, a more fleshed out standard library than Zig. However, they don't compete in some respects: Zig targets nonfree platforms like Windows and macOS, and being based on LLVM gives Zig a greater range of platforms/architectures OOTB. Andrew might be able to expand on this.
Gotcha. One thing that I really liked about Zig is its effortless interop with C. How does Hare compare in that regard?
Hare uses a superset of the C ABI and interop with C should be relatively straightforward. You can see an example with SDL2 here:
https://git.sr.ht/~sircmpwn/hare-examples/tree/master/item/s...
We have some planned improvements which will make this easier still. We'd like to improve the build driver's ability to link with C libraries via pkg-config, and automatically rig it up when you depend on C interop modules like hare-sdl2. Code generation to automatically provide bindings going either direction is also something we'd like to work on.
Zig goes, imho, a little bit too far. Hare has no intention of providing a built-in C toolchain, and does not treat C as more special than any other language for interop. It's a question of scope.
Re: The Hare programming language
#13Why is opening file in "os" namespace but closing file in "io" namespace?
The I/O namespace provides an I/O abstraction that only knows about I/O operations, like read and write, rather than I/O objects.
There's also an "fs" module which provides a filesystem abstraction:
The "os" module links these with the host operating system. It provides an implementation of the fs abstraction for the current working directory in the host filesystem, and also provides convenience wrappers like os::open, which calls fs::open with the host filesystem singleton.
Re: The Hare programming language
#14Earlier quoted context omitted.
Hare is much simpler than Zig and has a much different design, things like Zig's comptime is absent in Hare. Hare also has, in my opinion, a more fleshed out standard library than Zig. However, they don't compete in some respects: Zig targets nonfree platforms like Windows and macOS, and being based on LLVM gives Zig a greater range of platforms/architectures OOTB. Andrew might be able to expand on this.
Gotcha. One thing that I really liked about Zig is its effortless interop with C. How does Hare compare in that regard?
It's trivial for Hare programs to interop with C. All the programmer has to do is specify the libraries they want to link to.
Going the other way and calling Hare code from C is not that smooth yet, but there are plans to improve that in the future.
Re: The Hare programming language
#15[deleted]
Re: The Hare programming language
#16I can't find any information about concurrency. Do you plan to support async/await?
Re: The Hare programming language
#17Re: The Hare programming language
#18I 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/him...
Re: The Hare programming language
#19lol 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 foundation for new operating systems is... depressing. It's setting us up for another century of industry failure - buggy software that makes users less safe.
It's not to say that memory unsafe languages have no place. Toy programs, or programs not exposed at all, are fine. But that's clearly not the case here - the stated use cases are things like the OS, "networking software", etc. All of the places where C has caused incredible harm.
edit: It would be wrong not to note that Hare does consider memory safety. https://harelang.org/blog/2021-02-09-hare-advances-on-c/
There are clearly wins here, no question in my mind that a world where spatial memory safety is the default is a better world than today. It doesn't change my view overall, however, that for the use cases defined that the bar needs to be higher.
I am also compelled to say something nice about the language. Most apparent is that it looks very approachable - I have to wonder what the '!' means (I can guess), but otherwise it looks very readable. I also like the explicit nature, that's my preference for programs as well as I find it's much more readable.
I think "simplicity" can be a tricky goal, but I like seeing languages call it out as one - I'm very curious to see over the next few decades how "simple" plays out.
Re: The Hare programming language
#20lol 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…
There are plans to research an optional borrow checker for Hare. Hare also does offer many "safety" advantages over C: checked slice and array access, exhaustive switch and match, nullable pointer types, less undefined behavior, no strict pointer aliasing, fewer aggressive optimizations, and so on. Hare code is much less likely to have these errors when compared to C code.
I would ultimately just come out and say that we have to agree to disagree. I think that there is still plenty of room for a language that trusts the programmer. If you feel differently, I encourage you to invest in "safer" languages like Rust - but the argument that we're morally in the wrong to prefer another approach is not really appreciated.