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

101–110 of 132 posts

Re: Exploring Rust (from C#)

#101

Post by progman »

gjm11 wrote: post #20
skoczymroczny wrote: post #8

Earlier quoted context omitted.

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). 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 backgro…

> 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 systems programming only. Redox is the only reason for me to learn Rust.

> The one thing is its rule for when two identifiers are the same.

First it looked strange to me as well. However there are actually good reasons to avoid case sensitivity.

http://blog.codinghorror.com/the-case-for-case-insensitivity...

As for the user_sort and use_rsort example, such semantic errors can easily be fixed by qualification (a.user_sort and b.use_rsort). Errors like the following one however are very hard to fix in case sensitive languages like C++ and probably even Rust:

  module A:  func smart_func (x,y) = do_this
  module B:  func smart_Func (x,y) = do_that
  module C:  func Smart_Func (x,y) = do_something_else
main:

  import A, B, C
  smart_func (a,b)
hmm ... smart_func(a,b) doesn't work. Seems to be a typo. Which function did the author really mean?

Nim would reject such a mess in general.

The developers of Nim have implemented a lot of nice features. A really silly idea however are strong spaces. No serious developer would ever use such a dangerous "feature". It should be removed from Nim.

https://github.com/nim-lang/Nim/wiki/Whitespace-FAQ

Re: Exploring Rust (from C#)

#102

Post by progman »

naasking wrote: post #41
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…

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

Re: Exploring Rust (from C#)

#103

Post by progman »

greydius wrote: post #73
bryanlarsen wrote: post #65

Earlier quoted context omitted.

Sure, it's a misfeature, IMO, but it's certainly not a reason to write off the language. No matter what language you use, if you have two variables named myVariable and my_variable in the same scope, you've created a huge land mine in your code, and your linter should complain. Eventually somebody's going to come along and mix the two up. The fact that nim blows up differently than every other language just makes it…

> if you have two variables named myVariable and my_variable in the same scope But that's not the situation in the example. user_sort and use_RSort are perfectly fine identifiers that no reasonable person would expect to be interpreted as the same.

Such a conflict can be resolved easily by qualification (a.user_sort and b.use_RSort). What's the problem?

Re: Exploring Rust (from C#)

#104

Post by progman »

gjm11 wrote: post #69
nyan4 wrote: post #59

Earlier quoted context omitted.

This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity. #1: those variables have to be in the same scope or be procs working on the same types to be an issue. #2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's co…

I suspect this criticism usually comes from people who don't use Nim because anyone inclined to be bothered by it will not use Nim for that reason. I agree that "just keep a consistent style" is a good approach for single-person projects. It's harder to keep it working well as you get more people working on the code, though.

Actually Nim's attitude is more suitable for group work because every group can have its own style of coding. A simple transformer could be used to normalize the code. However it would force the developers to qualify all imported conflicting names which is a good idea anyway.

You cannot do this in C++ and Rust. There you actually have to keep a consistent style.

Re: Exploring Rust (from C#)

#105

Post by progman »

pif wrote: post #24
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…

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 :-(

Re: Exploring Rust (from C#)

#106

Post by progman »

tavert wrote: post #62
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…

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

Re: Exploring Rust (from C#)

#107

Post by progman »

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.

> Your comment is the only one I have seen making such a big issue about the variable naming.

It reminds of people who dislike Lisp only for its "ugly parentheses".

Re: Exploring Rust (from C#)

#108

Post by kibwen »

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…

  > Errors like the following one however are very hard to 
  > fix in case sensitive languages like C++ and probably 
  > even Rust
No, in Rust the compiler will emit a style warning if you have a function whose name includes capital letters. This can be toggled off (and also elevated into a hard error), but it's always on by default.

Furthermore, when you import a module Rust keeps it namespaced under the module's name, so you never need to worry about names accidentally colliding or being unsure as to where a symbol comes from. You have to use an explicit glob import to pull in all of a module's public items into the current namespace.

Furtherfurthermore, Rust warns when you import a symbol and then don't use it, so even if you name all of these functions differently and ignore the style warnings and glob-import the modules, then you'll get yet another warning when you fail to ever use two of the symbols.

Furtherfurtherfurthermore, Rust doesn't allow symbols with the same name to exist in the same namespace, so even if you went back and fixed all those functions to comply with the style warnings, you'd get compilation errors if you continued to glob-import any of the two of them.

Re: Exploring Rust (from C#)

#109

Post by kibwen »

tomp wrote: post #100
Rusky wrote: post #66

Earlier quoted context omitted.

Even if the language pulled some magic trick where it could verify collection implementations without unsafe, all you'd have done is move the unsafety into the type checker and compiler backend. The only difference is that Rust 1) moved some of that into the stdlib and 2) lets third parties extend it to provide more guarantees. Given this, I think you're drawing a rather arbitrary line- Rust (the compiler + stdlib, o…

It does guarantee memory safety... until you need to write your own collection. Then it explicitly endorses unsafe code (as opposed to offering a more powerful proof engine). I'm find with trusting something (compiler, proof engine, stdlib), but the issue is that safe Rust is barely a complete language!

This is a strange argument. The `unsafe` keyword only lets you do the following: dereference unsafe pointers, call unsafe functions (which usually either dereference unsafe pointers themselves, or are just wrappers over C functions, which are obviously unprovable), and mutate static data. Saying that safe Rust is "barely complete" is just as good as saying that Python is "barely complete" due to the fact that it doesn't allow you to read arbitrary locations in memory.

Re: Exploring Rust (from C#)

#110

Post by Certhas »

blub wrote: post #39
Certhas wrote: post #29

Earlier quoted context omitted.

> The facts that Rust is quite young, has no shipping hero project as a case study and there are basically no jobs available are adding fuel to the fire. That's a bit of a misrepresentation though. Rust code is shipping in Firefox, and more importantly, Servo will have an alpha release in June. The close integration between Rust and Servo development, as well as the rigorous pre 1.0 process also set it apart from oth…

I want to see a large-scale system written in Rust or a security-critical piece of infrastructure where it's demonstrable that defects were reduced. Of course, no one is obliged to fulfill my wish, it's just a criteria that I use to evaluate the maturity of a tool and that I think is very reasonable.

I think a browser is a large-scale, security critical piece of infrastructure.

Whether servo will truly have fewer leaks and security issues we'll have to see. They are also aiming for mor parallelism and therefore faster rendering....

Post reply on HN