Hacker News Reader

Comment by ncmncm | Hacker News Reader

The first thing I look for in something that claims to be a systems language is whether it provides anything that helps me out.

First and foremost, does it provide any primitive that can be used for automation? C++ brought destructors, Rust did a Drop trait. What do you have?

Second, does it provide any way to operate on types? C++ got templates, Rust offers generics. What do you have?

Third, does it provide useful compile-time logic?

If it lacks those, what does it bring to the table to make up for those gaping holes? This is not the '70s, or even the '80s. We have learned things since then. Have you?

View on HN

> We have learned things since then. Have you?

We have learned to read the documentation before we judge things.

Unless the front page points out at least something that is different or better about the new language compared to the alternatives, most people will not read the documentation.

I have learned to check on some basic facts before committing a huge block of time to another pointless exercise. The world seems mostly to have learned to serve up way more pointless exercises.

One choice is to just ignore everything, which almost always produces the right answer. But that will miss the thing that would have been worth looking into. Another choice is to try ways to filter out chaff. What is not a possible choice is to dig into everything that might conceivably be interesting.

One thing we can always be sure of: if it is meant to appeal mainly to C coders, it will fall flat, because everybody who is still using C has seen a thousand languages go by and passed on all of them.

I filter it a bit differently. There are enough people who will check out new language X; I don't have to. If it has merit, I'll keep hearing about it. Sure, I'll miss out on using X the first year or two out of the gate, but I don't actually need that. Yes, if X is all it's cracked up to be, I could have benefited from using it in that year or two. On the other hand, I didn't waste time learning a bunch of new languages trying to find the one that would be more useful than what I already have.

That is the "ignore everything new" choice. You are pointing out its lack of downside. On many days I would agree. (But you didn't. You spent enough time on it for this.)

If in fact the language would have turned out to be interesting, helping out early might make the difference between its fizzling out or getting traction. And, helping out might be a chance to learn a lot, or to ensure it will scratch your itch.

In this case, for me, none of that seems likely. As usual.

> But you didn't. You spent enough time on it for this.

Fair, to a point. But writing an HN comment is a bit lower investment than learning a new language well enough to evaluate it fairly.

> If in fact the language would have turned out to be interesting, helping out early might make the difference between its fizzling out or getting traction.

You may have that kind of pull; I don't. Nobody is going to care whether I like a language or not.

> And, helping out might be a chance to learn a lot, or to ensure it will scratch your itch.

That's somewhat more likely than me helping it gain traction. And, in fact, the earlier the input, the more influence it has at bending the language in the direction you want, because there's fewer voices at that stage. But there are too many potential languages for me to do that with very many of them, so we're back at the problem of choosing which ones to invest in...

(I once did take your approach, with the C++ STL, when was first announced on the newsgroups. It wasn't part of the compiler yet - it was a separate download. I found a bug in the initialization of the random number generator used to random-shuffle vectors. I, some random nobody on the net, emailed Stepanov and Lee, and got three fixes in the next two hours. I was amazed at the response. And the fix made it usable for what I was trying to do with it.

I think that's the only time I've invested in something brand new, though...)

> You may have that kind of pull; I don't.

I meant: one could do some of the work needed to make it ready for use. If not done, the language fizzles. Fizzling is the normal fate of any language, absent the miracle.

Hare looks a tiny bit better than C. That was D's problem: it was a tiny bit better than C++; now C++ is much, much better than what D had targeted. If you make Hare enough better than C to merit attention, it will be different enough for the C stalwarts to reject, but not powerful enough for C++ and Rust refugees to wash up onto.

This is an extremely selfish answer - by refusing to spend a few hours writing a front-page summary of your language, you're valuing the time of your m developers (where m is small) over that of the n developers who might want to evaluate the language (where n is large).

A language made by people who consciously make that tradeoff is almost certainly not worth even trying to learn. At least, if you're looking for a language that will actually act like a force-multiplying lever and save you time. Like, you know, programming languages are meant to do.

This is a gift to the world, so they aren't selfish. You are demanding, and you have no right to demand anything of random strangers on the Internet. Nobody is required to market their work as you demand, or even try very hard to seek new users. Often, slow growth is better.

Maybe someone not on the team will write a decent review of the language, and we will find out more. Hopefully that person will read the documentation and actually try out the language.

> You are demanding, and you have no right to demand anything of random strangers on the Internet.

In which case, the developers of this language are demanding that I spend my valuable time trying to read through their documentation to figure out if this language is good for me, in which case I reply: my time is also a gift and you have no right to demand that of me - I'm going to go and look at another language, and suggest that friends and fellow developers do the same.

Most systems don't merit reading the documentation; if it doesn't look markedly better, I'm moving on.

From my brief look at the documentation, the answers look like this: they have a defer statement much like Go's, they don't seem to have any form of generics, they don't seem to have any form of comptime logic.

They really need a section on the landing page to compare Hare to Zig. (And to C, for that matter.)

It seems that Hare has some restricted comptime logic. See section 6.8 of the spec [1]

[1] https://harelang.org/specification.pdf

> they don't seem to have any form of comptime logic

Or macros, not even textual C-style ones. Non-starter for me.

Macros were one of the biggest mistakes that C allowed, along with the undefined behavior.

Not allowing macros means a more standardized reference implementation, which translates to a more readable code overall.

Simple textual substitution macros are indeed pain.

Nicer, AST-level macros can be better, but can also be a pain (see Lisp, C++ for examples of either).

Reply on news.ycombinator.com