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

Rust 1.53

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Rust 1.53

#41

Post by borodi »

high_density wrote: post #17
beforeolives wrote: post #15

Earlier quoted context omitted.

> Maybe, and this is a fat maybe, Greek symbols could make the odd write-once math or scientific code easier to read. The Julia community has been trying really hard to convince people that this is a good idea and I'm still not on board with it.

maybe we can have some keyboard plugin/"mode" that merges letters to form symbols in special way? Korean windows have a "special-emoji" keyboard that can be invoked by: 1. type a charactor 2. press 'hanja' key 3. (wild special character selection menu appears) example: § (from 'ㅁ') / ㈜ (from 'ㅁ') / ㎖ (from 'ㄹ')

Julia does this in a pretty simple way, you type \lamdba then press tab and it becomes λ, emojis and many other things work like this, so typing them is very wasy.

Re: Rust 1.53

#42

Post by nonameiguess »

beforeolives wrote: post #15
jagger27 wrote: post #12

Earlier quoted context omitted.

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.

> Maybe, and this is a fat maybe, Greek symbols could make the odd write-once math or scientific code easier to read. The Julia community has been trying really hard to convince people that this is a good idea and I'm still not on board with it.

This is the one thing I used to love about Maple back in college. You can compute directly with mathematical symbols, draw matrices and rational numbers the same way you would on paper, and the language runtime understands it. Too bad it's a $5000 license or whatever.

Re: Rust 1.53

#43

Post by kibwen »

Pet_Ant wrote: post #39
airhead969 wrote: post #32

Earlier quoted context omitted.

Can't you just use poop emoji in comments and search for them like TODOs?

But then others won't feel dirty when they use the method. The goal is to make people feel bad when they add more usages of it and make it harder to remove. This is the case when it's easier and faster than the proper way. When there is crunch time it's hard to push your lead to reject the PR so it's soft pressure and it's apparent at the call site whereas a TODO in the method definition is not.

There is a famous story of a codebase that used `sleep` calls for this purpose. Start by sleeping 1 ms every time that the undesired function is called. Next release, up it to 10 ms, then 100 ms, and so on.

Re: Rust 1.53

#44

Post by runarberg »

jagger27 wrote: post #28
freeopinion wrote: post #23

Earlier quoted context omitted.

Your statement here has so many qualifiers that it's hard to treat it as a general rule. "English speaking world" "untypeable" "public API" Even then you exempt Greek symbols. I suppose you might be willing to accept ¢ or €. Of course, "untypeable" is very ambiguous. Still, not all code is "public API" and not all code is intended for the English speaking world. So I think it's great to support non-ASCII symbols. よろし…

I was not trying to argue against its general support, only that for this English-speaking audience (HN) there are very limited use cases.

Even if english speaking, it is still ambiguous. For example in my keyboard the micro sign (µ; not to be confused with the Greek small letter mu) is easy to type (AltGr + M). I bet this is the same for the majority of HN users. The US keyboard doesn’t use third level shift (usually AltGr) so most people that use US keyboard exclusively are unaware of this. Whenever I see people using the Latin small letter U (u) instead of the micro sign, all I think about is how restrictive the US keyboard actually is, and how much of a shame it is that the culture which predominantly uses this restrictive keyboard design came to be the dominant when designing computer interfaces.

Re: Rust 1.53

#45

Post by jcranmer »

mynameisash wrote: post #40
high_density wrote: post #17

Earlier quoted context omitted.

maybe we can have some keyboard plugin/"mode" that merges letters to form symbols in special way? Korean windows have a "special-emoji" keyboard that can be invoked by: 1. type a charactor 2. press 'hanja' key 3. (wild special character selection menu appears) example: § (from 'ㅁ') / ㈜ (from 'ㅁ') / ㎖ (from 'ㄹ')

It would be nice if this were built into Windows, but in lieu of that, I have been using WinCompose[0] for several years for typing diacritics (as part of my learning French). For example: * ALT e' = é * ALT u " = ü * ALT n ~ = ñ It's not limited to diacritics; you can type ligatures (ALT ae = æ), extended characters (ALT [/] = ), I assume the majority of UTF (ALT #G = 𝄞) and so on. And yes, even emoji (ALT ALT alem…

> It would be nice if this were built into Windows, but in lieu of that

Something that's basically equivalent is builtin. Just switch your keyboard from EN-US to EN-INTL, and now several accent characters become dead keys, so ' e = é, etc.

Re: Rust 1.53

#46

Post by vvillena »

jagger27 wrote: post #12
BelenusMordred wrote: post #2

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

There's lots of non-english codebases out there, supporting symbols for their languages is a big deal.

In a way, it's in part a job for the dev tools. Autocomplete engines should be able to complete these symbols from an ascii-only hint. 'a' should offer "α" as one of the completion options, and 'bla' should offer "BLÅHAJ".

Re: Rust 1.53

#47

Post by eska »

divtiwari wrote: post #5

Should 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've started learning it in March when the pandemic hit and I lost my job, so I had free time. I just started by making a side project, a static site generator of course. Now at my current job I was able to use Rust for an IoT data acquisition project, and feel like I'm more productive than I am with C++, which I have 20 years of experience with.

The other day the partner company which is using the output of my software admitted to me that they are chasing some weird heap corruption error in QtCore.dll, and therefore cannot hit a deadline.. I was relieved that this is a thing of the past for me now.

When I run into a memory error now, it's somewhere in the unsafe code blocks I have in the wrapper around the shitty C libraries by other partner companies, that didn't document the conditions of their API properly.

Re: Rust 1.53

#48

Post by staticassertion »

divtiwari wrote: post #5

Should 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 learned rust just before 1.0. Probably one of my best decisions as an engineer. I now run a company where we're using it as the primary language for our services.

Re: Rust 1.53

#49

Post by staticassertion »

kaba0 wrote: post #29
zozbot234 wrote: post #21

Earlier 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++…

> but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc

This is sort of true, in that I might take reference where I used to take a value, or vice versa, but it's pretty trivial. It's extremely rare for borrow checking or memory layout to slow me down at all when refactoring.

Re: Rust 1.53

#50

Post by jdrek1 »

runarberg wrote: post #44
jagger27 wrote: post #28

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

Even if english speaking, it is still ambiguous. For example in my keyboard the micro sign (µ; not to be confused with the Greek small letter mu) is easy to type (AltGr + M). I bet this is the same for the majority of HN users. The US keyboard doesn’t use third level shift (usually AltGr) so most people that use US keyboard exclusively are unaware of this. Whenever I see people using the Latin small letter U (u) inst…

> For example in my keyboard the micro sign (µ; not to be confused with the Greek small letter mu)

The greek letter mu IS the micro sign, where do you think it comes from?

Post reply on HN