141–150 of 323 posts
Earlier quoted context omitted.
Why?
Because the compiler won't let you, except under duress.
Earlier quoted context omitted.
> 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…
That’s just not realistic. We live in a complex world, and we need complex software. That’s why I vehemently hate these stupid lists: http://harmful.cat-v.org/software/ Don’t get me wrong, it is absolutely not directed at you, and I absolutely agree that we should strive for the simplest solution that covers the given problem, but don’t forget that essential complexity can’t be reduced. The only “weapon” we have agai…
I'd wager that most of the applications that need to be "complex" in fact only haven't sorted out how to process their payloads in an organized way. If most of your code has to think about concurrent memory accesses, something is likely wrong. (There may be exceptions, like traditional OS kernels).
As hardware gets more multithreaded beyond those 16 core machines, you'll have to be more careful than ever to avoid being "complex": when you appreciate what's happening at the hardware level, you'll start seeing that concurrent memory access (across cores or NUMA zones) is something to be avoided except at very central locations.
> essential complexity can’t be reduced
I suggest looking at accidental complexity first. We should make it explicit instead of using languages and tools that increasingly hide it. While languages have evolved ever more complicated type systems to be (supposedly) safer, the perceived complexity in code written in these languages isn't necessarily connected to hardware-level complexity. Many language constructs (e.g. RAII, async ...) strongly favour less organized, worse code just because they make it quicker to write. Possibly that includes checkers (like Rust's?) because even though they can be used as a measure of "real" complexity, they can also be used to guardrail a safe path to the worst possible complex solution.
Earlier quoted context omitted.
I am not a security maximalist: I will not pursue it at the expense of everything else. There is a trend among security professionals , as it were, to place anything on the chopping block in the name of security. I find this is often counter-productive, since the #1 way to improve security is to reduce complexity, which many approaches (e.g. Rust) fail at. Security is one factor which Hare balances with the rest, and…
> There is a trend among security professionals, as it were, to place anything on the chopping block in the name of security. I really have to disagree on this, in spite of not being a security professional, because the history has proven that even a single byte of unexpected write---either via buffer overflow or dangling pointer---can be disastrous. Honestly I'm not very interested in other aspects of memory safety,…
And while maybe a Wordpress bug could "only" lead to a user password database leaked but not the complete system compromised, there is a valid question which is actually worse from case to case.
Point is just that from a different angle, things are maybe not so clear.
Software written in memory unsafe languages is among the most used on the planet, and could in many cases not realistically replaced by safer languages today. It could also be the case that while bug-per-line might be higher with unsafe languages, the bang-for-buck (useful functionality per line) is often higher as well (I seriously think it could be true).
* https://git.sr.ht/~sircmpwn/hare/tree/master/item/cmd/harec
* https://git.sr.ht/~sircmpwn/hare/tree/master/item/hare
* https://harelang.org/blog/2021-03-14-a-self-hosting-toolchain/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…
> Labeled loops > I'm not yet sure whether this is a good thing or a bad thing. Sure, you can do clever shenanigans now, but something tells me this will make the code's control flow much harder to follow. The most popular example I can think of is JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Tbh, I think the opposite is true: without the ability to break outer loops, I have resorted to…
Earlier quoted context omitted.
That’s just not realistic. We live in a complex world, and we need complex software. That’s why I vehemently hate these stupid lists: http://harmful.cat-v.org/software/ Don’t get me wrong, it is absolutely not directed at you, and I absolutely agree that we should strive for the simplest solution that covers the given problem, but don’t forget that essential complexity can’t be reduced. The only “weapon” we have agai…
In a world where 99% of software is still written to run on 4-16 core machines and does tasks that any machine from the last 10 years can easily run on a single thread if it was just designed more simple instead of wasting tons of resources... I'd wager that most of the applications that need to be "complex" in fact only haven't sorted out how to process their payloads in an organized way. If most of your code has to…
The languages that hide accidental complexity to the greatest extent are very high level, dynamic, "managed" languages, often with a scripting-like, REPL-focused workflow. Rust is not really one of those. It's perfectly possible to write Rust code that's just as simple as old-school FORTRAN or C, if the problem being solved is conducive to that approach.
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.
There will always be shortcomings in any language, and there will always be situations that need to be fixed with a quick hack, even though that is not a long term solution.
And in almost any project I have a few lines of macro magic that almost completely fixes situations where I would otherwise have to resort to terribly complicated C++ templates and slow compile times.
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…
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…
It looks like self-hosting is still WIP. Do I have that right? * https://git.sr.ht/~sircmpwn/hare/tree/master/item/cmd/harec * https://git.sr.ht/~sircmpwn/hare/tree/master/item/hare * https://harelang.org/blog/2021-03-14-a-self-hosting-toolchain/
There is one more significant (but not user-visible) change planned for the language before we continue working on that.
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…
> Labeled loops > I'm not yet sure whether this is a good thing or a bad thing. Sure, you can do clever shenanigans now, but something tells me this will make the code's control flow much harder to follow. The most popular example I can think of is JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Tbh, I think the opposite is true: without the ability to break outer loops, I have resorted to…
Fair enough! Since writing that I've done a lot of Zig code, which has labeled loops, and I can say it's definitely made a lot of code clearer than it would be otherwise.