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

Exploring Rust (from C#)

nblumhardt.com

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Exploring Rust (from C#)

#111

Post by Manishearth »

elcritch wrote: post #95
kazagistar wrote: post #84

Earlier quoted context omitted.

> You will never be able to get both 100% guaranteed memory safety and low level control/performance. Sure you can. You just need a full fledged proof engine instead of "merely" a type system.

This. There's no reason the smaller bits of `unsafe` code couldn't be verified with a proof system (ala COQ). Very few systems can be completely `true` in a mathematical sense, including math itself. IMHO, this is a self-defeating argument. E.g. a form of: "math isn't provable so math sucks!". In the long run, this viewpoint would prevent moving to a system with 5% unsafe/95% safe which could be much more readily pro…

This is already being worked on http://plv.mpi-sws.org/rustbelt/

Re: Exploring Rust (from C#)

#112

Post by gjm11 »

progman wrote: post #101
gjm11 wrote: post #20

Earlier quoted context omitted.

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring…

> Nim is frustrating I have used Nim heavily for more than a year now, and it turned out to be the most productive language I have every used. Nim could be considered a modern Lisp with infix notation and Python like syntax with native C performance. The macro system is incredibly well designed and easy to handle. I also tried Rust, and it turned out to be much more complicated and time consuming. I would use it for…

> there are actually good reasons to avoid case sensitivity

My problem with Nim's identifier syntax rules are not about case-sensitivity. I have happily used case-sensitive languages and case-insensitive ones. My problem is with ignoring punctuation in identifiers.

> such semantic errors can easily be fixed by qualification

Once you notice that there's a problem. The trouble is, you might not.

> [three things with names like smart_func but different case]

Again, case-insensitivity is a red herring here as far as I'm concerned.

Re: Exploring Rust (from C#)

#113

Post by gjm11 »

progman wrote: post #102
naasking wrote: post #41

Earlier quoted context omitted.

Case-insensitivity I get, but deleting underscores? Yikes. I don't like Nim for other reasons, but that's a huge one.

The idea is that develoers prefer different styles of coding. Some like doThisAction, others prefer do_this_action, others Do_This_Action. Nim supports all styles. A simple reformatter can be used to transform the code of a project into a normalized form. Such an attempt would be very dangerous in C++.

So the idea is that, say, you'd have hooks in your version control system so that Alice always sees lowercase_with_underscores, Bob always sees camelCaseLikeThis, and Charlie always sees camel_Case_With_Underscores; and then each developer sees a version of the code in which everything is consistent, but it's a different consistent version for each? (And the thing in your actual repository is whatever it is -- it could be w_i_t_h___t_o_o___m_a_n_y___u_n_d_e_r_s_c_o_r_e_s for all anyone need care.)

That's certainly better than having different bits of the code use different identifier styles. But it feels somehow a fragile way to do things. And I worry about encouraging bad habits in teams that don't set things up with such care.

And... can you really make a simple reformatter that will consistently do the right thing? Identifiers may make reference to things whose capitalization shouldn't be canonicalized. HTML. TeX. iPhone. DrMemory.

(Also, though this is a bit of a cheap shot: note that the three identifiers in your first paragraph are not equivalent according to Nim's rules.)

Re: Exploring Rust (from C#)

#114

Post by naasking »

progman wrote: post #102
naasking wrote: post #41

Earlier quoted context omitted.

Case-insensitivity I get, but deleting underscores? Yikes. I don't like Nim for other reasons, but that's a huge one.

The idea is that develoers prefer different styles of coding. Some like doThisAction, others prefer do_this_action, others Do_This_Action. Nim supports all styles. A simple reformatter can be used to transform the code of a project into a normalized form. Such an attempt would be very dangerous in C++.

I don't see the advantage in supporting all styles. What you describe sounds like a pretty trivial benefit compared to breaking all of your ordinary text manipulation tools and violating the principle of least surprise.

Re: Exploring Rust (from C#)

#115

Post by gjm11 »

progman wrote: post #105
pif wrote: post #24

Earlier quoted context omitted.

Thanks a lot! I had never heard of Nim before, and I'll never ever try to know more. Such a gigantic error is a triple NO.

Thirty years of C obviously has fixed the mindset of many developers so much that they don't even want to think in different ways :-(

Please don't leap so quickly to psychoanalysing the presumed intellectual failings of people who disagree with you.

(I do not think your analysis is anywhere near correct in my case, even though I think Nim's identifier comparison rules are very unwise.)

Re: Exploring Rust (from C#)

#116

Post by Rusky »

tomp wrote: post #99
scott_s wrote: post #93

Earlier quoted context omitted.

Since tomp objects to trusting code, then I agree with Manishearth: if you're never willing to trust code, then you can never have guarantees. Even the proof engine is trusted code.

Well, you have to trust something... Silicone manufacturer, CPU designer, the OS, the compiler... But the big difference is, if I can do proofs and the compiler breaks my trust, that's a bug in the compiler. On the orher hand, Rust disallows complex proofs entirely, so I have to use unsafe code and trust random humans!

The compiler is just as much written by random humans as anything else.

Re: Exploring Rust (from C#)

#117

Post by gjm11 »

vfclists wrote: post #98
gjm11 wrote: post #20

Earlier quoted context omitted.

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring…

Really, the view of a number of bloggers who have used Nim consider it the best among the new crop of languages around for whatever reason, variable naming not withstanding. Your comment is the only one I have seen making such a big issue about the variable naming.

https://news.ycombinator.com/item?id=8822925 https://news.ycombinator.com/item?id=8823314 https://news.ycombinator.com/item?id=8935233 https://news.ycombinator.com/item?id=8936140 https://news.ycombinator.com/item?id=8936452 https://news.ycombinator.com/item?id=8936394 https://news.ycombinator.com/item?id=8936542 https://news.ycombinator.com/item?id=9670410 https://news.ycombinator.com/item?id=9670103

Re: Exploring Rust (from C#)

#118

Post by tavert »

progman wrote: post #106
tavert wrote: post #62

Earlier quoted context omitted.

Is there any documentation or discussion on the justification for doing this? I'm scratching my head and asking why anyone would do this intentionally...

One reason among others: http://blog.codinghorror.com/the-case-for-case-insensitivity...

Way too ascii-centric. Getting case transformations right in the presence of unicode can be complicated.

Re: Exploring Rust (from C#)

#119

Post by zerker2000 »

tomp wrote: post #40
Manishearth wrote: post #33

Earlier quoted context omitted.

> the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught ver…

> This is not a con; this is the _point_ of unsafe. It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". > Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? I'm talking about the fact that the programmer has to write the code/algorithms in such a way that…

Non-atomic writes to a single memory location, from what may well be separate cores etc, happen essentially at random due to out-of-order execution. What are the downsides to using the value from the last thread ~spawned~, and calling it a day?

Re: Exploring Rust (from C#)

#120

Post by progman »

tavert wrote: post #118
progman wrote: post #106

Earlier quoted context omitted.

One reason among others: http://blog.codinghorror.com/the-case-for-case-insensitivity...

Way too ascii-centric. Getting case transformations right in the presence of unicode can be complicated.

Unicode in identifiers is ugly. I never use that.
Post reply on HN