Thread 106792101

From what I heard it is essentially C but with tagged unions, no headers and much better error handling.
Has anyone tried Hare? It sounds promising to me.

Use case for these threads?

>>106792101 (OP)
Buy an ad, Drew.

>>106792101 (OP)
Rope, Drew

kys drew

It's okay, I guess. But what is the point when so many C alternatives already exist? I couldn't find an exact answer

>>106792101 (OP)
no one is using your malware you pedo drew

>>106792700
>But what is the point when so many C alternatives already exist? I couldn't find an exact answer
youre not going to get one, there is zero effort made by their community to lower the barrier of entry to Hare

>>106792123
ebussy... sex...

>>106792339
this is where he lost me

>>106792101 (OP)
Hi Drew

Stop the spam Drew OpenMediaVault

drew might be even more well-known than mikee as a resident /g/ histrionic schizo, lmao.

>>106792101 (OP)
all that, and java tier performance. hey wait a moment, why not just use java at that point???

>>106792101 (OP)
Nobody cares if it's a good language or not (probably it's not) but, why in the fuck he is not using LLVM as backend? Is he retarded?

>>106794579
have you ever made anything that used "LLVM" as a "backend"?

>>106794611
Maybe.

>>106792101 (OP)
usecase for drew creating these threads?

hare and a bunch of Drew's other projects were something I was really interested in before he outed himself. Really a shame how much of a homo that guy is and how untrustworthy he's proven to be. I got banned for 3 days last time I said something bad about Drew on here so I'll just leave it at that for today.

>>106793777
why do either of them care so much about spamming g anyways?

hit me up when any of these meme langs reach 1.0
I don't want to rewrite everything each month

Wake me up when I can use it on wangblows without a VM or WSL

>>106792700
>But what is the point when so many C alternatives already exist
Maybe it's better than the other alternatives?

To be honest, hare is the only recent newlang that actually got "C with fixed warts " right from a C programmer view

Zig, Odin and such ended up being much more than that


Also there are some refreshing choices made by ddv (either by necessity or deliberately, doesn't matter in the end)
> Language freeze at 1.0. that means the language doesn't aim to be in an eternal catching up of features and when the technology gap will becomes too "obvious", another language will be developed
This has the pros of avoiding the shitfest that is programming right now (which C standard? What java version? What python version?). If you know hare, you can sit down and programming now, as you will be able to do maintaining sw written with hate in 2300 (if there will be any, of course)

> QBE instead of llvm
Dependability (readability, maintainability, extensibility) over performance
Newlang all use llvm because it's the "golden standard" of backbends. But that comes at a cost, that is it requires a lot of effort to maintain it and extending to new archs. Hare tries to grow by being easy to port. Nowadays languages like Odin are trying to move away from llvm because they realize that more than 50% of the effort in maintaining the language is keeping up to broken compatibilty between llvm releases

Long story short, aside from technical merits, ddv had the balls to make what seems "controversial" choices wrt modern standard language choices, because he want a simple, hackable, easy to extend language as a primary metrics and to be honest, they are quite refreshing

>>106799388
>>106792700
He basically looked at C and see what are the problems that makes it anachronistic
> Text macros instead of modules system, hence even lacks of namespace
> Too primitive string implementation
> dangerous and error prone pointer arithmetics -> 90% of them can be avoided by implementing slices
> UB -> hare reduced UB casistics by a large margin
> Basically absent error handling capabilities, one of the most important programming language feature -> solved by anonymous tagged unions and pattern matching and error propagation operators (?, !)

And a couple of safety features like defer, non-nullable pointers and array access control + complete modern stdlib and a standard build system

These are unarguably not a matter of choices/preferences but objectively deficiency of a modern language

>>106799388
True but imho, Odin ended up pretty close.

>>106799388
>which C standard?
-std=c89
wow
much difficult
many hard

>>106799388
>Odin are trying to move away from llvm because they realize that more than 50% of the effort in maintaining the language is keeping up to broken compatibility between llvm releases
writing a language backend is by far the most difficult part of making a language implementation which is why almost every programming language made in the last 10 years all use llvm. I think Zig managed to make their own backend last month and its benchmarking faster than llvm. I dont think Ginger Bill is able to make his own backend will have to hire someone to do it

>>106799388
>Dependability (readability, maintainability, extensibility) over performance
Nobody cares about that. Modern software is build on layers and layers of technical debt.

>>106799930
odin is nice but hare is even better on paper
still, I won't mind odin replacing C in the future

>>106800588
Are you dumb? I meant as a maintainer

>>106801054
>Nobody cares about that.
I care
> Modern software is build on layers and layers of technical debt.
That's something hare would have prevented

>>106801776
>I care
You don't your software have the quality of all "suckless" projects, it's a featureless incomplete meme.

>>106801927
> I only know /g/ meme
That tells more about you than me, loser

>>106802294
I'm still having hair, chud.

>>106802689
It's almost certain I have more hair than you

>>106792101 (OP)
dead nigger baby of a programming language made by obsessed commiepedotroon.

>>106792101 (OP)
I don't understand some design decisions of Hare. Why you can't for example do?:
type <block>

Or something that can be more useful like:
defer <block>

>>106800758
the new zig debug backend is also 50x slower than llvm

>>106799450
Buy an ad, Drew.

>>106805482
> type <block>
What's the point of that?

Fuck off, drew.

You all missed the whole point of hare
>Hare is a language that most of its experienced users should be able to understand in its entirety: it’s feasible that one person can read and understand the entire compiler, for example. This also becomes easier given that Hare is self-contained – it does not depend on libc.

>>106803897
>loli
B A S E D
A S E D B
S E D B A
E D B A S
D B A S E

>>106792101 (OP)
>much better error handling
it doesn't have exceptions
some errors are best handled with tagged unions but others are better handled with exceptions

>>106792101 (OP)
fuck off drew
also buy an ad

this thread needs more controversy
https://www.youtube.com/watch?v=c7WOrFcwF_k

>>106813713
Exceptions can be implemented using tagged onions.

>>106815126
yeah, using if (err) { return err } at each function call
the point of exceptions is that you don't have to do that

>>106815432
What I mean is that exceptions can just be syntactic sugar for tagged unions.

>>106816052
exceptions are a control flow primitive, they are as far as you can get from being syntactic sugar for anything

>>106792101 (OP)
use case for hare

>>106817090
Generally exceptions are syntactic sugar for setjump and longjump but can also be implemented using tagged unions.

>>106818567
computed gotos (+ resetting RSP and RBP essentially) are not syntactic sugar you imbecile

>Generally exceptions are syntactic sugar for setjump and longjump
I'd say that it's the opposite, setjump and longjump are bloated implementations of exceptions in that:you don't function calls and you don't need to save all the registers. I mean, at the core exceptions are as lightweigth as function calls and function returns. The whole saving/restoring the registers is done for the exact same reason than for function calls. The compilers could very well (if they don't do this already), have lightweight try/throw and the register allocator save as much/as little register it needs to, just like for function calls.

Also, setjump/longjump allows you do unwind the stack and go back to specific places in the function call stack, but there is another style of exceptions where they respect a strict stack discipline (pop the last setjump buffer from an exception stack and longjump to it). A language could also have both.

There are languages like Python that throws "specific exceptions" that must be catched by a catch with the right exception type but I'd argue that it's basically the setjmp/longjump variety implemented badly. You could very have a hashtable/ struct that would associate an exception type to a setjump buffer and the thrower could directly get it and longjump in O(1).

>>106818947
>are bloated implementations of exceptions in that:you don't function calls
*dont need

>>106818947 me
>The compilers could very well (if they don't do this already), have lightweight try/throw and the register allocator save as much/as little register it needs to, just like for function calls.
For example, concerning the code generation of a try block in a particular function, the compiler could do a function call graph analysis and determine that the called functions (and the function it calls) do not do floating point operations not vector operations, so it only needs to save the general purpose registers.

Even better. If the function does something like try { some_function(arg1, arg2) } catch { }, the call to "some_function" already save the caller-saved registers to the try block/setjump does need to save them itself. So if an exception is thrown, the code at the catch block can restore registers using the caller-saved registers, that would have been also restored after the function call (when the some_function returns normally).

Same thing concerning the scratch registers (callee-saved registers). Those would also have been saved at the function call site so again the try block/setjump doesn't need to save them again.

>>106819102
>Same thing concerning the scratch registers (callee-saved registers).
that should be the caller-saved registers, so this is the same case as the previous paragraph I guess.
In general the try block/setjump should need to save the callee-saved registers.

>>106796658
they're banned from everywhere else
hn, lobsters, reddit, all have banned drew and hare because of how much they spam

>>106820064
Drew was banned 5 years before Hare was even a thing. And he was only banned because pushcx is a malding middle age boomer who likes dressing up as a little girl and throw little girl tantrums

>>106820101
lol ur banned drew

>>106792101 (OP)
I think the rat or whatever in the logo is pretty cute.

>>106820064
is there anything that infuriates either of them? something that can be posted to drive them to further autism for deh lulz?

>>106820101
>red reddit banned drew

BUY .

AND .

ADD .

>>106792101 (OP)
Hare stands proudly for trans rights.

>>106792101 (OP)
This post is advertising or begging.

>>106820336
It's a rabbit (not a baby hare, as mistakenly advertised)

>>106820905
Drew loves trannies & faggots so making fun of them would probably piss him off

>>106821653
>>106824714
looks like ballsack lol
wonder how drew would feel is someone DREW him having balls like that

>>106825064
alright heres the first version

>>106825417
>shaw

>>106825520
first time i ever do somethiing like this
sorry not sorry

also heres refernece

>>106825613
uhh why is it black background lol

It's C but slow, great.

Drew, fuck off already.

>>106831112
let inorganic threads die such is the nature of this site

>>106792101 (OP)
no thanks

>>106792127
>>106792339
>>106792599
>>106792853
Isn't Drew a mastotranny? I don't believe he would be advertising on 4chan

>>106792101 (OP)
QBE is dumpster fire

>>106792101 (OP)
what is that little bunny logo from?/?
i have this already saved to my pc but have never heard of what OP is talking about

too little too late: the language

>>106832388
why so?

>>106836090
Just look at QBE's code and tell me everything is fine.

trump

ball's Hare

>>106836280
There aren't any problems with the code.
r = v->t[0];
curi = &insb[NIns];
for (i=&b->ins[b->nins]; i!=b->ins;) {
i--;
if (regcpy(i)) {
i = dopm(b, i, v);
continue;
}
bszero(w);
if (!req(i->to, R)) {
assert(rtype(i->to) == RTmp);
t = i->to.val;
if (bshas(v, t))
bsclr(v, t);
else {
/* make sure we have a reg
* for the result */
bsset(v, t);
bsset(w, t);
}
}
j = T.memargs(i->op);
for (n=0; n<2; n++)
if (rtype(i->arg[n]) == RMem)
j--;
for (n=0; n<2; n++)
switch (rtype(i->arg[n])) {
case RMem:
t = i->arg[n].val;
m = &fn->mem[t];
if (rtype(m->base) == RTmp) {
bsset(v, m->base.val);
bsset(w, m->base.val);
}
if (rtype(m->index) == RTmp) {
bsset(v, m->index.val);
bsset(w, m->index.val);
}
break;
case RTmp:
t = i->arg[n].val;
lvarg[n] = bshas(v, t);
bsset(v, t);
if (j-- <= 0)
bsset(w, t);
break;
}
bscopy(u, v);
limit2(v, 0, 0, w);
for (n=0; n<2; n++)
if (rtype(i->arg[n]) == RTmp) {
t = i->arg[n].val;
if (!bshas(v, t)) {
/* do not reload if the
* the temporary was dead
*/
if (!lvarg[n])
bsclr(u, t);
i->arg[n] = slot(t);
}
}
reloads(u, v);
if (!req(i->to, R)) {
t = i->to.val;
store(i->to, tmp[t].slot);
bsclr(v, t);
}
emiti(*i);
r = v->t[0]; /* Tmp0 is NBit */
if (r)
sethint(v, r);

>>106838058
Good to know that Hare fags are amateurs.

>>106838370
the code looks fine. Either you address what's wrong with it or gtfb to reddit

>>106838508
You're a fucking idiot Drew. There are other alternatives to LLVM other than QBE, much better ones.
LibFirm is how a real optimizing compiler looks like.

>>106838704
>LibFirm
It optimizes less than QBE though (and QBE is not already that much to start with).
The code doesn't look that different from many old-school projects.

>>106838704
Also it does not support x86_64. There is that Eigen Compiler Suite that looks interesting but is written in C++... Also there's MIR but seems focused on JIT.
So really, they way you said it, make it looks like we have MANY good options. When we barely have one.

>>106838508
Can you even tell me which optimizations and analyses QBE does?
Which algorith it uses for register allocation? For instruction selection?
>>106838747
>It optimizes less than QBE though
What the fuck are you talking about nigger? Just look at the files each project has. I've seen the list of optimization LibFim does and QBE doesn't the quarter of it.

>>106838794
>Also it does not support x86_64
It does though.
>So really, they way you said it, make it looks like we have MANY good options. When we barely have one.
That's what I'm saying, I'm saying that there are a few (very few) and that I wonder how much you've got hit in the head to think this garbage of QBE was any good that it was better than the other ones.

>>106838822
>Which algorith it uses for register allocation?
simple linear scan
> For instruction selection?
pattern-matching tree shit

>>106838853
> it does though
"This version includes a complete backend for the IA32 and SPARC architecture, as well as unfinished backends for MIPS, ARM, and AMD64.
> arm
> amd64
> unfinished
Hmm...

https://github.com/libfirm/libfirm/issues/37
> MIR
About QBE: "It has the same optimizations as MIR-generator plus aliasing but QBE has no inlining"
c2m -eg 0.96 0.91 (Mir)
c2m -eb 0.92 0.85 (Mir)
cparser -O3 1.02 0.98 (LibFirm)

>>106838704
you didn't understand the whole rationale behind hare and its choices you stupid nigger
The hare main non-functional goal is that the whole ecosystem must be (ideally) understandable by a single person from top to bottom
with this in mind you'll understand why QBE (10k LOC) was chosen as a backend instead of LibFirm(100k LOC)

Performance is important but it shouldn't supersede other dependability metrics

>>106799388
>>106799450
There are things I like about Hare but I'll wait to see how it pans out. Unlike Zig it doesn't seem to have the velocity necessary to sustain it in the long term.

>>106839297
> Unlike Zig it doesn't seem to have the velocity necessary to sustain it in the long term.
Arguably, with the choices ddv made (like using QBE) it requires a smaller team to achieve the same effort required by zig which has to deal with LLVM evolution

But in all ends, hare doesn't need that much velocity to sustain in the long term, since the language will froze at 1.0 and will never add any features and by using slow pacing moving 3rd party ecosystem (like again QBE) the maintaining effort is minimized (and also distributed, since a small team of motivated person can port hare+QBE to their architecture of choice, something that it's nearly impossible with LLVM)

You have to agree with ddv that programming languages don't have to "keep up" but they are mortal entities, which to be honest I agree with after seeing the drawbacks of keeping languages updated + backward compatibility hell and featuritis. Programming languages should live for a reasonable timeframe (like 30+ years) and they die for another language(s) iteration

>>106839377
I don't disagree with any of that - but until I see some larger projects that have been around for a while written in Hare, I'm not going to invest time into it beyond just playing around. I hope it gains more adoption though

>>106839203
Meant for >>106838822 ?

why is half this thread comprised of ESL posters?

>>106842670
Because McPeople suck at CS

>>106792101 (OP)
Never hare of it.

Harey Clinton

>>106839203
Imagine googling other's opinion when you can just compile C file and see for yourself

The reality is both are useless meme backend because they don't support atomics or even long double

>>106844757
>long double
80bit floats using x87 instructions?

>>106845151
Right. libfirm would complain x87 being unimplemented and qbe only supports f64 max

>>106842670
Hare is a Russo-Chinese language
Only Chinese universities and one Russian professor mentioned it.