I love the non-ascii character support although for me as an English speaker I wouldn't use it, but I'm sure there many Asian teams that would appreciate these changes
struct 人 {
名字: String,
}Rust 1.53
81–90 of 98 posts
Re: Rust 1.53
#82Should one learn Rust, lets say after 3-4 years, i.e by mid 2020s, once it becomes more mainstream? The syntax of Rust is a mix of OCaml/C++ and I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer, so it takes a lot of cognitive overload to master it. So is it worth learning now or later?
If you consider GitHub to be a reasonable metric of industry practice in general, then judging by these charts [ https://madnight.github.io/githut/#/pull_requests/2021/1 ], I would say that going mainstream in a couple years is not very likely at all. Tiobe [ https://www.tiobe.com/tiobe-index/ ] paints a similar picture. The number of Rust-specific jobs advertisements also don't seem to suggest a coming wave that emp…
Loom is a great example of the Java designers still not getting it. Taking on a lot of JVM complexity in order to reuse the same broken API.
Re: Rust 1.53
#83Earlier quoted context omitted.
> I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer This notion is common among those who are first considering Rust, but also quite overblown in practice. The only thing that reasonably qualifies as "esoteric" in Rust is borrow checking and lifetimes, and these can be mitigated by using very simple idioms/patterns like cloning objects via .clone() or using copy-on-writ…
Disagree - a low level language can’t really mask itself as high level, the abstraction will always leak. Don’t get me wrong, Rust is a really great language and it is a very welcome addition to the for a long time seemingly stagnant low level world, but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc —- something trivially done in high level languages. C++…
Actually, once you get used to Rust, what you “loose” on one side of the productivity (ownership/lifetime/dispatch) you gain on the other side with the ergonomics (enum, matches, expression, …). So our experience, is that at the end, you still a net positive on the productivity side plus the other benefits.
We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.
The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)
The biggest challenge is to train a full team on Rust.
Re: Rust 1.53
#84Sweet, cmp::min_by_key and cmp::max_by_key have finally been stabilized. Was sorely missing this little convenience in Rust, as it helps express a particular idea more clearly and succinctly.
Also the improvement to compile times on macOS due to the change in how debug info is stored is a nice productivity boost.
Re: Rust 1.53
#85> Identifiers can now contain non-ascii characters. All valid identifier characters in Unicode as defined in UAX #31 can now be used. That includes characters from many different scripts and languages, but does not include emoji. Don't despair fellow emoji devs, our time will come soon enough.
I cannot understand how this new "feature" could be considered a good idea.
Re: Rust 1.53
#86Earlier quoted context omitted.
I was not trying to argue against its general support, only that for this English-speaking audience (HN) there are very limited use cases.
I accept your caution. But it is fun for me to consider the differences in these: enum Size { P, XS, S, M, L, XL, XXL } enum Size { Petit, Extra_Small, Small, Medium, Large, Extra_Large, Extra_Extra_Large } enum Size { 小小小, 小小, 小, 中, 大, 大大, 大大大 } Which do you prefer: P, Petit, Petite, 小小小, 3小, XXS, 2XS? English is chalk full of non-English words. And lots of symbols are useful. Sometimes it's worth it to learn the sy…
That's not standard Chinese. Is it Japanese?
You could write SSS, SS, LL and LLL in English too.
By the way, it's 'chock-full' not 'chalk-full'.
Re: Rust 1.53
#87Should one learn Rust, lets say after 3-4 years, i.e by mid 2020s, once it becomes more mainstream? The syntax of Rust is a mix of OCaml/C++ and I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer, so it takes a lot of cognitive overload to master it. So is it worth learning now or later?
I would say definitely yes. While Rust asks the developer to worry about things they don't in other "memory managed" languages, its ergonomic and expressiveness add to the productivity. Once you get used to Rust, it becomes a net positive from a productivity side; at least this has been our experience, and you get a much more efficient and robust codebase.
However, here are the following caveats: - If you have a client or employer project to do now, and you are not yet familiar with Rust, do it with your language of expertise. Rust has to be learned before starting a new real project with it. - The real challenge is the cost to train an entire team on it. - Obviously, universal languages do not exist, so if you do AI, especially modeling, use Python (for now), web stuff use JS/TS, mobile stuff, Kotlin | Swift | Dart/Flutter. You can do some Rust on mobile and even web with WASM, but those are very niche use cases.
Re: Rust 1.53
#88Earlier quoted context omitted.
I accept your caution. But it is fun for me to consider the differences in these: enum Size { P, XS, S, M, L, XL, XXL } enum Size { Petit, Extra_Small, Small, Medium, Large, Extra_Large, Extra_Extra_Large } enum Size { 小小小, 小小, 小, 中, 大, 大大, 大大大 } Which do you prefer: P, Petit, Petite, 小小小, 3小, XXS, 2XS? English is chalk full of non-English words. And lots of symbols are useful. Sometimes it's worth it to learn the sy…
That's not standard Chinese. Is it Japanese? You could write SSS, SS, LL and LLL in English too. By the way, it's 'chock-full' not 'chalk-full'.
Thanks for the correction. TIL
Are you distinguishing Chinese or Japanese on visual appearance? Or by some other method?
I think 小中大 have an advantage over SML because SML have no meaning by themselves. 小中大 have the exact meaning we need. Granted, 中 kinda ruins that argument. Size::中 is very clear, but perhaps not more so than Size::M.
I'm actually curious. Which do you like better in code? P, SSS, XXS, 小小小, 3S, 3小, whole words, something else?
Re: Rust 1.53
#89Earlier quoted context omitted.
That's not standard Chinese. Is it Japanese? You could write SSS, SS, LL and LLL in English too. By the way, it's 'chock-full' not 'chalk-full'.
Thanks for the correction. TIL Are you distinguishing Chinese or Japanese on visual appearance? Or by some other method? I think 小中大 have an advantage over SML because SML have no meaning by themselves. 小中大 have the exact meaning we need. Granted, 中 kinda ruins that argument. Size::中 is very clear, but perhaps not more so than Size::M. I'm actually curious. Which do you like better in code? P, SSS, XXS, 小小小, 3S, 3小,…
I can't read Japanese. I just know they use characters slightly differently, so I
can't be sure they wouldn't write that.
The majority of people in the world can read and type 'S' easily, not so for '小'.
It seems you're basically arguing for pictograms. Like coding in Wingdings with a character map or something.
I would prefer to use a number scale, but if I had to choose from those options I would use whatever is most conventional in whatever area I'm in, which would probably be XXS.
Re: Rust 1.53
#90> Identifiers can now contain non-ascii characters. All valid identifier characters in Unicode as defined in UAX #31 can now be used. That includes characters from many different scripts and languages, but does not include emoji. Don't despair fellow emoji devs, our time will come soon enough.
In the English speaking world, I have a hard time justifying untypeable identifiers. Maybe, and this is a fat maybe, Greek symbols could make the odd write-once math or scientific code easier to read. It would be bonkers to use any non-ascii codepoints in a public API.
I tried doing this once, but it's not worth the pain of having to switch keyboards or copy-paste symbols