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

Go channels, goroutines and GC available in Nim

forum.nim-lang.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#41

Post by kibwen »

fjehcjriendje wrote: post #16
pcwalton wrote: post #11

Earlier quoted context omitted.

> I'm sitting here feeling very impressed. Deferred reference counting has very good semantics for games. Not if you need to be thread-safe. > Even better, you can control the cycle detection part separately and run that part at an advantageous time. How would that work with multithreading? (Assuming you had a thread-safe GC, which Nim's isn't.)

So, I've noticed that over the past six months that every time something about Nim gets posted to HN, you make an effort to discredit the language. Care to offer an explanation why?

You yourself know that this claim is entirely unsubstantiated, as evidenced by the fact that you felt the need to create a throwaway account. pcwalton is an active commentator throughout HN in general, and garbage collection and parallelism are two of his areas of expertise. If his opinion is somehow uninformed, then tell him so and explain how. If he's not uninformed, then the only thing your comment is doing is trying to shut down legitimate criticism.

All languages have faults. Engage with your critics, own your faults, and either correct them or justify them based on your principles.

EDIT: To give an example, pcwalton also initially criticized Go for not being memory-safe for values of GOMAXPROCS greater than 1. However, the Go team later implemented the dynamic race detector, which, if you've followed pcwalton's comments at all, you know that he is actually quite impressed with.

Re: Go channels, goroutines and GC available in Nim

#42

Post by steveklabnik »

Pharohbot wrote: post #33
MichaelGG wrote: post #29

Earlier quoted context omitted.

I'm guessing because Nim gets portrayed as safe, or offers some safe features, but overall is not memory safe. Rust has worked very hard and gotten through the problem of having memory safety, with zero runtime cost and reasonably good language features. Since it's 2015, it seems fair to point out when a new language offers something neat, but in a way that isn't safe.

Nim is as safe as any other language. Perhaps it's not as safe as Rust but that brings specific trade offs most people dont wan't to deal with. I don't understand why people think that Nim is "terribly unsafe" when in reality it's like any other language

> Nim is as safe as any other language.

With regards to memory safety, it is not. https://news.ycombinator.com/item?id=9050999 is an old comment from Patrick, but in today's Nim, it segfaults in both release and development modes for me. Rust's guaranteed memory safety means that Rust code (without explicit unsafe, the vast vast majority of code) cannot segfault.

> I don't understand why people think that Nim is "terribly unsafe" when in reality it's like any other language

For example, unless I write a bad cext, I cannot get Ruby to segfault.

None of this makes Nim a bad language. All languages have tradeoffs.

Re: Go channels, goroutines and GC available in Nim

#43

Post by MichaelGG »

Pharohbot wrote: post #40
MichaelGG wrote: post #39

Earlier quoted context omitted.

Because it is flatly untrue? Memory safety is rather a binary thing. C# without /unsafe is safe. Same for Java and Rust. Not true for Nim or C/C++. Rust is unique in doing this without any GC or other runtime overhead, AFAIK, which makes it a bit special.

Do you have any specific examples of these unsafetiness in Nim?

Pointers?

Re: Go channels, goroutines and GC available in Nim

#44

Post by fjehcjriendje »

kibwen wrote: post #41
fjehcjriendje wrote: post #16

Earlier quoted context omitted.

So, I've noticed that over the past six months that every time something about Nim gets posted to HN, you make an effort to discredit the language. Care to offer an explanation why?

You yourself know that this claim is entirely unsubstantiated, as evidenced by the fact that you felt the need to create a throwaway account. pcwalton is an active commentator throughout HN in general, and garbage collection and parallelism are two of his areas of expertise. If his opinion is somehow uninformed, then tell him so and explain how. If he's not uninformed, then the only thing your comment is doing is try…

I always post using throwaways since I don't like karma influencing the content of my posts and it also makes it significantly more difficult for third parties to profile me.

Re: Go channels, goroutines and GC available in Nim

#45

Post by Pharohbot »

steveklabnik wrote: post #42
Pharohbot wrote: post #33

Earlier quoted context omitted.

Nim is as safe as any other language. Perhaps it's not as safe as Rust but that brings specific trade offs most people dont wan't to deal with. I don't understand why people think that Nim is "terribly unsafe" when in reality it's like any other language

> Nim is as safe as any other language. With regards to memory safety, it is not. https://news.ycombinator.com/item?id=9050999 is an old comment from Patrick, but in today's Nim, it segfaults in both release and development modes for me. Rust's guaranteed memory safety means that Rust code (without explicit unsafe, the vast vast majority of code) cannot segfault. > I don't understand why people think that Nim is "ter…

Yes Rust is more safe than Nim, I'm not arguing that. I'm also not arguing that Nim is as safe as languages with automatic memory management.

EDIT: Also, Nim is planning on turning those segfaults into runtime NilErrors and a nilChecks flag that will check for them at compile time, you can also avoid this by annotating Pointers with `not nil`

Re: Go channels, goroutines and GC available in Nim

#47

Post by vvanders »

pcwalton wrote: post #23
vvanders wrote: post #18

Earlier quoted context omitted.

If you're crossing threads in games stuff you're doing it wrong. There's a good chance you're running into false-sharing and other pitfalls. Most games use worker-queues(in which case you can use non-GC objects) to deal with architectures like the CELL and for better cache coherency. In that case Nim is a pretty good fir.

> If you're crossing threads in games stuff you're doing it wrong. There's a good chance you're running into false-sharing and other pitfalls. Of course, you shouldn't use shared memory unless you need it. But often you need it. Look at how game developers have demanded shared memory in JavaScript, for example. Modern multicore CPUs do a lot of work to make shared memory work, and work well. > Most games use worker-q…

> Look at how game developers have demanded shared memory in JavaScript

Have a source for that? I find it pretty dubious.

If you're looking to multicore for performance with javascript then you're using the wrong language. Correct memory layout and access patterns will give you a real-world 50-100x win.

Re: Go channels, goroutines and GC available in Nim

#48

Post by jessaustin »

Pharohbot wrote: post #46
MichaelGG wrote: post #43

Earlier quoted context omitted.

Pointers?

Uhh that's not much of an answer...

I haven't done anything in Nim, but in C it's really easy to do bad things with pointers. You can deref a NULL, you can be sloppy about arithmetic, you can overflow a buffer, etc. Nim seems to emphasize using other features instead of pointers, but it still has them.

Re: Go channels, goroutines and GC available in Nim

#49

Post by Pharohbot »

jessaustin wrote: post #48
Pharohbot wrote: post #46

Earlier quoted context omitted.

Uhh that's not much of an answer...

I haven't done anything in Nim, but in C it's really easy to do bad things with pointers. You can deref a NULL, you can be sloppy about arithmetic, you can overflow a buffer, etc. Nim seems to emphasize using other features instead of pointers, but it still has them.

As stated before, there are ways to avoid them and ways that Nim will soon handle them, but do you know how many other languages deref a NULL pointer? Unlike C, this does not result in undefined behavior in means that it will execute something unsafe in Nim

Re: Go channels, goroutines and GC available in Nim

#50

Post by jeremyjh »

I thought the Go runtime runs foreign code on M:M threads; e.g. when Go time calls foreign code, it dedicates a thread to it. This is so foreign libraries (which are unaware of yielding to the Go scheduler when they do I/O) don't block a thread with multiple goroutines scheduled on it. I do not think Nim code can run "in a goroutine".
Post reply on HN