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

A Quick Comparison of Nim vs. Rust

arthurtw.github.io

Post reply on HN
Print view View original

81–90 of 94 posts

Re: A Quick Comparison of Nim vs. Rust

#81

Post by duaneb »

dom96 wrote: post #78
duaneb wrote: post #75

Earlier quoted context omitted.

It has little benefit and requires new tooling to do simple refactoring like "rename". > Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form. This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.

I don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.

> It's not a "little" benefit in my opinion

Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor.

Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

Re: A Quick Comparison of Nim vs. Rust

#82

Post by dom96 »

duaneb wrote: post #81
dom96 wrote: post #78

Earlier quoted context omitted.

I don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.

> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

Re: A Quick Comparison of Nim vs. Rust

#83

Post by beagle3 »

kibwen wrote: post #80
nine_k wrote: post #76

Earlier quoted context omitted.

What would make a standalone Rust executable 20 MB in size? Last time I checked, Rust did not expect to carry libc with it, and can run entirely without a runtime.

For purposes of comparison, the Rust compiler (which is the most extensive Rust program on my computer at the moment) clocks in at 8MB. EDIT: Servo, which is the largest Rust program in existence at the moment, is 21MB. Personally I doubt the above claim that writing this in C would reduce the binary size by 95%. I obviously don't have any statically-linked written-in-C web browsers on hand, but if I poke around in C…

I am Updated my comment (GP) to indicate I was talking entirely about compiler size, not executable product size.

Is the 8MB rust compiler statically or dynamically linked to LLVM? It's been a few years, but I never got a statically linked LLVM-using program below 30MB (unstripped, I think stripped was 16MB but I don't remember)

Re: A Quick Comparison of Nim vs. Rust

#84

Post by duaneb »

dom96 wrote: post #82
duaneb wrote: post #81

Earlier quoted context omitted.

> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

> In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things?

You don't. It's a terrible idea to mix naming conventions.

> amyAtePizza has the same meaning as amy_ate_pizza.

WHY?! What possible benefit could it have? Why would you be mixing styles in the first case? Why can't you just remember which style hopefully your entire code base uses?

Re: A Quick Comparison of Nim vs. Rust

#85

Post by baldfat »

arthurtw wrote: post #33
skrebbel wrote: post #24

I like how articles like this help elevate Nim's status. To me, deep inside, Rust always felt like this grand high-stakes project, by wise people at this big experienced company Mozilla, and Nim felt like a hobby project that got out of hand. That's an entirely unfair judgment of course, but I bet more people feel that way. I like that Nim is starting to get the attention it deserves.

Yes, I think Nim deserves more attention, and that’s part of the reason I wrote this article.

Never even gave Nim a thought. Just read some and now I think I will try a little pet project with it. Really looks very interesting. I am wondering how the C, C++ , Objective C and JavaScript from one compiler works. personally I never want to touch JavaScript but it might be interesting how this works.

Re: A Quick Comparison of Nim vs. Rust

#87

Post by rm445 »

FeeTinesAMady wrote: post #48
okasaki wrote: post #35

Earlier quoted context omitted.

On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work

That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.

It's an unusual feature. Perhaps it calls for a 'go fmt' (nim fmt?) type tool that canonicalises names, to be automatically run on check-in.

Re: A Quick Comparison of Nim vs. Rust

#88

Post by scott_s »

dom96 wrote: post #82
duaneb wrote: post #81

Earlier quoted context omitted.

> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

I think it will put more cognitive load on the humans who read the code. Instead of doing a quick visual comparison to see if identifiers are the same, programmers will need to actually comprehend the two tokens, and then transform them in their head to see if they are the same. This sounds minor, but I think the cognitive load can add up. Visually comparing two tokens is not quite conscious thought, while comprehension is. It's something you'll always need to think about when reading code.

Re: A Quick Comparison of Nim vs. Rust

#89

Post by dom96 »

duaneb wrote: post #84
dom96 wrote: post #82

Earlier quoted context omitted.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

> In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? You don't. It's a terrible idea to mix naming conventions. > amyAtePizza has the same meaning as amy_ate_pizza. WHY?! What possible benefit could it have? Why would you be mixing styles in the first case? Why can't you just remember which style hopefully your entire code base uses?

I wouldn't mix styles inside my own code base. But what if I am using somebody else's library which uses a different style? The benefit is that I can then use the style I have been using in my code base to call the functions in that library without mixing naming conventions.

Re: A Quick Comparison of Nim vs. Rust

#90

Post by Dylan16807 »

dom96 wrote: post #82
duaneb wrote: post #81

Earlier quoted context omitted.

> It's not a "little" benefit in my opinion Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor. Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

You don't understand how having multiple highly-different forms for each name is harder to read? People read a token at a time whenever possible.

Nobody is arguing that you should be able to use multiple forms for different variables. They're arguing that you shouldn't use multiple forms at all.

Post reply on HN