The Hare programming language • Hacker News Board

Re: The Hare programming language

#101

Post by pwdisswordfish9 » Mon, Apr 25, 2022, 11:10 AM UTC

turminal wrote: post #87

jpe90 wrote: post #84

Since the language is officially announced now, here's an interesting analysis on the language: https://tilde.team/~kiedtl/blog/hare/ Personally I'm very interesting in playing with it. Generics, functional programming constructs, and a lot of the syntactic sugar you find in modern languages have their uses but I think there's a lot of merit to the idea that you might not want them in a systems language. I think clea…

> Since the language is officially announced now, here's an interesting analysis on the language: https://tilde.team/~kiedtl/blog/hare/ Just a reminder (since I can't see a date in the blog post) that this was written almost a year ago. Lots of things have changed in the language since then.

Hare has generics now?!?!

Because to me it looks like the bulk of the criticism remains substantially relevant.

Re: The Hare programming language

#102

Post by the_duke » Mon, Apr 25, 2022, 11:13 AM UTC

turminal wrote: post #34

staticassertion wrote: post #22

Earlier quoted context omitted.

I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well. That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table. > but the argument that we're morally in the wrong to prefer another approach is not really appreciated. Well, sorry to hear i…

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

If that is the recommendation, maybe the standard library could focus on easily spawning and coordinating multiple processes instead, with very easy to use process communication.

Re: The Hare programming language

#103

Post by zozbot234 » Mon, Apr 25, 2022, 11:14 AM UTC

anonymoushn wrote: post #91

the_duke wrote: post #82

Earlier quoted context omitted.

I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design. Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a…

Making the Rust ownership model central to the core language and standard library has meant that after 11 years of Rust, your program still can't have two objects of the same type owned by different allocators. As a result, I am interested in other approaches to these problems.

Local allocators are being standardized. This has nothing to do with the Rust ownership model, C++ took a long time to standardize an allocator abstraction too.

Re: The Hare programming language

#104

Post by vladharbuz » Mon, Apr 25, 2022, 11:14 AM UTC

FrozenVoid wrote: post #95

Lack of macros in recent systems languages like Zig/Hare/etc seems to be a design flaw, a handicap marketed as safety feature or bargain for clarity. If a language can't replace C macros, it cannot replace C.

Could you expand on this? I'm really curious why you think so. I have written and worked with C codebases that do quite well without using macros at all.

Re: The Hare programming language

#105

Post by veltas » Mon, Apr 25, 2022, 11:18 AM UTC

C replacements always seem to have noisier syntax, and not nearly enough motivation to switch from C. And if I could have been tempted with templates and a more intelligent type system I would have switched to a restricted C++ subset years ago.

And yes macros are dirty, but yet they're often far simpler than the alternatives, based on how languages like C++, Zig et al have attempted to reduce them.

Re: The Hare programming language

#106

Post by BaculumMeumEst » Mon, Apr 25, 2022, 11:18 AM UTC

FrozenVoid wrote: post #95

Lack of macros in recent systems languages like Zig/Hare/etc seems to be a design flaw, a handicap marketed as safety feature or bargain for clarity. If a language can't replace C macros, it cannot replace C.

What necessary use case of macros isn’t addressed by comptime in zig?

Re: The Hare programming language

#107

Post by eatonphil » Mon, Apr 25, 2022, 11:22 AM UTC

the_duke wrote: post #96

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

The problem here is that focusing on a language can lead to lots of small API design decisions that make it very cumbersome to support other systems later without significant breaking changes. I can appreciate the ideological and practical purity of that decision, but even Linux aficionados need to deploy code to other operating systems to make a living.

I don't have data to support it but even for Go, a language that does support macOS and Windows, it does not feel like the stdlib is as mature or performant as the Linux version. I don't have numbers for that yet just observations doing simple benchmarks across Linux, macOS and Windows.

Some languages are just clearly designed to be used on the server.

Re: The Hare programming language

#108

Post by the_duke » Mon, Apr 25, 2022, 11:27 AM UTC

sanxiyn wrote: post #88

the_duke wrote: post #82

Earlier quoted context omitted.

I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design. Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a…

> Otherwise, what's the point? Hare seems to solve spatial memory safety and null safety, which I think is a big deal.

Better than C is certainly a step up, but in my opinion also solving temporal safety must be a goal for a new language in this space.

Re: The Hare programming language

#109

Post by kaba0 » Mon, Apr 25, 2022, 11:32 AM UTC

vladharbuz wrote: post #33

staticassertion wrote: post #27

Earlier quoted context omitted.

I hear you, but I think the problem is that you're framing this as "I, the developer, don't want to accept these costs". And that's fine when the software doesn't leave your system. The problem is that you're them pushing other costs onto your users ie: exploitable software. So from the developer perspective, great, it works for you, but the cost is there. I'm sympathetic to not wanting to use the other languages ava…

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…

I’m sure it is not the answer you want to hear, but partial use of GCs seems to be exactly that. Modern GCs have insanely good throughput OR latency.

Quite a few languages have value types now, with that you can restrict your usage to stack allocations for the critical hot loops, while low-latency GCs promise less pauses than the OS itself, which should be plenty good for even the most demanding games.

Re: The Hare programming language

#110

Post by kaba0 » Mon, Apr 25, 2022, 11:38 AM UTC

turminal wrote: post #47

zozbot234 wrote: post #45

Earlier quoted context omitted.

> C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. It really isn't. Not compared to C++, at least. Or to managed language runtimes, which are just as "large and complicated", only beneath the hood.

It's certainly much more complicated than Go, and not just on the surface

But they are nowhere near the same niche. Go is much much closer to JS than to Rust by design, it just mimics being lower-level.

System level programming almost by definition requires quite a bit of complexity, and you can’t hide it no matter how elegant your abstraction is. Essential complexity is non-reduceable: