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

21–30 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#21

Post by kodablah »

duaneb wrote: post #20
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.

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

Re: Go channels, goroutines and GC available in Nim

#22

Post by stefantalpalaru »

kodablah wrote: post #14
aikah wrote: post #12

Earlier quoted context omitted.

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

Almost. Go had the advantage of M:N threading with its goroutines and elegant CSP implementation.

Re: Go channels, goroutines and GC available in Nim

#23

Post by pcwalton »

vvanders wrote: post #18
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.)

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-queues(in which case you can use non-GC objects) to deal with architectures like the CELL and for better cache coherency.

I agree with you that GC is often not the best solution for shared memory concurrency. But I think you really need to design the language around "no GC" in order to make that really ergonomic relative to C++. The entire C++ language and library ecosystem is based around making manual memory management (relatively) easy to use; going back to malloc and free is a hard sell.

Re: Go channels, goroutines and GC available in Nim

#24

Post by worklogin »

kodablah wrote: post #14
aikah wrote: post #12

Earlier quoted context omitted.

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

Calling something a superset usually means it's actually an expansion of something... kind of like C++11 might be a superset of C++03 (not sure if that's accurate).

Re: Go channels, goroutines and GC available in Nim

#25

Post by rspeer »

vbit wrote: post #5
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).

Well you can already use Nim threads ( http://nim-lang.org/docs/threads.html ) and channels ( http://nim-lang.org/docs/channels.html ) - the model is similar although the implementation uses system threads rather than coroutines. Nim also has lightweight coroutines using `async` and `await` ( http://nim-lang.org/docs/asyncdispatch.html ) - you can run a bunch of these within one thread. Also, have a look at gevent fo…

Don't look at gevent for Python, look at a responsible async library: asyncio if you like Py3, Twisted if you like Py2 and want something that's very featureful but old-school, Trollius if you wish you could be using asyncio but you're stuck on Py2.

gevent is too much magic. It aims to give you async without changing any of your code. To accomplish this, it monkey-patches the entire Python standard library, in a way that is 99% compatible with Python, but the 1% will constantly surprise and infuriate you. Its compatibility shows no signs of increasing given how much its development has slowed down.

You can use gevent as a quick hack, but you will hate yourself if you have to maintain gevent code.

Re: Go channels, goroutines and GC available in Nim

#26

Post by rbehrends »

pcwalton wrote: post #15
Pharohbot wrote: post #13

Earlier quoted context omitted.

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

Well, this is currently highly speculative. What I proposed to Andreas was essentially a model based on Eiffel's SCOOP (with some additional influence from Erlang). Whether it's a practical design remains to be seen.

Note that shared, lockable heaps need not be heavyweight structures. It is entirely possible to imagine a shared hash table with one heap per bucket and fine-grained locking, for example. Collections for such small heaps can be fast because the number of roots is limited, and (depending on what invariants you guarantee), you can even forgo stack scanning for most collections or limit the number of stack frames that need to be traversed.

Re: Go channels, goroutines and GC available in Nim

#27

Post by pcwalton »

rbehrends wrote: post #26
pcwalton wrote: post #15

Earlier quoted context omitted.

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

Well, this is currently highly speculative. What I proposed to Andreas was essentially a model based on Eiffel's SCOOP (with some additional influence from Erlang). Whether it's a practical design remains to be seen. Note that shared, lockable heaps need not be heavyweight structures. It is entirely possible to imagine a shared hash table with one heap per bucket and fine-grained locking, for example. Collections for…

Neat, I'll read more on SCOOP. Thanks!

Re: Go channels, goroutines and GC available in Nim

#28

Post by rbehrends »

pcwalton wrote: post #27
rbehrends wrote: post #26

Earlier quoted context omitted.

Well, this is currently highly speculative. What I proposed to Andreas was essentially a model based on Eiffel's SCOOP (with some additional influence from Erlang). Whether it's a practical design remains to be seen. Note that shared, lockable heaps need not be heavyweight structures. It is entirely possible to imagine a shared hash table with one heap per bucket and fine-grained locking, for example. Collections for…

Neat, I'll read more on SCOOP. Thanks!

SCOOP is not a horribly complicated idea (well, other than the using preconditions as wait conditions, which has been critiqued in the past and is not a critical ingredient). It's basically an extension of the basic idea of monitors. It is based on the idea of having a unified approach for shared memory and distributed system and accomplishes that by assuming that objects can be partitioned into disjoint ("separate") data spaces, access to which is regulated to ensure mutual exclusion; this is why it translates nicely to a model involving thread-local heaps.

At the programming language level, this then mostly involves maintaining mutual exclusion (in Eiffel, the necessary semantics are attached to how "separate" types are handled) and having the optimizer get rid of unnecessary copies.

Re: Go channels, goroutines and GC available in Nim

#29

Post by MichaelGG »

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

Re: Go channels, goroutines and GC available in Nim

#30

Post by MichaelGG »

kodablah wrote: post #14
aikah wrote: post #12

Earlier quoted context omitted.

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

That's a really strange metric to use. It'll rarely be true, except in a sort of Turing completeness way.
Post reply on HN