Is it the most based language?

>Hare is written in C
Future compiler exploits galore!
But actually that would require the language to be used at all outside of nocoder toy bullshit

>can't program his way out of a paperbag
He probably wrote more real (C) code than you

>use after free and double free, both of which can lead to arbitrary code execution
No they can't

>Even C is better than hare at preventing use after free.
Source?

>days without Drewish Tricks: 0

You will NEVER be a real woman.

Myrddin is a oridb project, a 9front maintainer/contributor
The project should be no longer maintained iirc

If one "contributes" to the language, he/she needs to contribute to a specification, standard library, compiler, etc.
making projects IN the language doesn't count.

It has no specification. It claims to have one, but the document that stands for one is not a specification.
It has 0 advantage over c. It's much slower, makes bigger binaries, is just as unsafe, compiler slower, supports fewer platforms, is far buggier, isn't standardized yet, has no tools or libraries worth anything, etc.

It quite literally IS by lonely retards, which is quite literally the biggest problem about hare and why it's so shit and has only disadvantage over C. "Look mah I baked the library features into the language" is not an advantage, it's a disadvantage (now you're forced to have it even when you don't need it).

Vlad is not a troon but a commie. Count them: 3 trannies listed, not 4. Byron is just a cringie zoomer with no dev ability or experience at all. The important part is inexperience despite the inflated status, demonstrating how bad hare is hurting.

3 troons out of 8 maintainers.

Look at the so-called contributions
>fixed a typo
>changed the doc
Wow such contributions. None of those people even talk about hare, or use it, or even advertise that they touched it. Why do they hate hare so much?

Nah, the people against hare are redditors and LULZ autists
It's pretty much a sign it's a good language without even knowing it

Nope. It's not anymore a mystery hare shitposter are redditors who use LULZ
You know something it's nice when LULZ start screetchig about trans

Lol, only redditors don't like it.
You are a very week golem

>Strange, there isn't a single person saying good things about it on the entire internet,
You mean Reddit, hn and LULZ?
What that could mean?

Redditors like you don't care because his "abrasive" and "problematic" opinions
Your master must be weak

Hare doesn't need pr
If you are into that kind of stuff you should look for rust they are working really hard on that

That's what your peers think. Make up your mind
> Sucking trannies cock
Calm down dude, that's just your fantasy

Oof! *drops mic*
Brutal.

And to clarify what I mean by "defer everywhere"
is that unlike C++, Rust, and my specific idiomatic way of writing C, there is no "standard" place for defer to go. It can be in the beginning of a function, or in the middle nested under 3 match statements that the shitty segfaulting compiler forces you to do just do check if ptr != NULL. Absolutely trash language.

>no type safety
>no encapsulation
>no thread safety
Oh wait I forget hare has no threads, KEK. I keep forgetting this language explicitly has zero way to scale for any performance critical applications.
>aborting on use after free instead of just not accessing the pointer
Of course a harebrain would think this is acceptable.
>deliberately did not include the autistic ass syntax for using this contraption because the equivalent in function C is 100 times smaller.
Every time.

> Hare has ZERO way to deal with that without bloating your code by a factor of 2 JUST TO BE AT THE SAME LEVEL OF SAFETY AS C. LMAO.
Nice way of contradicting yourself in the same sentence

Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake

There is no contradiction. There is no reason to use Hare over C when C is just as safe as hare and has better tooling, more mature libraries, isn't ran by a single autistic tranny lover, and is smaller, faster, and has threads.
>Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake
if (ptr) {
/* ... */
}

Earlier in code
free(ptr);
ptr = NULL;

> project zero. Hare has ZERO way to deal with that without bloating your code by a factor of 2 JUST TO BE AT THE SAME LEVEL OF SAFETY AS C. LMAO.
That's a huge overstimation. If you are icnvinced of that shows some measurement to convince us
The small overhead of wrapping deferencing in match statement it's valuable enough

You're not paid by loc or chars typed aren't you?

Yes because
match (z) {
case null =>
abort();
case let z: *int =>
yield *z; // Valid
};

Is in the harebrained mind somehow more readable than
if (ptr) {
/* do something with *ptr */
}

You are all fucking delusional nocoders. This example is the smallest possible one and it is LITERALLY TWICE AS LONG

>You don't need that. the UNIX way is to create more processes and communicate between those
The UNIX way is to use pthreads when you need threads, because they exist on every modern UNIX system.
>implying there is zero need for lightweight processes
>t. nocoder
That is not only way, way slower, it is 100 times more overhead because sharing data between processes is significantly more difficult, error prone, and time consuming than threads.
What about the extremely common use case of simply needing to do 2 things at the same time?
Here is an example.
In a simplex modem application, the receiver needs to be always running so that it can stop the transmitter from clobbering a signal via carrier sensing. This requires doing 2 things at the same time WHILE sharing state. Seperate processes would simply be too slow at sharing state without unironically using pthreads with the PTHREAD_*_SHARED attribute on a mutex, barrier or condition to access a shared memory map.
The code in Hare would be more bloated, slower, and have more bugs simply because the creator is too lazy and or dumb to implement threads and copes with
>muh 1970s UNIX way
UNIX has come a long way homosexual.

Another example would be the most performant networking library in existence, ZeroMQ.
Every time you use ZeroMQ it spins up a thread for IO. Doing that with processes would defeat the entire purpose and make everything slow for NO REASON.

Bait

>Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake
>if (ptr) {
> /* ... */
>}

That's doesn't force it. You are merely checking if it's null.
I asked for a way to make **impossible** to deference a nullable pointer

I'll wait

>Yes because
>match (z) {
>case null =>
> abort();
>case let z: *int =>
> yield *z; // Valid
>};
>
>Is in the harebrained mind somehow more readable than
>if (ptr) {
> /* do something with *ptr */
>}
>
Match statement are reused for both forcing pointer access **and** error handling. It seems kinda retarded to implement two different way of doing very similar things

>I asked for a way to make **impossible** to deference a nullable point
>compile C with -fsanitize=addresss
>attempt to dereference NULL poitner
>program aborts with an error message
In what way is this different than anything I've seen in hare?
You can statically link AddressSanitizer.
>Match statement are reused for both forcing pointer access **and** error handling. It seems kinda retarded to implement two different way of doing very similar things
>cope
And the tradeoff is that accessing pointers (the only way to actually deal with use after free) is twice as bloated. Just like I said it is. Please kill yourself.

>But I can not do that
Bait
>The second way allows you to do mistakes unwillingly, that's the point
Don't be a retard? I've had zero use after free and double free bugs in C for a good long while now.
Here is an actual solution for hare. Why not allow if statements to "unwrap" nullable values. Zig does this and works great.
The match statement literally makes your code twice as bloated for no good reason. Zig has the same nullable pointer semantics but I can still use a single if statement to unwrap it.

>implying there is zero need for lightweight processes
There is not, really

>That is not only way, way slower, it is 100 times more overhead because sharing data between processes is significantly more difficult, error prone, and time consuming than threads.
Difficulty wise they are the same. Maybe processes are are less error prone since they share less states
>What about the extremely common use case of simply needing to do 2 things at the same time?
You use 2 processes?
>Here is an example.
>In a simplex modem application, the receiver needs to be always running so that it can stop the transmitter from clobbering a signal via carrier sensing. This requires doing 2 things at the same time WHILE sharing state.
Share state by communicating between processes
> Seperate processes would simply be too slow
"Too slow" needs to be compared to something. Too slow for what?

>There is not really
You have never written a single program.
>Difficulty wise they are the same. Maybe processes are are less error prone since they share less states
>have an object with a mutex, that wraps access to the shared state
>literally just pass the object to threads
>everything ok
VS
>sending things through pipes
>have to deal with all the semantics of pipes, and sockets if you use socketpair
Hmm that sucks, is error prone, and makes you write a fuck ton of Code.
>allocate shared memory map
Wait we have to synchronize access, fuck I guess we have to use pthread libraries anyways.
>shm_get
LMAO
I've written programs that have done all of these things and threads are by far simpler faster
>Share state by communicating between processes
And how exactly would you do that. I've described how in my post, and it is slower than using threads. Maybe if you weren't a nocoder you could show me how I would do it?
>"Too slow" needs to be compared to something. Too slow for what?
Using threads is faster.
You can kill yourself now.

>You can seethe about my white skin all that you want, but the language of the internet is English, and always has been.
If you are EFL it's more likely you are a blackmutt respect to ESL, I don't know of you are aware of that

>No matter how cancerous the web is, there is no doubt that if HTTP servers weren't performant, then your entire country wouldn't be able to send "Good Morning" on WhatsApp and start violently shitting all over each other in riots.
Performant != Critical
Are you sure you ever worked on real "critical applications"?

>Why should I use it over hare then?
>Because ubsan makes undefined behavior not an issue in C.
So does hare. What's your point? What about the other features?
>Pretty much nothing is needed. You are a retard
>Projection. I've seen you in every single one of these threads. Why? You don't even code.
I'm not. But I always see that raii retard pasta and then after you receive a reply you start screetchig and write multiple wall of text
That does sounds like you are very lonely

Baked into every ESL is absolute seethe at Anglo superiority.
>Performant != Critical
>Are you sure you ever worked on real "critical applications"?
Give an example then.

>You still stating this without any proof
Proof here

>no type safety
>no encapsulation
>no thread safety
Oh wait I forget hare has no threads, KEK. I keep forgetting this language explicitly has zero way to scale for any performance critical applications.
>aborting on use after free instead of just not accessing the pointer
Of course a harebrain would think this is acceptable.
>deliberately did not include the autistic ass syntax for using this contraption because the equivalent in function C is 100 times smaller.
Every time.
[...]
There is no contradiction. There is no reason to use Hare over C when C is just as safe as hare and has better tooling, more mature libraries, isn't ran by a single autistic tranny lover, and is smaller, faster, and has threads.
>Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake
if (ptr) {
/* ... */
}

Earlier in code
free(ptr);
ptr = NULL;

[...]
Yes because
match (z) {
case null =>
abort();
case let z: *int =>
yield *z; // Valid
};

Is in the harebrained mind somehow more readable than
if (ptr) {
/* do something with *ptr */
}

You are all fucking delusional nocoders. This example is the smallest possible one and it is LITERALLY TWICE AS LONG

Twice as long in the smallest possible case.
You are right that Zig has other problems, but it at least has generics, threads the same level of error handling, modules, and I don't need to wrap every nullable pointer access in a 7 line minimum match statement.
Code bloat matters. Only ESL Sirs could possibly think otherwise.

>have an object with a mutex, that wraps access to the shared state
>literally just pass the object to threads
>everything ok
What is race condition and deadlock?
>sending things through pipes
>have to deal with all the semantics of pipes, and sockets if you use socketpair
There are libraries that abstract over sockets. That is actually more a socket critics than mp Vs mt

>Wait we have to synchronize access, fuck I guess we have to use pthread libraries anyways.
Why? Use synchronous protocol or CFDTs to some extent
>shm_get
>LMAO
What? Are you able to state some thought clearly?
>I've written programs that have done all of these things and threads are by far simpler faster
They were toy programs then
> Using threads is faster
Message passing seems to be perfomant enough over network. What makes you think it's not for local communication?

>You can kill yourself now.
>Baked into every ESL is absolute seethe at Anglo superiority.
> Anglo
Lol

>Give an example then.
Industrial controllers
Medical devices

>What is race condition and deadlock?
These can happen with multiple processes retard. You can also just use lock free objects with atomics for even faster code.
>There are libraries that abstract over sockets.
>bloating your code with an entire library vs just using a thread
>Why? Use synchronous protocol or CFDTs to some extent
>use an entire server vs just using threads
If we are talking about a shared memory map, you could also use posix semaphores, but those suck too.
>What? Are you able to state some thought clearly?
You have never used shm_get clearly.
>Message passing seems to be perfomant enough over network
It is literally the ONLY way over a network. Of course it will be good enough for the network, it has to be. The limitations of the network bring a whole host of other issue and it is still not even close to a as fast as just accessing memory in a thread.
>Industrial controllers
I've worked on those, and you are absolutely delusional if you don't think speed matters.
Hare would not be a remotely feasible candidate to replace any software on anything I've worked on in that space regardless.

> HTTP
Nginx doesn't seems to have big performance problems

>Nginx
>uses threads
>is performant
I know.

Hare is a worthless shitlang. Every single time anyone brings up an actual issue with the language its sour grapes.

Drew, how many ESLs are you paying to shill this language?

Nginx uses a single event thread and has overall more a multiprocess core over multithreading

>Oh wait I forget hare has no threads, KEK.
Threads are kinda useless and not having them eliminate the problem

> I keep forgetting this language explicitly has zero way to scale for any performance critical applications.
You have processes. "Scaling " and "critical applications" don't generally go together, in any language
>aborting on use after free instead of just not accessing the pointer
You can still access it by forcing the access with a keyword. Still it's very likely you are making a mistake if you don't explicitly state you are accessing a nulled pointers
function C is 100 times smaller.

>There is no contradiction.
Yea there is. If you state that "there is no way to do something" and continue with "unless" that's a logic contradiction

> There is no reason to use Hare over C when C is just as safe as hare and has better tooling, more mature libraries, isn't ran by a single autistic tranny lover, and is smaller, faster, and has threads.
People already posted you why use hare over c but I will post them again just to clarify
> Namespaces and modules for a better organized code scope and more seamless 3rd party libraries collaboration without a central or distributed package manager
> Less UB
> Better error handling: monadic errors and propagation and forced acknowledgment of errors makes the code less error prone and eliminated constant deduplication of wrapping pointers and error codes. It also eliminates the need for special semantic interpretation of perfectly allowed return value as errors and force the coupling of return error code and errno

>Good afternoon Sir,
>Threads are kinda useless and not having them eliminate the problem
>*eliminates
>Fucking hell. English is not that hard.
You still seems to not understand that people do not care about English as long as the content is understandable
Reddit is a better suited place to get angry about a languages grammar spoken by a minority of the world population

>You are nocoding scum who got filtered by threads.
>Scaling " and "critical applications"
>what is an HTTP server
It doesn't sounds like a "critical applications". We have different ideas about what really is a "critical applications"

>If the way to do something is objectively worse than the thing you are trying to replace, than what is the point of using the new thing?
It's worse in what way?
>Namespaces and modules
>A nice feature, but ultimately not needed.
Pretty much nothing is needed. You are a retard
>Less UB
>ubsan exists for C.
Why should I use it over hare then?
>Better error handling
>You don't need this. Every time I've ever seen it used to its fullest extent in hare, it bloats the code, all to essentially print a more exact error message to a user.
You are just an autist outcast that needs human interaction at this point. You seems to post in every hare thread waiting to talk with someone

>You can seethe about my white skin all that you want, but the language of the internet is English, and always has been.
If you are EFL it's more likely you are a blackmutt respect to ESL, I don't know of you are aware of that

>No matter how cancerous the web is, there is no doubt that if HTTP servers weren't performant, then your entire country wouldn't be able to send "Good Morning" on WhatsApp and start violently shitting all over each other in riots.
Performant != Critical
Are you sure you ever worked on real "critical applications"?

>Why should I use it over hare then?
>Because ubsan makes undefined behavior not an issue in C.
So does hare. What's your point? What about the other features?
>Pretty much nothing is needed. You are a retard
>Projection. I've seen you in every single one of these threads. Why? You don't even code.
I'm not. But I always see that raii retard pasta and then after you receive a reply you start screetchig and write multiple wall of text
That does sounds like you are very lonely

>Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake
>if (ptr) {
> /* ... */
>}

That's doesn't force it. You are merely checking if it's null.
I asked for a way to make **impossible** to deference a nullable pointer

I'll wait

>Yes because
>match (z) {
>case null =>
> abort();
>case let z: *int =>
> yield *z; // Valid
>};
>
>Is in the harebrained mind somehow more readable than
>if (ptr) {
> /* do something with *ptr */
>}
>
Match statement are reused for both forcing pointer access **and** error handling. It seems kinda retarded to implement two different way of doing very similar things

> Hare has ZERO way to deal with that without bloating your code by a factor of 2 JUST TO BE AT THE SAME LEVEL OF SAFETY AS C. LMAO.
Nice way of contradicting yourself in the same sentence

Show me a way to force a pointer to be non nullable and thus avoiding deferencing it by mistake

This is the ESL Sir by the way.

Each hare thread has these 2 posters.
>ESL nocoder
>Drew PseudoIntellectual

Sometimes there is a shitcoder tranny, but I don't see them this thread.