Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I tend to judge languages solely on their aesthetic utility unless they're designed to make something very difficult possible (e.g. Erlang). And this one isn't any more pleasant to read than Java or C, it just happens to be a little different. Given the long list of advantages to using Rust, why they can't use an existing syntax?

Also, I've always felt queasy about using -> or => as arrows. And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down.



> And the word 'let' instead of 'def' or 'var' gives me a strange flashback to middle school which I can't quite pin down.

I agree about the 'let' part. Why isn't "int i = 0;" sufficient?


I suspect this is an artifact from their stance on mutable state, and some inspiration from more functional languages. There certainly isn't much harm in being clear where you are initializing variables. I would say that using actual english words rather than brief non-words such as def or var makes the syntax more readable.

If the keyword really bothers you that much, couldn't you fork the project and perform a global find/replace? (yes I realize that _maintaining_ a fork like that could be nightmarish, but the point still stands)


int i = 0 not code because modern compilers don't need to know about int at first. The compiler wants to now that you creat a variable the type is not importend at that moment. Thats why most new languages like go or scala have the type after the inizalisation.


> int i = 0 not code because modern compilers don't need to know about int at first.

Where "modern" means "any non-utterly-stupid compiler built in the last 40 years or so".


Why would you have to specify it's an int when the compiler is perfectly able to discover that himself?


Is it an int? An int32? An int64? Is it unsigned? Maybe it's actually a float which just happens to be initialized to a valid integer value. In that case is it a float or a double?

Literals can map to multiple types, and there hasn't yet been discovered a satisfactory way--apart from guessing in cases of ambiguity--to support type inference for literals.


That depends on your definition of "satisfactory" - F# uses strong type inference on literals and there is no ambiguity. Of course this means that distinguishing between types requires metadata, for example 42uy is an unsigned byte, 42L is an int64, 42I is a bigint and 42N is a BigRational. I think this is satisfactory, although you might disagree.


Sorry, I meant "inference for overloaded literals."


To make sure the programmer realizes this as well.

(It's a reasonable opinion, albeit not mine.)




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: