Live data from Hacker News

The Hare programming language

harelang.org

121–130 of 323 posts

Re: The Hare programming language

#121
post #109

Earlier quoted context omitted.

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.

Hey, I'm open to any answer that helps me write better programs. :) Which languages do you have experience working with in high-performance situations? I, for one, had high hopes for using Go for video game development, but it turns out that even in highly-tuned Go code with the latest GC optimisations, there are still significant GC pauses that cannot be overcome [0]. However, perhaps you're referring to other types…

Java's ZGC as of jdk 17 has very low pause times (e.g. a p99 of roughly 0.1 ms in this benchmark[0]). Their stated goal is to remain sub 1 ms, but in practice it stays well below that.

The JVM isn't the most common game dev platform, but I have been enjoying using LibGDX with Scala on jdk 17 with ZGC.

[0] https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html

Re: The Hare programming language

#122
post #117

Earlier quoted context omitted.

> 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. We have sanitizers if you are a bad programmer, use that if you don't trust yourself

It’s just ridiculous to call someone a bad programmer over memory bugs. By your own words you are definitely a bad programmer if you have ever written more than 1000 lines of code in low level programming language, because there is simply no way you haven’t made an error. You just don’t necessarily know about it, which in my opinion makes you a worse developer, especially with this ancient and destructive mindset.

There is nothing wrong with being a bad developer, we are all bad developers if we don't understand what we are doing

We have the tools to eliminate memory bugs already

Forcing people to use a language with a buitin sanitizer/babysitter that runs everytime you compile your code and as a result makes you wait 10+ minutes between each line of change is dumb

Expecting your code to be bug free because the code written by someone else told you so is also dumb

https://github.com/rust-lang/rust/issues/38899

who to trust in that case?

--

educate and trust developers, use tools to audit your code when needed

Re: The Hare programming language

#123

lol 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…

Quoted post unavailable.

> This summarizes everything one needs to know

Your comment comes off as very dishonest. How does this quote summarize "everything I need to know". The quote you show appears to be out of context, I followed your link and that it appears to be a conclusion following a number of points explaining why, for the author, Rust's safety feature is apparently not enough to counterbalance it's flaws.

I don't fully agree with the points there (I enjoy Rust), but what does criticizing Rust have to do with "not understanding memory safety"?

Can you elaborate on why somebody has to appreciate Rust? Because I don't see it. Rust is not a religion and we shouldn't treat it as such.

Re: The Hare programming language

#124
post #117

Earlier quoted context omitted.

It’s just ridiculous to call someone a bad programmer over memory bugs. By your own words you are definitely a bad programmer if you have ever written more than 1000 lines of code in low level programming language, because there is simply no way you haven’t made an error. You just don’t necessarily know about it, which in my opinion makes you a worse developer, especially with this ancient and destructive mindset.

There is nothing wrong with being a bad developer, we are all bad developers if we don't understand what we are doing We have the tools to eliminate memory bugs already Forcing people to use a language with a buitin sanitizer/babysitter that runs everytime you compile your code and as a result makes you wait 10+ minutes between each line of change is dumb Expecting your code to be bug free because the code written by…

Sanitizers can only show you some memory problems that happen during a given runtime with given data.

And your 10+ minutes baseless assumption is just demonstratively false. In the default debug mode it is literally instant with human perception on my current, not small project. Longer compiles only happen in release mode or when you introduce new dependencies.

Shall I link you to Valgrind bugs as well?

Re: The Hare programming language

#125
post #57

lol 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.

They aren't a counterpoint at all. They're confirmation. Security-wise legacy operating systems (Linux, NT, ...) suck. New security vulnerabilities are discovered every week and month in them to the point that nobody actually considers these "multi-user systems" any more and obviously every box hooked up to the internet better be getting patches really frequently.

Re: The Hare programming language

#126
Happy to see “secretlang” out in the open! I have been following development from afar and really like the idea of a “simple” take on a language, but with a lot of wisdom and affordances added since the state of the world back in 1972. In short, Hare seems to be a language that I really should like and I want to take it for a spin.

What I find a bit confusing though is the licensing. I belong to the “BSD school”, but can at least claim that I understand (and respect) how GNU looks at things. Looking at Hare’s licensing [1], I am somewhat stumped and my usual modes of thinking no longer apply. What is the threat that warrants this level of complexity? A commercial fork? A community fork? Proprietary drivers? Are these really realistic enough threats to warrant this level of license complexity rather than just stamping ISC and CC-BY on the whole thing and not worry about forks at all? Yes, there is some writing in the README, but perhaps I am too thick to “get it”?

[1]: https://git.sr.ht/~sircmpwn/hare#licensing

Lastly, a sanity check, am I reacting too strongly to this if I feel that it has a bit of chilling effect in terms of my excitement?

Re: The Hare programming language

#127
post #57

Earlier quoted context omitted.

While any modern operating system is the living counter point, so far it's manageable.

Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument. It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1]) [1] https://github.com…

Redox is probably a better example than Hubris:

https://www.redox-os.org/

Hubris is intended to run on microcontrollers in a very low-level context (e.g. no display), so is very unlikely become a desktop / user-facing OS.

(I work at Oxide, mostly writing Hubris code)

Re: The Hare programming language

#129
post #124

Earlier quoted context omitted.

There is nothing wrong with being a bad developer, we are all bad developers if we don't understand what we are doing We have the tools to eliminate memory bugs already Forcing people to use a language with a buitin sanitizer/babysitter that runs everytime you compile your code and as a result makes you wait 10+ minutes between each line of change is dumb Expecting your code to be bug free because the code written by…

Sanitizers can only show you some memory problems that happen during a given runtime with given data . And your 10+ minutes baseless assumption is just demonstratively false. In the default debug mode it is literally instant with human perception on my current, not small project. Longer compiles only happen in release mode or when you introduce new dependencies. Shall I link you to Valgrind bugs as well?

> And your 10+ minutes baseless assumption is just demonstratively false

Ok, not 10+ minutes, more like 6 minutes on a beefy machine:

https://www.youtube.com/watch?v=nR2WDBMjkh8&t=976s

> Shall I link you to Valgrind bugs as well?

See, you fail to understand the point

Re: The Hare programming language

#130
post #126

Happy to see “secretlang” out in the open! I have been following development from afar and really like the idea of a “simple” take on a language, but with a lot of wisdom and affordances added since the state of the world back in 1972. In short, Hare seems to be a language that I really should like and I want to take it for a spin. What I find a bit confusing though is the licensing. I belong to the “BSD school”, but…

I think you are reacting too strongly. Really, what's the problem?
Post reply on HN