Live data from Hacker News

‘~’ is being removed from Rust

github.com

71–80 of 117 posts

Re: ‘~’ is being removed from Rust

#71

Earlier quoted context omitted.

Hmm... I don't understand why it has to be Text Editor vs IDE. The two concepts are orthogonal. One is for editing text; the other is for understanding and autocompleting text. If their concern is that there aren't any good tools for Rust yet, that'll be solved with time.

I think you are missing the point of the statement. If one was designing a language meant to be developed in an IDE, you can hold various assumptions which would influence how syntax shapes up. A trivial example which is not related to rust but I think serves as a decent example, you can assume the IDE will color/italicize/etc member variables to get rid of _var __var var__ nonsense. You can also use slightly less ve…

I'm not sure how interesting this topic really is. As an example, look at Smalltalk. Crazy easy syntax, and made to be used in an IDE that dwarf what most of us consider an IDE.

Re: ‘~’ is being removed from Rust

#72
post #9
post #5

Earlier quoted context omitted.

> `~` is harder to search for, as well as not on all keyboards. Which keyboards do not have a '~' key? How do those people type a path relative to their home directory? Use $HOME/foo/bar all the time?

> Which keyboards do not have a '~' key? Most euro keyboards need at least AltGr + key, possibly 2 keys (because ~ is a dead key, so a space is needed to insert the character itself) > How do those people type a path relative to their home directory? Use $HOME/foo/bar all the time? It's common to `cd; cd foo/bar`

It is not 1974, and people are not limited to typing the characters molded into the type wheel and keytops at the factory. At the moment, it's as easy for me to type × or † as it is to type + or _, and I would happily make it as easy to type λ or ← to get the benefit of reading code as such.

The situation with ~ is simpler; it's used by plenty of programming systems today, and any programmer who uses it and can't type it as easily as on a default US keyboard (i.e. with one modifier+key press) is not using their tools effectively.

Re: ‘~’ is being removed from Rust

#73
post #11

Feh. It's an interesting split between what I'll call the concisionists and the explicitists. As a concisionist, this change stinks. I appreciate that the "not on my keyboard" argument is a big deal, but I'd argue that just merits a change of sigil, not adding verbosity. Designing a language to be prolix just makes code more laborious to understand.

> As a concisionist, this change stinks.

Hardly. As thestinger argued so eloquently, legitimate use of the ~ are few and far between: typically, recursive data structure definitions, which are rare even when you go Recursive Crazy. (Functional programming would even avoid unique pointers, since they prevent sharing.)

From an information theoretic perspective, giving a special syntax for such an uncommon use doesn't make sense. If you want your language to be concise, you want the short-cuts to be used for frequent cases. Before we give a special syntax to unique pointers, we should address everything that's more often used. That would turn Rust into APL.

Since we don't want such a combinatorial explosion of special symbols, we're back to the good old Huffman encoding: short cuts for the frequent use cases, more verbosity for the rare ones.

Re: ‘~’ is being removed from Rust

#75
post #72
post #9

Earlier quoted context omitted.

> Which keyboards do not have a '~' key? Most euro keyboards need at least AltGr + key, possibly 2 keys (because ~ is a dead key, so a space is needed to insert the character itself) > How do those people type a path relative to their home directory? Use $HOME/foo/bar all the time? It's common to `cd; cd foo/bar`

It is not 1974, and people are not limited to typing the characters molded into the type wheel and keytops at the factory. At the moment, it's as easy for me to type × or † as it is to type + or _, and I would happily make it as easy to type λ or ← to get the benefit of reading code as such. The situation with ~ is simpler; it's used by plenty of programming systems today, and any programmer who uses it and can't typ…

Sadly, most people don't use a sane layout. Instead, they use the default layout. It's just the status quo bias at work, which explains why the qwerty layout and staggered key still exist, despite overwhelming evidence in favour of alternatives.

(To anyone who feels the urge to educate me on the Fable of the Keys, remember that typing speed is not the only worthy criterion. Comfort, RSI, and ease of learning, matter much more.)

Re: ‘~’ is being removed from Rust

#76
post #60

Earlier quoted context omitted.

I actually regret that comment. I feel I was being a bit too negative in my original post, and I don't want to add fuel to the fire by continuing the argument here.

No, no... I'm sorry if my comment sounded strange. I wasn't being ironic or snarky, I was being genuine. What are your thoughts regarding IDEs vs editors? It's an important topic.

Honestly, as a guy who works on a lot of old code that I didn't write, IDEs are a complete godsend. Features like 'find me everywhere this method gets called', or 'find everywhere this value gets written to', and just simple navigation between functions/files. They're a backbone of my maintenance programming strategies, and I don't know what I'd do without them.

I do all of my javascript coding in vim and don't miss IDEs so much, but that's because I mostly only work on my own javascript code. For large, multi-person projects I massively prefer working inside an IDE.

Re: ‘~’ is being removed from Rust

#77

Gee, with this few sigils remaining, Rust is going to have a very hard time finding widespread adoption, since it won't stand out from competing languages!

We still have "fn". :)

fn is my favorite keyword for function definition. "function" is too long. "def" doesn't say anything about functions (unless you read it as DEfine Function). "func" sounds too funny. "defun" always reads "defunct" to me.

And just out of curiosity, where did the rust designers get the inspiration for "fn"? I know plan 9 rc and clojure have "fn". Or maybe it's independent invention?

Re: ‘~’ is being removed from Rust

#78
post #77

Earlier quoted context omitted.

We still have "fn". :)

fn is my favorite keyword for function definition. "function" is too long. "def" doesn't say anything about functions (unless you read it as DEfine Function). "func" sounds too funny. "defun" always reads "defunct" to me. And just out of curiosity, where did the rust designers get the inspiration for "fn"? I know plan 9 rc and clojure have "fn". Or maybe it's independent invention?

Anonymous functions in ML, possibly.

Re: ‘~’ is being removed from Rust

#79
post #66
post #63

Earlier quoted context omitted.

words are easier grep for, but I'd rather read x = (2 * 2)/y instead of "x assign 2 plus 2 divide y"

Mathematical operators are well established with well known meanings, but the Rust-specific ~ is not.

It would be after a little while of using the language, I just don't think it should optimize for new users.

Re: ‘~’ is being removed from Rust

#80

Earlier quoted context omitted.

No, no... I'm sorry if my comment sounded strange. I wasn't being ironic or snarky, I was being genuine. What are your thoughts regarding IDEs vs editors? It's an important topic.

Honestly, as a guy who works on a lot of old code that I didn't write, IDEs are a complete godsend. Features like 'find me everywhere this method gets called', or 'find everywhere this value gets written to', and just simple navigation between functions/files. They're a backbone of my maintenance programming strategies, and I don't know what I'd do without them. I do all of my javascript coding in vim and don't miss…

I think the real key here is not ide friendliness, but "compiler as a service." The compiler, by definition, is already capable of understanding our code. If that understanding can be exposed as a standard api, we can build up a set of powerful capabilities for refactoring and much deeper programmatic transformations. With very large code bases, this is no longer just nice-to-have ... it is the next tool we should rationally insist on.
Post reply on HN