Thread 106857285

>Makes C obsolete
Is Hare the most based language?

sell me on it

that's a bunny

>>106857285 (OP)
Hi Drew

>>106857285 (OP)
drew i quit 4chan for like a year and you're still posting this shit

toylang

>>106858781
nuh uh, it's a baby hare!

usecase for shitty toylangs?

I don't like to share my thoughts until a thread has at least twenty posts saying nothing but "bump", but I'll make an exception this once. I think it's a good idea to create a stable, long-term oriented language in the C market space.
I vaguely recall reading something where Drew indicated that some C stdlib code that needed to be ported made heavy use of macros, but he wanted to avoid that language complexity and had to write a (comparatively) large amount of code to generate an equivalent Hare version. To me, this is an obvious sign of an insufficiently expressive language, not a selling point about minimalism. I think he stated that he plans to have no generics/reflection/macros/metaprogramming at all. Similarly, it lacks any built-in support for threading or parallelism, which are features that I would think to be "must-haves" if designing for the next century.
I don't work in this space though, so I'm talking out my ass. All of the things that stuck out to me might be totally irrelevant for his target audience, and he knows a thousand times better than me what his language needs. If I were somehow in a situation where I needed to make a program for myself and my Linux-using friends and could only choose between C or Hare, I would pick Hare though. So, that's something.
>>106858781
agreed, but cute bnuuy tho

>>106857285 (OP)
>no linear types
>no capability types
>no exceptions (yes chud, exceptions can be implement as syntactic sugar for sum types error pattern matching)
>no defer block
>no error propagation
>you have to do the "borrow" and "ownership" by yourself (pic)
>simplistic simple pass compiler
>no templates
>no macros
>no move semantic
>no interfaces
>poor performance
>hurrr durrr NIH mindset bullshit to justify a poorly designed compiler
>70% of performance with 10% of the code of LLVM, sure dude
>no OOP (this is not good or bad)
>C based syntax
>no function overload
It can't make C obsolete. It's basically C but 50 years later.

>>106857285 (OP)
kys

>>106857285 (OP)
kys
kys

>>106857285 (OP)
kys
kys
kys

>>106857285 (OP)
why would i use this instead of lua?

>>106860814
>no linear types
*Not yet. They are investigating it
>no exceptions (yes chud, exceptions can be implement as syntactic sugar for sum types error pattern matching)
No need to then. Pattern matching is just fine
>no defer block
Why?
>no error propagation
I think it does have that
>poor performance
>70% of performance with 10% of the code of LLVM, sure dude
That's due to QBE
>>no OOP (this is not good or bad)
>C based syntax
>no function overload
Useless feature

>>106860849
>why would i use this instead of lua?
funny you would mention Lua because the big selling point of Lua is that you dont have to install this huge environment like Python, its like a put couple of 600kb binaries in your path and you start using it.

Drew chose to not provide a precompiled binary like Zig and Odin but makes you compile all the dependencies and compiler source to your system. Which defeats the purpose of breaking out of the C ecosystem and makes you a unix slave.

Everything Drew does filters out his potential userbase. He made SourceHut unusable to noobs compared to Github that handholds everything you need to do to use it. He uses mailing lists instead of forums because muh email. Nothing about what Drew does is anything you can recommend to anyone.

>>106861477
>Pattern matching is just fine
No it's not, pattern matching is the wrong construct to handle errors, it's verbose and error prone. Look how "exceptions" are implemented in Swift.

>no defer block
>Why?
Destructing or deallocating multiple resources is often needed in the same context of the function, you can probably pass pointers to those resources to a function but then you need to write a "defer function" and is not aceptable.

>>106857285 (OP)
Is Bicha allowed at HareCon, Drew?

>>106860814
i thought these threads were a meme but looks like it's actual garbage

HI DREW

Looks like every other C repleacement language
What's so special about this one?

>variable assignment is let name = ...
If you don't explicitly specify the type on assignment it's a toy language

>>106863263
his sexual appitite for japanes lolis (or whatever the fuck gookcucks are into nowadays)

>>106861477
>>no exceptions (yes chud, exceptions can be implement as syntactic sugar for sum types error pattern matching)
control flow primitives are not syntactic sugar, braindead faggot

>>106863293
Yes they are

>>106863660
being able to emulate something doesn't make the thing syntactic sugar

>>106864448
It's doesn't emulate anything chud, it's syntactic sugar over pattern matching + error propapation.

>>106861534
>Everything Drew does filters out his potential userbase.
To me it's the opposite, on paper I find all choice interesting
> Hare
small codebase
Just a better C
100 years old language
Understandable from one person from top to bottom (including the backend)
> Helios
Capability based ukernel (written in hare)
> AresOS (Helios kernel)
Plan 9 inspired (uniform resource representation, unique network agnostic protocol)
fat client <--> fat client distributed operating system

> Source hut
No ads and no js. I don't really know it very much tho

>>106861672
>it's verbose and error prone.
It's not verbose and actually the opposite of "error prone" (as long as pattern matching is exhaustive)

>>106865858
>syntactic sugar over pattern matching
exceptions are a kind of jump, they have nothing to do with pattern matching you dumb fuck
pattern matching is syntactic sugar for conditionals and assignments

>>106857285 (OP)
Algol 68, PL/I, and Pascal already made C obsolete before C existed. PL/I was a more popular language with IBM and Gary Kildall, so it's likely that if IBM used their own OS or CP/M instead of MS-DOS, we would be using PL/I instead of C wherever C is used today. The Mac was designed for Pascal.

>>106866936
Please, stop being a funking retard. See >>106861672 https://docs.swift.org/swift-book/documentation/the-swift-programming-language/errorhandling/

>>106863263
This one dilates() in the standard lib

>>106861672
>instead of having to exit the function and unwind the stack until we reach an exception handler (yuck!), we repeatedly return from functions, deallocating their stacks, until we reach an exception handler (wow!)
I'm sure there's some sort of difference there, but what an incredibly vague summary of the feature they're trying to advertise

>>106867022
>Error handling in Swift resembles exception handling in other languages, with the use of the try, catch and throw keywords.
>Unlike exception handling in many languages — including Objective-C — error handling in Swift doesn’t involve unwinding the call stack, a process that can be computationally expensive.
>As such, the performance characteristics of a throw statement are comparable to those of a return statement.
Yeah, because a thrown exception is doing *ONE* INDIRECT JUMP you dumb motherfucker.

Languages with improper retarded "expections" *emulate* a single exception with a whole chain of hidden control flow (conditional + return) that "unwind" the function call stack one frame at a time, in O(n).

Excpetions are not syntactic sugar for pattern matching + error propagation.
The hidden control flow at each callsite that emulates a real exception is syntactic sugar for pattern matching + error propagation.

>>106857285 (OP)
Fuck off drew segfault