@nickjonson:

> I’ve found (Nim's) supposed to be faster than Julia...

Referring to your opening post, Nim is at least as fast as Julia but not that 
much faster for well written Julia code other than Julia's wait to pre-compile 
it's code when it's called the first time. The problem with writing Julia code 
is one always has to think about and check how it sees the (dynamic) types in 
order to get this speed; also, I think it's state of development of 
multi-threading capabilities is in at least as much a state of flux as Nim's 
(currently).

But they are two different use cases: Nim produces stand alone executable code 
whereas Julia depends on its development environment to run (again at least 
currently).

@jyelon:

> the thread-local heaps made it impossible to pass structured data from one 
> thread to another

Not impossible, but a little more boilerplate code is required to accomplish if 
one doesn't want to allow the system to just deepCopy the data between threads.

> I think sharing data structures between threads in garbage collected 
> languages is more common than you think. Java, definitely. C#, golang. 
> Anything that runs on the JVM, like scala or kotlin. All pure functional 
> languages, like haskell...

You may as well add F#, too.

Yes, all of those named languages now have multi-threaded GC; that is the way 
memory management has been conventionally done for Virtual Machine types of 
languages and Haskell now has a multi-threaded GC implementation, too.

There are lots of modern languages that don't have GC as in Apple's Swift 
(using reference counted pointers with automatic destruction, but with flaws), 
Rust (a kind of safe smart pointer but with reference counting as an option 
when that doesn't work), and of course C++ (depends on libraries used, but 
something like Rust without the type safety) and one can still get things done, 
although you are right that GC makes it fairly easy for lots of types of 
applications.

> I want a garbage collected language.

Don't knock Nim's new run time owned ref's until you've tried them: we believe 
that for typical use they will be almost as easy to use as GC'ed references but 
without GC's downfalls in taking a huge development effort to reduce memory 
access wait time latency while supporting multi-threading, high execution time 
overheads (even worse for multi-threaded versions), and non-deterministic 
destruction (not knowing exactly when heap memory will be free'ed after the 
data goes out of scope or even after the reference to the data is manually set 
to nil).

Have you actually tried multi-threading in those other languages to see how 
easy they are to use for your particular application? Have you actually tried 
to write something using multi-threading in modern Nim for your application? 
You'll never know how well they work or don't until you've actually written 
some Proof Of Concept little micro applications.

Reply via email to