81–90 of 90 posts
Earlier quoted context omitted.
> thereby discouraging negativity from people in bad moods A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”.
> A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”. A counter punch from someone who feels attacked, right? Alternatively, you could accept the well-intentioned and fair criticism.
Earlier quoted context omitted.
> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usual…
> But they obviously didn't put any effort into the syntax. Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did. The result is... not very human-friendly IMO.
But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations.
Avoiding look-ahead (or especially the need to re-parse parts recursively) is a very good rule of thumb, sure. But when you need to decide whether you make the language simpler to read for the machine or more heavyweight for the human the answer should be absolute clear.
A modern compiler spends anyway most of its time in the semantic analysis (and depending on language, later optimizing the output). Optimizing the lexical part for the win of a few milliseconds on tens of thousands of lines just makes no sense. Today's computers are even fast enough to parse spoken human language fast enough. Again it's the analysis that takes time there.
The thing with Rust's syntax is especially annoying as almost everything else in that language makes a lot of sense. The concepts are neatly put together. It's explicit about the right things. It's considerably small and simple. It's almost a kind of sweet spot in language design, imho. And than it was hit hard with the ugly stick. That's a really sad point. And so needless.
I still hope they will come to their mind some day, and will start to offer a kind of "light" syntax at some point.
I really wish Rust could be more like Scala 3 on the outside, with a clean, minimal pythonic look & feel, and not like how someone put it before in a comment in this thread "When I look at Rust, all I see is `{};`". The later is also exactly my impression, sadly.
Earlier quoted context omitted.
> But they obviously didn't put any effort into the syntax. Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did. The result is... not very human-friendly IMO.
Exactly my point. This syntax was made for machines, not for humans. That's just not reasonable given how fast our computers are, and where the actual work for a modern compiler lies. But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations. Avoiding look…
Earlier quoted context omitted.
> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usual…
> they obviously didn't put any effort into the syntax This is an incredibly arrogant and ignorant statement to make, especially for someone who self-describes as "looking only occasionally into Rust". A whole lot of thought has been put into Rust's syntax. > The result is that the language reads partly like C++ My impression is that a certain amount of this was intentional; if their goal is to attract C++ developers…
> This is an incredibly arrogant and ignorant statement to make, especially for someone who self-describes as "looking only occasionally into Rust".
There is nothing arrogant or especially ignorant about my statement.
I'm primary using a language that has a shitload more features than Rust but gets along with a fraction of syntax.
So from my standpoint this is clearly something to criticize Rust for.
And this is very sad imho as I think Rust is a great language as such. A great language with a miserable syntax!
That's especially unfortunate as there are today no technical reasons to make ugly languages given how fast our computers are.
> A whole lot of thought has been put into Rust's syntax.
Who knows, maybe you're even right, idk.
But at least the result does not show, and that's the only relevant part.
> My impression is that a certain amount of this was intentional; if their goal is to attract C++ developers, they can't scare them off with syntax that's wildly alien.
That's imho nonsense. You can't "scare" C++ developers with syntax. They already endure one of the most broken syntaxes out there.
One does not use C++ because of its syntax, but in spite of that monstrosity!
One endures it as the language has other until lately unmatched properties. But C++'s look & feel is just a horrible historical accident all in all.
Rust would be attractive for its features no mater the syntax.
As we see it gets hyped and does very well for a newcomer even it's overly and needlessly ugly.
> Fewer characters doesn't automatically mean better readability; in many cases it can mean the opposite.
Sure.
But it's Rust that uses almost every ASCII char for some special purposes; imitating by doing so one or two of the worst examples history ever created.
The other thing is: Putting outright line noise everywhere only because that makes reading the code simpler for the machine is just the completely wrong priority. Less line noise makes reading code definitely simpler for humans. It has reasons why math notation looks like it looks after hundreds of years of optimization…
The whole point of good syntax is that you can mostly ignore the syntax and concentrate on the message. But Rust is like C++, you can often hardly see the actual content as it's burrowed under a pile of ugly needless syntax noise.
Copying a bad example is definitely nothing to be proud of. Rust failed in that regard miserably, imho. For completely incomprehensible reasons—which make it especially bad.
It's a real pity such a great language looks like a archaic accident!
Earlier quoted context omitted.
Exactly my point. This syntax was made for machines, not for humans. That's just not reasonable given how fast our computers are, and where the actual work for a modern compiler lies. But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations. Avoiding look…
It’s not just about parser throughput, it also helps with giving better error messages (because the compiler can make better sense of partially-broken syntax), which is something the Rust team cares a whole lot about.
Good error messages and robust error recovery for syntax errors are possible for almost any kind of language, even very weird ones, with today's modern parser technology. Just have a look at what for example Tree-Sitter does.
But the meat of good programming language error messages lies not in the syntax errors. It's in meaningful and informative semantic error messages. And these are almost completely independent of the language's syntax.
I get that this is mostly for fun, but this is as good a place as any to bring up an issue I rarely see discussed with any post about a new language. Well-established languages have tons of widely used, highly vetted libraries implementing functionality that doesn’t exist in the new language and would be totally impractical for an individual to implement themselves. For example, if I’m doing scientific computing, I n…
Totally agreed about FFI. I wanted to make it easy to interop with C code and write expressive bindings. Check for example the language bindings to LLVM's C API (fairly low level) and Tree-Sitter which is used internally (a bit higher level bindings) https://github.com/tibordp/alumina/tree/master/libraries/llv... https://github.com/tibordp/alumina/blob/master/libraries/tre... I think UFCS makes it quite nice for bind…
Earlier quoted context omitted.
This is even more impressive than LuaJIT's FFI in my opinion, which I previously thought was state of the art. You basically pass in a preprocessed header, and LuaJIT does the rest. All this to say, I feel that any FFI that requires you to manually write bindings is rubbish.
We lived with manual bindings to interface with C for years. Building in direct support for C itself is a huge leap forward in usability. In several ways it's even better than C++'s support for C.
I really don’t like the cognitive load of having to remember to use defer. We already have the scope defined, why add something extra? IMHO the way it’s used in Go is a workaround, of luck of destructors, not a feature. Edit: not a criticism on your language OP, which is better than what I could have ever built. Just a comment in the “defer” trend.
Earlier quoted context omitted.
It’s not just about parser throughput, it also helps with giving better error messages (because the compiler can make better sense of partially-broken syntax), which is something the Rust team cares a whole lot about.
I don't buy that. Good error messages and robust error recovery for syntax errors are possible for almost any kind of language, even very weird ones, with today's modern parser technology. Just have a look at what for example Tree-Sitter does. But the meat of good programming language error messages lies not in the syntax errors. It's in meaningful and informative semantic error messages. And these are almost complet…
I personally find rust syntax pretty neat. It's designed to be unambiguous to machines, but that also means it's unambiguous to humans. It has no () around tests, but it mandates {} because that prevents goto fail. It has the classic ML `;` as a separator, not terminator. It's a pragmatic blend of C++ (with generics, namespacing, and the C influence), and ML (expression based, easy to parse, let-binding and type inference).
Earlier quoted context omitted.
What an odd comment when the post contains this: > It is mostly for fun and exercise in language design, I don't have any grand aspirations for it.
> What an odd comment when the post contains this "It is mostly for fun and exercise in language design, I don't have any grand aspirations for it." You are being quite generous in calling the comment "odd". Here are five words to summarize that comment: disparaging, out of context, cruel, speculative, and pessimistic. pipeline_peak can do better. The HN guidelines are a good start. >> pipeline_peak : Another Rust lo…