DeVault: Announcing the Hare programming language
DeVault: Announcing the Hare programming language
Posted May 2, 2022 16:16 UTC (Mon) by wtarreau (subscriber, #51152)In reply to: DeVault: Announcing the Hare programming language by ddevault
Parent article: DeVault: Announcing the Hare programming language
>
> https://git.sr.ht/~sircmpwn/hare-irc
> String manipulation and manual memory management goes together like oil and water. I think we've done a pretty good job nevertheless,
> and you can do most string operations relatively comfortably.
>
> https://docs.harelang.org/strings
> https://docs.harelang.org/regex
> https://docs.harelang.org/fmt
Thanks Drew for sharing. However I had already looked at these ones. For example what's not obvious to me is how strings and memory mix together. I.e. if I want to write a variant of base64 output whose max output size I already know based on the input, am I supposed to use concat() between strings for every character or may I just create a string of suitable size and fill the chars a-la "*(p++) = c" since I know what I'm doing ? Don't get me wrong, I love the approach of "trust the programmer", especially since nowadays a non-negligible number of bugs are induced from trying to work around absurd warnings or non-sensical UB, resulting in unnatural code that easily breaks. I'm just curious to know how that mixes as I do imagine it's not a trivial thing.
> >I don't know if it also forces to change every single line of code when using an alternate implementation of a lib
> It does not; vendoring is very straightforward and does not require any rewriting of the code. You can also trivially vendor modules
> from the standard library.
OK, fine!
> >That said it's strange that cross compiling is still in the roadmap, given that by now it should be well known that cross-compiling
> > should be the default approach and native compiling just a special case of it.
> This is in fact how it works in Hare, we just have to glue a few pieces together to make it useful. You can compile Hare code to any
> supported arch like so:
>
> $ harec -X^ -T+riscv64 example.ha | qbe -t rv64 > example.s
> $ as -o example example.s
That's fine then!
> But generally Hare programs are not built like this - they're built by invoking the build driver, hare(1), which is just currently
> lacking the convenience flags to glue all of the bits together. Also missing is the non-trivial considerations for handling sysroots
> when linking to native C libraries, though thankfully most Hare programs don't link to C.
OK so in practice it does support cross-compiling, it's just that it's not trivial to use right now. That's much less of a problem, because usually when cross-compiling is not supported, it stems from reasons having their roots very deeply burried. Here's it's mostly a UI issue in fact.
Thanks for the clarifications.