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

71–80 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#71

Post by stefantalpalaru »

jeremyjh wrote: post #64
stefantalpalaru wrote: post #59

Earlier quoted context omitted.

> 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()…

> > 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. Are you sure? Once a thread enters cgo it is considered blocked and is removed from the thread pool according to these sources [1][2]. I previously found a thread where Ian Lance Taylor explained it more explicitly but I couldn't find that now. Is that not what is happening though w…

> Are you sure?

Yes. See the chinese whispers benchmark with 500000 goroutines and a maximum resident set size of 5.4 GB on amd64. It has the same memory usage (and run time) as the Go version compiled with gccgo.

> Once a thread enters cgo

This has nothing to do with cgo. It's a different mechanism specific to gccgo.

> I do not understand how the Nim code can live in the segmented stack of a goroutine

Good thing you asked. I just ported to Nim the peano.go benchmark described as a "torture test for segmented stacks" and... it failed. The fix was to pass -fsplit-stack to gcc when it compiles the C code generated by nim.

> nor how the Go runtime could know it is time to grow that stack

From what I can tell it's done in __splitstack_makecontext() and friends from GCC's libgo.

Re: Go channels, goroutines and GC available in Nim

#72

Post by pjmlp »

Pharohbot wrote: post #56
jessaustin wrote: post #53

Earlier quoted context omitted.

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 opt…

Ada, SPARK, ParaSail

Re: Go channels, goroutines and GC available in Nim

#73

Post by Pharohbot »

pcwalton wrote: post #60
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

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

As stated before in this thread, there _will_ be nil Checks in the future which will result in NilErrors or you can just annotate it with `not nil` right now and it will never be nil. You can also use -fsanitize flags with the clang backend to trap the null dereferences.

Re: Go channels, goroutines and GC available in Nim

#74

Post by [deleted] »

pcwalton wrote: post #60
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

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

[deleted]

Re: Go channels, goroutines and GC available in Nim

#75

Post by [deleted] »

pcwalton wrote: post #60
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

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

[deleted]

Re: Go channels, goroutines and GC available in Nim

#76

Post by [deleted] »

pcwalton wrote: post #60
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

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

[deleted]

Re: Go channels, goroutines and GC available in Nim

#77

Post by Pharohbot »

MichaelGG wrote: post #62
Pharohbot wrote: post #57

Earlier quoted context omitted.

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.

That's not at all the impression I get from reading the Nim manual. It sounds rather clear when it says unsafe over many different features. Can you declare a function pointer and point it at anything? It allows unchecked array access - what's stopping traditional overflows? I've not used Nim, but compiling to C and exposing a lot of C-like functionality seems to indicate that code will still be subject to the same t…

I never said that Nim is safe/ doesnt have safe areas in the language. But at this stage of development with Nim, it really focuses on the Language goals rather than anything else right now. I have only stated multiple times through this thread that there are way to avoid this unsafetiness and ways that will help avoid these situations in the Future with Nim (nilChecks)

Re: Go channels, goroutines and GC available in Nim

#78

Post by jeremyjh »

stefantalpalaru wrote: post #71
jeremyjh wrote: post #64

Earlier quoted context omitted.

> > 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. Are you sure? Once a thread enters cgo it is considered blocked and is removed from the thread pool according to these sources [1][2]. I previously found a thread where Ian Lance Taylor explained it more explicitly but I couldn't find that now. Is that not what is happening though w…

> Are you sure? Yes. See the chinese whispers benchmark with 500000 goroutines and a maximum resident set size of 5.4 GB on amd64. It has the same memory usage (and run time) as the Go version compiled with gccgo. > Once a thread enters cgo This has nothing to do with cgo. It's a different mechanism specific to gccgo. > I do not understand how the Nim code can live in the segmented stack of a goroutine Good thing you…

Well, cool! Great work :)

Re: Go channels, goroutines and GC available in Nim

#79

Post by duaneb »

kodablah wrote: post #21
duaneb wrote: post #20

Earlier quoted context omitted.

> Since Nim is a superset of Go I seriously doubt that Nim is out of the box binary compatible with another runtime's fundamental types.

I am not looking for binary compatibility. I am looking for feature parity. Go interfaces can be handled with concepts [1] or just macros. I am talking about an alternative Go implementation (i.e. just sitting on top of Nim), not ABI compat between the two runtimes. 1 - http://nim-lang.org/docs/manual.html#generics-concepts

Along that way is C++ and "we should attempt to be a superset of all programming paradigms". Fewer features is better, and more restrictions allow better tooling and iteration if they don't functionally restrict the programmer.

Basically, I'm not sure of the benefit of building go on top of nim. They appear to fill the same space in orthogonal ways.

Re: Go channels, goroutines and GC available in Nim

#80

Post by jibalt »

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?

I've noticed that a) that's an ad hominem attack and b) it isn't accurate.
Post reply on HN