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

31–40 of 87 posts

Re: Go channels, goroutines and GC available in Nim

#31

Post by rudolf0 »

rspeer wrote: post #25
vbit wrote: post #5

Earlier quoted context omitted.

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…

You make a valid point, but many years of work have gone into the monkeypatching at this point. If you use the latest version, it's very rare to find a place where it fails. It's usually only an issue if you're dealing with a third party module that makes use of native shared libraries.

I use gevent both for small and large projects, and haven't had any complaints. The monkeypatching pains my soul just a little bit, but I've found no better async framework for Python yet.

Re: Go channels, goroutines and GC available in Nim

#32

Post by copx »

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

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

And how do you do "memory management well"? Like Rust? You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management.

Ref counting is not superior or inferior to explicit, restrictive ownership semantics. Those are simply different trade-offs.

Nim might be strictly inferior for writing a heavily multi-threaded web browser because of its memory management approach but that does not mean the approach is generally inferior.

Seems to me that Nim aims to be a "casual", rapid development / friendly (Python-like) language. Ownership semantics like in Rust do not fit there.

Re: Go channels, goroutines and GC available in Nim

#33

Post by Pharohbot »

MichaelGG wrote: post #29
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?

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

Re: Go channels, goroutines and GC available in Nim

#34

Post by stcredzero »

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

Not if you need to be thread-safe.

Everything that has to be thread-safe uses channels. I use channels to sanitize everything for a purely synchronous game loop. As an optimization, in cases where there are atomic operations available, there are places where concurrent code can mutate values visible to the game loop, but this is strictly an optimization technique, to be used judiciously. (So only values like "speed" can use this technique. Anything that's a reference is verboten.)

How would that work with multithreading? (Assuming you had a thread-safe GC, which Nim's isn't.)

I didn't realize Nim's GC wasn't thread safe. In my current architecture, you'd only have to worry about the part using channels to sanitize things for the synchronous game loop. If everything outside of the game loop was written such that most everything was allocated on the stack, the GC would never have to collect anything outside of the game loop. So maybe it could work as a port. I couldn't say for sure, though.

Re: Go channels, goroutines and GC available in Nim

#35

Post by pcwalton »

copx wrote: post #32
pcwalton wrote: post #17

Earlier quoted context omitted.

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

And how do you do "memory management well"? Like Rust? You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management. Ref counting is not superior or inferior to explicit, restrictive ownership semantics. Those are simply different trade-offs. Nim might be strictly inferior for writing a heavily multi-threaded web browser because of its memory management approach but that does…

I'm personally a fan of regular old Java/C#-like concurrent garbage collection for most "scripting" languages (perhaps surprisingly, given my work on Rust). It's a lot of work to get there, but I think there's no substitute for doing the work—apps really end up needing the flexibility of shared memory. Shortcuts that seem simple like DRC end up tending to run into walls in practice, which is something that the other languages discovered—history keeps pointing to the HotSpot-style garbage collector as the one that systems that need to offer a simple, general-purpose garbage-collected programming model migrate to.

For different use cases Rust-style ownership semantics (when the performance of GC and runtime interoperability become an issue), or Azul-style pauseless GC (when you're willing to trade throughput for latency), or shared-nothing architectures (when you need them for legacy reasons like JavaScript, or want a simple programming model like Erlang) can work great.

Re: Go channels, goroutines and GC available in Nim

#36

Post by heinrich5991 »

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

It has a feel of a scripting language, but as far as I can tell, it rather has the safety of C/C++, which I personally wouldn't call "safe like any other language".

Re: Go channels, goroutines and GC available in Nim

#37

Post by tatterdemalion »

pcwalton wrote: post #35
copx wrote: post #32

Earlier quoted context omitted.

And how do you do "memory management well"? Like Rust? You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management. Ref counting is not superior or inferior to explicit, restrictive ownership semantics. Those are simply different trade-offs. Nim might be strictly inferior for writing a heavily multi-threaded web browser because of its memory management approach but that does…

I'm personally a fan of regular old Java/C#-like concurrent garbage collection for most "scripting" languages (perhaps surprisingly, given my work on Rust). It's a lot of work to get there, but I think there's no substitute for doing the work—apps really end up needing the flexibility of shared memory. Shortcuts that seem simple like DRC end up tending to run into walls in practice, which is something that the other…

"apps really end up needing the flexibility of shared memory"

Why? Just performance or is there a design reason also?

Re: Go channels, goroutines and GC available in Nim

#38

Post by Pharohbot »

heinrich5991 wrote: post #36
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

It has a feel of a scripting language, but as far as I can tell, it rather has the safety of C/C++, which I personally wouldn't call "safe like any other language".

Why not? I'm interested to know because in my opinion I don't see it any less safe than languages that don't have automatic memory management and/or languages like Rust.

Re: Go channels, goroutines and GC available in Nim

#39

Post by MichaelGG »

Pharohbot wrote: post #38
heinrich5991 wrote: post #36

Earlier quoted context omitted.

It has a feel of a scripting language, but as far as I can tell, it rather has the safety of C/C++, which I personally wouldn't call "safe like any other language".

Why not? I'm interested to know because in my opinion I don't see it any less safe than languages that don't have automatic memory management and/or languages like Rust.

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.

Re: Go channels, goroutines and GC available in Nim

#40

Post by Pharohbot »

MichaelGG wrote: post #39
Pharohbot wrote: post #38

Earlier quoted context omitted.

Why not? I'm interested to know because in my opinion I don't see it any less safe than languages that don't have automatic memory management and/or languages like Rust.

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?
Post reply on HN