Make the Raku programming language familiar to C++ programmers | Hacker News Reader

Make the Raku programming language familiar to C++ programmers

software.gellyfish.co.uk

64 pointslizmat30 comments

I love Raku. Perl faced the same sort of pressure as PHP did to modernize and get rid of insanity, but where PHP modernized by sweeping all the insanity under the rug, Raku leaned into the insanity and invented brand new modern forms of it. Global variables getting you down? Just use dynamically scoped variables, where assignment follows the call stack. Automatic conversion between strings and ints annoying? Stick it in the type system and let user-defined types implement the behavior too. Hate nulls? Use the class object itself as a typed null.

So much of the language is so fundamentally different from how languages are made in Current Year that I couldn't begin to evaluate how useful or confusing these features are in the wild (especially operators like `ff`); I simply have zero context whatsoever for it.

Dynamically scoped variables have been around for a long time, and have existed in perl since version 4. I don't know which language first introduced them, but the Bourne Shell had them (and I suspect perl inherited them, like many other things, from shell). I do wish they were offered in more languages.

AFAIK original LISP is the oldest language with dynamic-scoped variables.

Although these were introduced as an implementation bug at first, and modern dialects (Scheme / Common Lisp) eventually replaced them with lexical-scoped variables, dynamic-scoped variables are still supported with different syntax in them (parameter objects in Scheme and special variables in CL.)

I like the niche Raku has carved out for itself, as a sort of experimental platform for writing software expressively.

I don't use it, I probably won't, this kind of expressivity is something which feels good for developers but doesn't help them cooperate. The tradeoffs are probably not worth it.

I'm glad it exists, though. It's a language where the users mostly find neat ways to say things, Perl is a great basis for that sort of language, and I wish them well.

I've used Raku, it's actually pretty good. It's the first language I've used in a while that I genuinely enjoyed and had fun working with. Alot of the articles that get posted to HN about Raku are often like this one, showing how to push the envelope in Raku, but I wouldn't so so far as to call it an experimental language. Just like in the Perl tradition, you can do some straight voodoo in Raku but it's not required either. It's fairly straight forward on the surface and has all the familiar accoutrements of a modern language. You can be productive without having to delve into any of the esoteric and experimental stuff but can still get 'underneath the hood' if you need to.

The difference between experimental platform and experimental language is admittedly subtle, but I did mean platform.

For anyone who just wants a cleaner Perl, it's there, it works. Descriptively, Raku as a 'scene' draws in a lot of people who come from the poetic school of Perl, which is great, it's clearly well designed for that crowd.

I don't know that I'd call Raku battle-hardened yet, but it's not an experimental language in the sense of having novel semantics, or frequent breaking changes, nor would you expect to hit a bunch of implementation bugs.

I'm not expecting many developers to decide to work in the large with a strict subset of Raku, because you can do that with Perl and get all of CPAN, or just use Python and black and have epsilon of zero problems of that nature.

>I don't know that I'd call Raku battle-hardened yet

You're right here, the Rakudo[1] compiler had its first stable release back in 2015 and comparatively speaking, there's a lot of space for growth.

[1]: https://rakudo.org/

I know this is a just for fun post, but C++ engineers haven't been especially happy with iostreams. {fmt} and std::format are more modern alternatives.

And use of std::endl is widely considered an antipattern. Use of '\n' is always better for printing new lines.

> And use of std::endl is widely considered an antipattern. Use of '\n' is always better for printing new lines.

people say that and then I loose half an hour trying to understand where my code is going wrong because my terminal did not flush when trying to debug log

When I want to flush, I use std::flush. Nothing about "endl" screams "this flushes", which is why nobody uses it. Also, flushing on every newline is a needless pessimization. Not that performance is everything, but it doesn't buy you much here.

endl just saves you from getting out of the habit of using endl, really.

>Nothing about "endl" screams "this flushes", which is why nobody uses it.

Are you seriously suggesting no one uses std::endl? A simple search on Github actually reveals the opposite... almost everyone uses std::endl and almost no one uses std::flush (94% use std::endl, and 6% use std::flush).

I am also in the std::endl camp and find it absurd when people bike shed over it. It's the most intuitive/least surprising behavior (based on Stack overflow questions) and how almost all other mainstream languages behave (flush on new line), and as such it should be the default choice.

The use of ... << '\n' << std::flush is best when you want to explicitly call out that behavior because of performance reasons or some other exceptional circumstance.

> Also, flushing on every newline is a needless pessimization.

Maybe, but when you're debugging it's essential. Those debugging cout's aren't going to be there in production.

cerr should flush on \n too by default, AFAIK.

cerr shouldn't be buffered... that's what clog is for

Ah, I thought it was line-buffered, but apparently I was wrong.

Just use cerr for debugging. It is not buffered so it always outuputs, even in unexpected crashes.

I wish it would but this is just not what I observe here, I have to flush explicitly to get things to show on the console

std::cerr being unbuffered is one of its defining features. If you're not seeing that, either you (or some dependency you use) disables it, or it's a bug in your C++ stdlib.

> Use of '\n' is always better for printing new lines.

Does this do the right thing on Windows?

Yes! For the same reason it does the right thing in C APIs. Which many people don't realize (understandably) until they read the fine print in docs.

If you read the specification of std::endl, it simply sends a "\n" and flushes.

Unless you explicitly set O_BINARY on stdout/stderr then LF is converted to CRLF, aka "text mode" vs "binary mode" for files.

Just in time for C++23’s long awaited std::print

https://github.com/cplusplus/papers/issues/884

The despair of iostream coming to a language near you.

Nothing wrong with the stl, their error messages are <std::iostream::comment::__p<e<r<f<e<c<t<std::iostream::nesting::l<__y c> o> m>__p>r>e>__h>__n>s>I>b>l>e at line 13256 of inaccessibleandsomewhatobfuscatedheaderstream.hpp

The STL and iostream are totally different libraries.

STL is pretty much the foundational work of practical generic programming, while iostream is a trashfire of a feverdream someone had about "hey it'd be really cool if I overload operators to do I/O, wouldn't it? That would look so futuristic in code!1". The original STL implementation has even been formally verified.

But you're right, modern stdlib implementations for C++ tend to be essentially obfuscated beyond any notion of readability.

I tried Raku a few times, but thought it to be too slow for me. Grammars seemed kinda nice, but somewhat frustrating.

One good thing about Raku is that I thought it had what I called "a programmers mindset". To put it another way, the language seemed to be structured in such a way to "think the way I think", rather than the other way around.

nowadays everyone does programming language

If by "nowadays" you mean two decades ago up through now and by "everyone" you mean Larry Wall and the Perl community then I guess so.

Raku is the new name for Perl 6, which began way back in the year 2000.

>nowadays everyone does programming language

By design/specification, Raku[0] is over 20 years old. The Rakudo[1] compiler is a lot younger, with its first stable release back in 2015.

[0]: https://raku.org/

[1]: https://rakudo.org/

Reply on news.ycombinator.com