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

211–220 of 253 posts

Re: Rust's 2018 roadmap

#211

Post by jcelerier »

pleasecalllater wrote: post #196
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? 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.

I'm also non native english and I would much rather have people focus on fixing bugs rather than submitting idiotic translations.

Exhibit A: latest GCC error message,

"le déréférencement d'un pointeur transtypé à la barbare va enfreindre la règle selon laquelle une zone mémoire ne peut être accédée que par un seul pointeur".

Nowadays I just set LC_ALL=C on my machines since translations are so bad.

Re: Rust's 2018 roadmap

#212

Post by pleasecalllater »

kiriakasis wrote: post #205
pleasecalllater wrote: post #196

Earlier quoted context omitted.

> 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.

I agree that tools should be better, but i believe that "just use good tools" might not be a viable solution for the parent.

No, there is no justification for bad tools. If someone makes a tool only for ASCII, fine, but don't expect that people will say it's a good tool.

Even huge sites have problems when I want to use my real name, or the name of the city I live in. They are usually made by US companies, which is strange, as you have all kinds of people there, with different names. Unfortunately the reality is that those US companies don't care about supporting normal characters people use. Even websites like Upwork don't allow me to enter my real name. Isn't that strange? I have told them about that months ago, nobody cares.

So getting to the real problem: supporting unicode is not as hard as it seems, just use from the beginning.

Re: Rust's 2018 roadmap

#213

Post by masklinn »

matthewrudy wrote: post #208
masklinn wrote: post #197

Earlier quoted context omitted.

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

in which case you'll need to add a comment to remember what it says: print("\u4f60\u597d\uff0c\u4e16\u754c\uff01") # "你好，世界！"

That makes the source file not-ascii again.

Re: Rust's 2018 roadmap

#214

Post by masklinn »

saurik wrote: post #207
icebraining wrote: post #204

Earlier quoted context omitted.

I'm not opposed to unicode in source code, but we do put all string literals in external files, by using gettext. Your example would be: print(_("Hello World!")) And then a zh.po file with: #: file.py:1 msgid "Hello World!" msgstr "你好，世界！"

This assumes then programmer speaks English and Chinese is a "translation".

Or even just the second part. One could imagine software with chinese as the reference and english as the translation.

I guess that's one good thing about Java's resource bundles, though they don't help source readability.

Re: Rust's 2018 roadmap

#215

Post by golergka »

lucideer wrote: post #209
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…

> 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 If there are tools that break when this happens, those tools need to be fixed. Bugs in those tools need to be found (through usage) and reported. If we avoid the problem by strictly sticking to ascii in source files, that amounts to sweeping those bugs under the carpet. Furthermore, an…

This is all good and well, but there are also projects that need to be delivered in this imperfect world and imperfect tools that we have. And I'd rather assume the worst of the world in the beginning and take appropriate precautions than debug some tooling problem right on the day of the release.

Re: Rust's 2018 roadmap

#216

Post by syeaj »

steveklabnik wrote: post #186
syeaj wrote: post #158

Earlier quoted context omitted.

While the book is really top notch (I'm usually not a fan of programming language books), there's something to be said for not introducing all concepts at once. A scripting language has many of the same concepts, but not lifetimes, etc. Not to say objects are intuitive!

Thanks! While this is true, those languages have stuff Rust doesn't as well. Take Ruby, for example: Rust doesn't have method_missing, or eigenclasses, or inheritance. "How do I know which method gets invoked" is much more complex.

Okay, I yield. I think you may be right. I've been thinking a lot about how I'll teach my children STEM topics and I've grappled with the idea of teaching Rust. One of the things I like about it is that you know the behavior at compile time, unlike Ruby or even C.

Re: Rust's 2018 roadmap

#217

Post by steveklabnik »

kowdermeister wrote: post #210
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…

Long for sure, but I really miss practical use cases, for example: > Asked how long the string is, you might say 12. However, Rust’s answer is 24: I get that, `.len()` is tricky, but why not include an easy, common way to determine character length of a string in the documentation?

There are different concepts of length depending on what you need. And not all of them are in the standard library, and hence, the book.

“Character length” is not a Unicode concept, for example.

Re: Rust's 2018 roadmap

#218

Post by lucideer »

golergka wrote: post #215
lucideer wrote: post #209

Earlier quoted context omitted.

> 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 If there are tools that break when this happens, those tools need to be fixed. Bugs in those tools need to be found (through usage) and reported. If we avoid the problem by strictly sticking to ascii in source files, that amounts to sweeping those bugs under the carpet. Furthermore, an…

This is all good and well, but there are also projects that need to be delivered in this imperfect world and imperfect tools that we have. And I'd rather assume the worst of the world in the beginning and take appropriate precautions than debug some tooling problem right on the day of the release.

You're right, economic incentives do usually favour ignoring/avoiding difficult problems and increasing technical debt. but I'd generally like to approach that as a pragmatic balance between what should be done and what needs to be in the short-term.

Re: Rust's 2018 roadmap

#219

Post by Grue3 »

jcelerier wrote: post #211
pleasecalllater wrote: post #196

Earlier quoted context omitted.

> 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.

I'm also non native english and I would much rather have people focus on fixing bugs rather than submitting idiotic translations. Exhibit A: latest GCC error message, "le déréférencement d'un pointeur transtypé à la barbare va enfreindre la règle selon laquelle une zone mémoire ne peut être accédée que par un seul pointeur". Nowadays I just set LC_ALL=C on my machines since translations are so bad.

Just today I was trying to install a new version of Postgres on Windows. For some reason they decided to detect system language and print all error messages in Russian... in the wrong encoding, so it looked like lorem ipsum written in Wingdings font. Took me ages to understand what the problem is. Just use English for god's sake.

Re: Rust's 2018 roadmap

#220

Post by icebraining »

saurik wrote: post #207
icebraining wrote: post #204

Earlier quoted context omitted.

I'm not opposed to unicode in source code, but we do put all string literals in external files, by using gettext. Your example would be: print(_("Hello World!")) And then a zh.po file with: #: file.py:1 msgid "Hello World!" msgstr "你好，世界！"

This assumes then programmer speaks English and Chinese is a "translation".

It's just a placeholder, you can use anything. The company I work for, and its clients, are not in English-speaking countries either.
Post reply on HN