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

What makes Nim practical?

hookrace.net

Post reply on HN
Print view View original

101–110 of 132 posts

Re: What makes Nim practical?

#101

Post by pcwalton »

jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

It doesn't seem like an accurate claim, as Rust also has the ability to reason about uniqueness of data. Rust uses a type system to do it—which, via Curry-Howard, qualifies as "automated proof technology" :)

It looks like Nim has some ability to reason about arithmetic identities natively, which is neat. In practice Rust uses iterators to encode the same sorts of common patterns in the type system.

Re: What makes Nim practical?

#102

Post by filwit »

nkurz wrote: post #69
bpicolo wrote: post #62

Earlier quoted context omitted.

Let's be realistic. If you have somebody naming variables: foo_bar = blah foobar = blah fooBar = blah That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.

I agree, but the problem is that you don't ever want to do this whether those are three different variables (or is that two?) or whether all are alternative forms of the same case/underscore insensitive name. Nim is going out it's way to make the syntax you have about legal (will all of these equivalent), which strikes me as a bad move. The best case for usability is that this "feature" never used, which makes it an…

In practice, resolving symbols is not really harder. Once you understand the symbols rules, your mind is very good at finding the match. Plus the real solution is proper IDE support with "goto definition". IMO, the benefits of semi-case-insensitivity (allow programmers to write how they want) outweight the issues it causes.

Re: What makes Nim practical?

#103

Post by filwit »

quotemstr wrote: post #74
dom96 wrote: post #72

Earlier quoted context omitted.

You can with NimGrep: http://nim-lang.org/nimgrep.html

If a language's lexical structure is so tortured that I need a special tool to grep it, I'm going to skip it and go back to the sanity of C++.

Ridiculous.

We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument. Especially since we have a tool (nimgrep) which addresses the issue and takes < minute to learn. Once Nim has better IDE support, no one will be grepping in the first place.

Re: What makes Nim practical?

#104

Post by filwit »

dom96 wrote: post #39
CyberShadow wrote: post #29

Nim has some good ideas but I can't get over the syntax: - Significant whitespace, but tabs are forbidden - No block comments, save for `discard """ ... """` - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

> - No block comments, save for `discard """ ... """` I believe a different syntax for those will be added soon: https://github.com/Araq/Nim/issues/1535

Not that it's even really needed... Just select the section of text and use your IDE's shortcuts to comment it out (which now works fine in any IDE due to comments no longer being part of the AST)

Re: What makes Nim practical?

#105

Post by fenollp »

codexon wrote: post #87
iopq wrote: post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

There's 1 thing that can't be done in Nim that you can do in Go though. And that is the goroutine system. Something like that needs to be explicitly baked into the language. You can try to emulate it with your own thread pools but you will never get the same level of preemption. However few people will ever need this feature, and erlang/elixir probably does it better, though at a the cost of speed.

But but but Go's concurrent scheduler just isn't preemptive. It's cooperative (and that's meh).

Re: What makes Nim practical?

#106

Post by marvy »

jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

Well, it will be hard to find a proof for it being the "only" language to do so, since as one of the commenters mentioned there is indeed at least one other. But http://nim-lang.org/manual.html#parallel-spawn seems to discuss it a bit. Or did you want more details? If so, what kind? Actually I don't know anything about Nim anyway, so whatever your question is I can't answer it.

Re: What makes Nim practical?

#107

Post by def- »

jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

This is all I found: http://nim-lang.org/manual.html#parallel-statement

Re: What makes Nim practical?

#108

Post by Araq »

jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

Disclaimer: I'm the lead designer of Nim.

pcwalton's remark is excellent but "automated proof technology" is not a well defined term. What I mean by this is that it goes beyond what a traditional type checker can do. I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong. Note that the very same analysis also proves your index bounds are correct.

Nim's disjoint checker is so experimental that its docs are indeed very terse and we only have a couple of test cases for now. That said, the disjoint checking is restricted to the 'parallel' statement, so its complexity only affects this language construct and not the whole language. You can think of it as a macro that does additional checking.

Re: What makes Nim practical?

#109

Post by Araq »

marvy wrote: post #106
jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

Well, it will be hard to find a proof for it being the "only" language to do so, since as one of the commenters mentioned there is indeed at least one other. But http://nim-lang.org/manual.html#parallel-spawn seems to discuss it a bit. Or did you want more details? If so, what kind? Actually I don't know anything about Nim anyway, so whatever your question is I can't answer it.

Well I did my homework. When you find another language that does it in a somewhat similar fashion, I'll happily change the website. ;-) I didn't think Rust counts, but since it's constantly changing, I will have a fresh look at it.

Re: What makes Nim practical?

#110

Post by dbaupp »

Araq wrote: post #108
jwiley wrote: post #92

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

Disclaimer: I'm the lead designer of Nim. pcwalton's remark is excellent but "automated proof technology" is not a well defined term. What I mean by this is that it goes beyond what a traditional type checker can do. I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong. Note that the very same analysis also proves your index bounds are correct. Nim's disjoi…

> I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong

Reading http://nim-lang.org/manual.html#parallel-statement point by point (disclaimer, I think Nim is very cool, but safe parallelism is one of Rust's strongest points):

> Every location of the form a[i] and a[i..j] and dest where dest is part of the pattern dest = spawn f(...) has to be provably disjoint. This is called the disjoint check.

The type system guarantees disjointness when necessary: a mutable reference `&mut` is guaranteed to be the only way to access the data it points to at any given point in time and iterators over mutable references preserve this guarantee, so disjointness-for-writing is automatic.

> Every other complex location loc that is used in a spawned proc (spawn f(loc)) has to be immutable for the duration of the parallel section. This is called the immutability check. Currently it is not specified what exactly "complex location" means. We need to make this an optimization!

Rust generalises immutable to "safe to be used in parallel"; everything that is (truly) immutable satisfies this, but so do, for example, memory locations that can only be used with atomic CPU instructions, or values that are protected by a mutex. There's no way to get data races with such things, so they're safe to refer to in multiple threads.

This is captured by the Sync trait (types which can be used from multiple threads in a shared way implement it): http://doc.rust-lang.org/nightly/std/marker/trait.Sync.html

> Every array access has to be provably within bounds. This is called the bounds check.

Rust's iterators give in-bounds automatically, but there's also no restriction about requiring bounds checks or not. (What does this rule offer Nim?)

> Slices are optimized so that no copy is performed. This optimization is not yet performed for ordinary slices outside of a parallel section. Slices are also special in that they currently do not support negative indexes!

I'm not sure what this means in the context of Nim, but passing around a Rust references never does a copy (even into another thread).

(Disclaimer 2: it's not currently possible to pass a reference into another thread safely, but the standard library is designed to support it, the only missing piece is changing one piece of the type system, https://github.com/rust-lang/rfcs/pull/458 , to be able to guarantee safety.)

Post reply on HN