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

51–60 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#51

Post by stefantalpalaru »

jeremyjh wrote: post #50

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

> I do not think Nim code can run "in a goroutine".

It does. Don't forget that this is gccgo so it is possible to use plain C functions as goroutines. Nim is translated to C and with the help of a macro I convert Nim functions with an arbitrary number of arguments into ones with a single void* arg that gccgo wants for its 'go' keyword implementation:

    extern void* __go_go(void (*f)(void *), void *);

Re: Go channels, goroutines and GC available in Nim

#52

Post by digitalzombie »

bmurphy1976 wrote: post #3

I'm very curious to hear the pros and cons of this from somebody who has intimate knowledge of Nim internals. I really really like Go's CSP model and would love to see it properly supported in another lightweight non-jvm language (yes I know about Erlang, it doesn't fit the bill for me).

Ada have a CSP model too, just fyi.

It's a mature language. You can look into that?

Re: Go channels, goroutines and GC available in Nim

#53

Post by jessaustin »

Pharohbot wrote: post #49
jessaustin wrote: post #48

Earlier quoted context omitted.

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

Sorry for my ignorance, but the languages other than C that I've used are javascript, python, various lisps, bash, sql, prolog, etc.: no pointers! I'm interested to learn how pointers might be made safe, in Nim or anywhere else?

Re: Go channels, goroutines and GC available in Nim

#54

Post by kibwen »

fjehcjriendje wrote: post #44
kibwen wrote: post #41

Earlier quoted context omitted.

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.

This is some glass-houses logic right here, given that you're attempting to leverage trivially-falsifiable assertions in order to profile pcwalton as a Nim hater with a personal vendetta. In the meantime you have yet to actually address his criticisms, which, to reiterate, indicates that you're trying to shut down critics via deflection.

(I suppose, in the future, pcwalton should just generate a throwaway before commenting on Nim.)

Re: Go channels, goroutines and GC available in Nim

#55

Post by steveklabnik »

Pharohbot wrote: post #45
steveklabnik wrote: post #42

Earlier quoted context omitted.

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

Cool. When you said 'any other language,' I thought you were speaking more broadly than C or C++.

Re: Go channels, goroutines and GC available in Nim

#56

Post by Pharohbot »

jessaustin wrote: post #53
Pharohbot wrote: post #49

Earlier quoted context omitted.

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

Sorry for my ignorance, but the languages other than C that I've used are javascript, python, various lisps, bash, sql, prolog, etc.: no pointers! I'm interested to learn how pointers might be made safe, in Nim or anywhere else?

It really depends on how you define "safe". Nim will allow you to deref null pointers (unless you annotate it with `not nil`, then it can never be nil, this results in compile errors if it is) but if they are, it will be like Java and throw an exception if --nilChecks:On. The only language I know that makes pointers safe is Rust, with it's borrow checker and such, but that's a tradeoff I don't really want and the options Nim provides are better for my case.

Re: Go channels, goroutines and GC available in Nim

#57

Post by Pharohbot »

steveklabnik wrote: post #55
Pharohbot wrote: post #45

Earlier quoted context omitted.

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`

Cool. When you said 'any other language,' I thought you were speaking more broadly than C or C++.

I probably should have been more clear, but I think it's safe to say that unlike C/C++, Nim can handle these types of issues like other languages that deal with pointers (Java, Go etc) with control from the programmer. The only memory safe language I know is Rust, but I am probably wrong on that part, so that's why I singled out Rust on how It's safer than Nim.

Re: Go channels, goroutines and GC available in Nim

#58

Post by jeremyjh »

stefantalpalaru wrote: post #51
jeremyjh wrote: post #50

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

> I do not think Nim code can run "in a goroutine". It does. Don't forget that this is gccgo so it is possible to use plain C functions as goroutines. Nim is translated to C and with the help of a macro I convert Nim functions with an arbitrary number of arguments into ones with a single void* arg that gccgo wants for its 'go' keyword implementation: extern void* __go_go(void (*f)(void *), void *);

Yes, but when the Go runtime calls that foreign function pointer, it is going to schedule an entire OS thread for its duration isn't it? If it doesn't, then nothing prevents foreign code from blocking other goroutines. How does the Nim code yield the thread for other goroutines, does it have to register a callback?

Re: Go channels, goroutines and GC available in Nim

#59

Post by stefantalpalaru »

jeremyjh wrote: post #58
stefantalpalaru wrote: post #51

Earlier quoted context omitted.

> I do not think Nim code can run "in a goroutine". It does. Don't forget that this is gccgo so it is possible to use plain C functions as goroutines. Nim is translated to C and with the help of a macro I convert Nim functions with an arbitrary number of arguments into ones with a single void* arg that gccgo wants for its 'go' keyword implementation: extern void* __go_go(void (*f)(void *), void *);

Yes, but when the Go runtime calls that foreign function pointer, it is going to schedule an entire OS thread for its duration isn't it? If it doesn't, then nothing prevents foreign code from blocking other goroutines. How does the Nim code yield the thread for other goroutines, does it have to register a callback?

> when the Go runtime calls that foreign function pointer, it is going to schedule an entire OS thread for its duration isn't it?

No.

> How does the Nim code yield the thread for other goroutines, does it have to register a callback?

There are no callbacks. Yielding happens automatically when launching another goroutine, when sending, receiving or selecting on a channel. You can also yield explicitly with go_yield() - the better named equivalent of Go's runtime.Gosched().

It's easier to understand if you realize that all those operations with goroutines and channels end up being done in the Go runtime.

Re: Go channels, goroutines and GC available in Nim

#60

Post by pcwalton »

Pharohbot wrote: post #49
jessaustin wrote: post #48

Earlier quoted context omitted.

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

It is undefined behavior in Nim due to compiling to C. https://news.ycombinator.com/item?id=9050999
Post reply on HN