Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

191–200 of 253 posts

Re: Rust's 2018 roadmap

#191

Post by golergka »

cpach wrote: post #123
smoe wrote: post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

let hello = String::from("السلام عليكم"); let hello = String::from("Dobrý den"); let hello = String::from("Hello"); let hello = String::from("שָׁלוֹם"); let hello = String::from("नमस्ते"); let hello = String::from("こんにちは"); let hello = String::from("안녕하세요"); let hello = String::from("你好"); let hello = String::from("Olá"); let hello = String::from("Здравствуйте"); let hello = String::from("Hola"); This is such a beaut…

> let hello = String::from("שָׁלוֹם");

This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly.

Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're a lot of tools that we developers need to use on those, and their encoding issues tend to follow the Murphy's law and appear at the most inconvenient moment.

Edit regarding localization: all projects that I've worked on had localization in separate json or XML files, with automatic import/export from spreadsheets that would be filled by third party localization company.

This is the line of code I find my cursor on literally the moment I switch to HN:

questIcon.Text.text = ("Quest:" + World.current[index].template.trueId + "_title").T();

Where T() is the extension method from localization system. Why on earth would you include user-facing strings in the code itself?

Re: Rust's 2018 roadmap

#192

Post by jhasse »

Rusky wrote: post #149
jhasse wrote: post #140

Earlier quoted context omitted.

Yes, you should instead make sure everyone doesn't feel alienated, not only the people from a minority regarding their race, age or sex.

That... does seem to be the goal.

I wasn't talking about Rust, but wanted to give a direct answer to "Is it unjust to make sure people from a minority do not feel alienated?".

Re: Rust's 2018 roadmap

#193

Post by Dylan16807 »

golergka wrote: post #191
cpach wrote: post #123

Earlier quoted context omitted.

let hello = String::from("السلام عليكم"); let hello = String::from("Dobrý den"); let hello = String::from("Hello"); let hello = String::from("שָׁלוֹם"); let hello = String::from("नमस्ते"); let hello = String::from("こんにちは"); let hello = String::from("안녕하세요"); let hello = String::from("你好"); let hello = String::from("Olá"); let hello = String::from("Здравствуйте"); let hello = String::from("Hola"); This is such a beaut…

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

What tools care whether a file is ASCII or UTF-8?

Re: Rust's 2018 roadmap

#194

Post by littlestymaar »

staticassertion wrote: post #164
Rusky wrote: post #149

Earlier quoted context omitted.

That... does seem to be the goal.

No no no, you see, by making minorities safer we must then be making the majority feel less safe! Safety is a zero sum game after all.

> Safety is a zero sum game after all.

That's what we thought before Rust came, that you could only have safety if you sacrificied speed. But now we know it was wrong ;)

Re: Rust's 2018 roadmap

#195

Post by wodenokoto »

golergka wrote: post #191
cpach wrote: post #123

Earlier quoted context omitted.

let hello = String::from("السلام عليكم"); let hello = String::from("Dobrý den"); let hello = String::from("Hello"); let hello = String::from("שָׁלוֹם"); let hello = String::from("नमस्ते"); let hello = String::from("こんにちは"); let hello = String::from("안녕하세요"); let hello = String::from("你好"); let hello = String::from("Olá"); let hello = String::from("Здравствуйте"); let hello = String::from("Hola"); This is such a beaut…

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

> Also, can we please, please, please keep source code files as pure ascii

How do you propose that we write programs that interact with non-ASCII compatible language users? All string literals are to be saved in external, somehow non-source code files?

How would you go about writing a Chinese "Hello World"?

In Python 3, I would write

    print("你好，世界！")
I have no idea how you propose this should be done in pure ascii.

Re: Rust's 2018 roadmap

#196

Post by pleasecalllater »

golergka wrote: post #191
cpach wrote: post #123

Earlier quoted context omitted.

let hello = String::from("السلام عليكم"); let hello = String::from("Dobrý den"); let hello = String::from("Hello"); let hello = String::from("שָׁלוֹם"); let hello = String::from("नमस्ते"); let hello = String::from("こんにちは"); let hello = String::from("안녕하세요"); let hello = String::from("你好"); let hello = String::from("Olá"); let hello = String::from("Здравствуйте"); let hello = String::from("Hola"); This is such a beaut…

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

> Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker.

I'm a non native English speaker. That's why I hate tools, and websites which don't understand that people have different letters in names. Just use good tools.

Re: Rust's 2018 roadmap

#197

Post by masklinn »

wodenokoto wrote: post #195
golergka wrote: post #191

Earlier quoted context omitted.

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

> Also, can we please, please, please keep source code files as pure ascii How do you propose that we write programs that interact with non-ASCII compatible language users? All string literals are to be saved in external, somehow non-source code files? How would you go about writing a Chinese "Hello World"? In Python 3, I would write print("你好，世界！") I have no idea how you propose this should be done in pure ascii.

    print("\u4f60\u597d\uff0c\u4e16\u754c\uff01")
I'd guess?

Re: Rust's 2018 roadmap

#198

Post by enriquto »

golergka wrote: post #191
cpach wrote: post #123

Earlier quoted context omitted.

let hello = String::from("السلام عليكم"); let hello = String::from("Dobrý den"); let hello = String::from("Hello"); let hello = String::from("שָׁלוֹם"); let hello = String::from("नमस्ते"); let hello = String::from("こんにちは"); let hello = String::from("안녕하세요"); let hello = String::from("你好"); let hello = String::from("Olá"); let hello = String::from("Здравствуйте"); let hello = String::from("Hola"); This is such a beaut…

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

> Also, can we please, please, please keep source code files as pure ascii?

But why? In scientific computing (e.g., in C and in Python), I like to write my formulas using variable names like α, β, γ. Having to write alpha, beta, gamma uglyfies the formulas unacceptably.

Support for non-ascii variable names is actually my main reason to use clang instead of gcc.

Re: Rust's 2018 roadmap

#199

Post by Shoothe »

Shoothe wrote: post #83
tototomtoboro wrote: post #77

Earlier quoted context omitted.

Have you tried https://marketplace.visualstudio.com/items?itemName=rust-lan... ? You will need the rls from nightly but its working very nicely for me.

Nope, I'll try that out tomorrow, thanks for the advice! VS Code's handling of TypeScript really spoiled me but on the other hand it seems like tooling becomes more and more important in programming languages (e.g. Roslyn).

Rust (rls) works! Excellent. Maybe the Rust team should have a recommended tools page? (obviously curated)

Re: Rust's 2018 roadmap

#200

Post by smcl »

wodenokoto wrote: post #195
golergka wrote: post #191

Earlier quoted context omitted.

> let hello = String::from("שָׁלוֹם"); This brings back PTSD for anyone who implemented ad-hoc RTL and UTF-16 surrogate pairs support in an environment that lacked them. Thank g-d I insisted that we at least omit diacritics as nobody uses them and they're a huge pain to implement and QA properly. Also, can we please, please, please keep source code files as pure ascii? Asking as a non-native english speaker. There're…

> Also, can we please, please, please keep source code files as pure ascii How do you propose that we write programs that interact with non-ASCII compatible language users? All string literals are to be saved in external, somehow non-source code files? How would you go about writing a Chinese "Hello World"? In Python 3, I would write print("你好，世界！") I have no idea how you propose this should be done in pure ascii.

I think the main point is to remove the Chinese characters in the string literal and refer to some object which contains the contents of some already-parsed localisation file - and that's the file where the Chinese chars characters would live.

So you'd probably write something like:

    print(localisedStuff["zh"]["hello-world"])
This looks clunky in a little standalone example but if you can imagine having to build an app that supports many languages then this starts to make sense as you'd more likely have:

    print(localisedStuff[selectedLanguage]["hello-world"])
However I disagree with the original comment that non-ASCII chars shouldn't be supported in code - I think that Chinese, Arabic, Korean, Israeli (etc) speaking devs should be able to deal with string literals in whatever language they feel comfortable in.
Post reply on HN