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

11–20 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#11

Post by pcwalton »

stcredzero wrote: post #8

This document describes how the GC works and how to tune it for (soft) realtime systems. The basic algorithm is Deferred Reference Counting with cycle detection. I'm sitting here feeling very impressed. Deferred reference counting has very good semantics for games. Even better, you can control the cycle detection part separately and run that part at an advantageous time. (Though it's probably better to just let GC do…

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

Re: Go channels, goroutines and GC available in Nim

#12

Post by aikah »

kodablah wrote: post #2

I always wanted to see a Go/Nim interop project in a little different vein. Since Nim is a superset of Go (and Go is fairly simple), why not a Go implementation in Nim via cross-compilation? Then you can even build a Nim macro that does a "Go get" and Nim developers can use Golang libraries right in their code as imports. Not to mention we get a full, alternative Go impl. It should be easy to bootstrap by first using…

> Since Nim is a superset of Go

what ?

Re: Go channels, goroutines and GC available in Nim

#13

Post by Pharohbot »

pcwalton wrote: post #11
stcredzero wrote: post #8

This document describes how the GC works and how to tune it for (soft) realtime systems. The basic algorithm is Deferred Reference Counting with cycle detection. I'm sitting here feeling very impressed. Deferred reference counting has very good semantics for games. Even better, you can control the cycle detection part separately and run that part at an advantageous time. (Though it's probably better to just let GC do…

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

A more general approach to shared memory via lockable heaps is a feature Nim seems will implement soon.

Re: Go channels, goroutines and GC available in Nim

#14

Post by kodablah »

aikah wrote: post #12
kodablah wrote: post #2

I always wanted to see a Go/Nim interop project in a little different vein. Since Nim is a superset of Go (and Go is fairly simple), why not a Go implementation in Nim via cross-compilation? Then you can even build a Nim macro that does a "Go get" and Nim developers can use Golang libraries right in their code as imports. Not to mention we get a full, alternative Go impl. It should be easy to bootstrap by first using…

> Since Nim is a superset of Go what ?

I was under the impression this was true feature-set wise. I may be wrong though and am happy to be corrected.

Re: Go channels, goroutines and GC available in Nim

#15

Post by pcwalton »

Pharohbot wrote: post #13
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.)

A more general approach to shared memory via lockable heaps is a feature Nim seems will implement soon.

Sounds interesting. Do you have any links to documentation?

I'm interested in reading more about it, because Nim is doing a lot of experimental stuff and it's always interesting to look at its designs.

(Edited to remove speculation about how well it will perform before reading about it.)

Re: Go channels, goroutines and GC available in Nim

#16

Post by fjehcjriendje »

pcwalton wrote: post #11
stcredzero wrote: post #8

This document describes how the GC works and how to tune it for (soft) realtime systems. The basic algorithm is Deferred Reference Counting with cycle detection. I'm sitting here feeling very impressed. Deferred reference counting has very good semantics for games. Even better, you can control the cycle detection part separately and run that part at an advantageous time. (Though it's probably better to just let GC do…

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

Re: Go channels, goroutines and GC available in Nim

#17

Post by pcwalton »

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 think Nim is an impressive language that does a lot of things really well. I don't think the memory management is one of them. I believe that memory management and compilation to C are the only two major things I've ever talked about in regards to Nim, because I'm abstractly interested in those topics. If an article about thread-local deferred reference counting in Ruby hit the top of HN and the comments were talking about how that's good for games, I'd probably comment there too.

Re: Go channels, goroutines and GC available in Nim

#18

Post by vvanders »

pcwalton wrote: post #11
stcredzero wrote: post #8

This document describes how the GC works and how to tune it for (soft) realtime systems. The basic algorithm is Deferred Reference Counting with cycle detection. I'm sitting here feeling very impressed. Deferred reference counting has very good semantics for games. Even better, you can control the cycle detection part separately and run that part at an advantageous time. (Though it's probably better to just let GC do…

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

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.

Re: Go channels, goroutines and GC available in Nim

#19

Post by stefantalpalaru »

stcredzero wrote: post #9
stefantalpalaru wrote: post #7

Earlier quoted context omitted.

> why not a Go implementation in Nim via cross-compilation? Nim's macros have one limitation that prevents an accurate implementation of another syntax: they can't fully modify the existing syntax. See how I had to use "scase" inside "select" blocks because the existing "case" keyword insists on having "of" after it. So Nim's semantics put some limits on the amount of hijacking one can inflict on it through macros.

If you front compilation with Go's parser, you could generate bog-standard Nim code from the AST.

You can, but you'd be limiting yourself to pure Go. I'd rather have Go with Nim's generics, transpilation to C, macros, compile time computation, etc.

Re: Go channels, goroutines and GC available in Nim

#20

Post by duaneb »

kodablah wrote: post #2

I always wanted to see a Go/Nim interop project in a little different vein. Since Nim is a superset of Go (and Go is fairly simple), why not a Go implementation in Nim via cross-compilation? Then you can even build a Nim macro that does a "Go get" and Nim developers can use Golang libraries right in their code as imports. Not to mention we get a full, alternative Go impl. It should be easy to bootstrap by first using…

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

Post reply on HN