>Makes C obsoleteIs Hare the most based language?
sell me on it
that's a bunny
>>106857285Hi Drew
>>106857285drew i quit 4chan for like a year and you're still posting this shit
toylang
>>106858781nuh 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.>>106858781agreed, but cute bnuuy tho
>>106857285>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 overloadIt can't make C obsolete. It's basically C but 50 years later.
>>106857285kyskys
>>106857285why 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 fineNo 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.
>>106857285Is Bicha allowed at HareCon, Drew?
>>106860814i thought these threads were a meme but looks like it's actual garbage
HI DREW
Looks like every other C repleacement languageWhat'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
>>106863263his 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
>>106863293Yes they are
>>106863660being able to emulate something doesn't make the thing syntactic sugar
>>106864448It'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 > Haresmall codebase Just a better C100 years old language Understandable from one person from top to bottom (including the backend)> HeliosCapability 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 matchingexceptions are a kind of jump, they have nothing to do with pattern matching you dumb fuckpattern matching is syntactic sugar for conditionals and assignments
>>106857285Algol 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.
>>106866936Please, stop being a funking retard. See >>106861672 https://docs.swift.org/swift-book/documentation/the-swift-programming-language/errorhandling/
>>106863263This 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.
>>106857285Fuck off drew segfault
