Hacker News Reader

Comment by atiedebee | Hacker News Reader

I recently dabbled in "hare" which was quite a nice experienced.

I liked how the language stayed pretty simple compared to other C-replacements. The standard library is also pretty nice. It is however an extremely niche language, but still quite capable

View on HN

I really like the design choices they've made. Namely:

- Once you cut out the legacy nonsense out of C, you can then add a few nice modern features to your language and still end up with something that's smaller and simpler than C.

- Performance optimizations are possible. But by default, simplicity is always picked over performance. (i.e. most UB is eliminated, even if it hurts performance)

- A few basic pointer features go a long way in eliminating memory most memory safety bugs. There are non-nullable pointers, ranges with automatic bound checks, and no C strings.

- They get a lot of mileage out of their tagged union type. It allows for elegant implementations of algebraic types, polymorphism, and error handling.

- The error handling!

I was pretty excited about Hare until Devault said that Hare wouldn't be doing multithreading as he preferred multiprocessing. That was a pretty big dealbreaker for me. The rest of the language looks quite clean though!

hare-ev [0] is using epoll under the covers, which means multithreading is there, already. Especially as ev may be merged into the stdlib at some point.

[0] https://git.sr.ht/~sircmpwn/hare-ev

Maybe I'm misunderstanding something, but it seems like ev is still multiprocessing? Reading the code, it looks like you can read/write to files, and if you want to kick off some other work it spawns a process. I don't see any instance of threads there.

epoll is threaded, not multiprocess. [0]

hare-ev is using rt to make the epoll syscalls. [1]

> On Linux, ev is implemented with epoll. Note that, on Linux, I/O on regular files is always blocking.

[0] https://www.man7.org/linux/man-pages/man7/epoll.7.html

[1] https://docs.harelang.org/rt#SYS_epoll_create

> epoll is threaded, not multiprocess

epoll is orthogonal to threads. It _can_ be used in a multithreaded program, but it doesn't have to be. It may very well be implemented in terms of kernel threads, but that's not what I'm talking about. I'm talking about user-space threads.

You could always link to pthread and use that in your Hare code, no?

Conceptually yes, but I suspect there's going to be a lot hairier in practice. For instance, I think there's some stuff that needs language support such as thread-local storage. I'd guess it would be simpler to just re-implement threading from scratch using syscalls. But I also don't think the language provides any support for atomics, so you'd have to roll your own there.

hare will not support Windows.

https://harelang.org/documentation/install/#supported-platfo...

Interesting reasons.

Makes sense

But why 8-character indents as the standard formatting for Hare programs? I notice that Odin seems to prefer 8-character indents as well. It seems like a real blow to readability for deeply nested code. Maybe you aren't supposed to write deeply nested code?

Reply on news.ycombinator.com