81–90 of 118 posts
I see that at this point in time Smalltalk and Lisp machines have become completely memory-holed (oh wait, Smalltalk & Lisp are interactive, thus "interpreted", thus obviously not compiled! I'll show myself out)
Don't know about Smalltalk but there are numerous CL compilers...
Earlier quoted context omitted.
I'm curious, what more are you looking for? From the nim manual: "Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables. This helps to prevent race conditions. GC efficiency is improved quite a lot, because the GC never has to stop other threads and see what they reference. Memory allocation requires no lock at all! This design easily scales to massive multicore proc…
How does Nim do thread-based GC if an object is shared across threads? Does it not allow that sharing references cross-thread (not sure how it would without lifetimes though)?
Earlier quoted context omitted.
How does Nim do thread-based GC if an object is shared across threads? Does it not allow that sharing references cross-thread (not sure how it would without lifetimes though)?
If I understand the Nim manual correctly, there is no sharing of objects across threads. Instead, Nim assumes message passing. When you communicate between threads, Nim makes a deep copy of the message. In theory, that strategy could be very inefficient if the messages are large, but it also means the garbage collector is unaware of threads and therefore simpler.
You can message-pass a pointer if you are sure the referenced object won't be GCed.
I see that at this point in time Smalltalk and Lisp machines have become completely memory-holed (oh wait, Smalltalk & Lisp are interactive, thus "interpreted", thus obviously not compiled! I'll show myself out)
Don't know about Smalltalk but there are numerous CL compilers...
Nim is an amazing language. The syntax is cleaner (IMO) and easier-to-read than Go and approaches Python in its readability, which is impressive for a statically typed, compiled language[0]. The design is focused on performance above all else, but it still has metaprogramming[1] and functional features. However, Go and other languages have a huge ecosystem and many more libraries. Nim only has a few web servers/frame…
Nim is an amazing language. The syntax is cleaner (IMO) and easier-to-read than Go and approaches Python in its readability, which is impressive for a statically typed, compiled language[0]. The design is focused on performance above all else, but it still has metaprogramming[1] and functional features. However, Go and other languages have a huge ecosystem and many more libraries. Nim only has a few web servers/frame…
Minor nit. Every language you mentioned with a GC is not a systems language.
The term is nebulous though.
Earlier quoted context omitted.
Minor nit. Every language you mentioned with a GC is not a systems language.
Go is a systems language. The term isn't confined to device drivers. It includes platform/backend software such as web servers and things like message queues or the Docker ecosystem. The term is nebulous though.
By your argument Ruby and Python are also systems languages because they can be used to write servers and job queues.
You're not doing real time programming with Go. Don't make systems programming lose its meaning by promulgating this myth.
Nim is an amazing language. The syntax is cleaner (IMO) and easier-to-read than Go and approaches Python in its readability, which is impressive for a statically typed, compiled language[0]. The design is focused on performance above all else, but it still has metaprogramming[1] and functional features. However, Go and other languages have a huge ecosystem and many more libraries. Nim only has a few web servers/frame…
Minor nit. Every language you mentioned with a GC is not a systems language.
Earlier quoted context omitted.
Go is a systems language. The term isn't confined to device drivers. It includes platform/backend software such as web servers and things like message queues or the Docker ecosystem. The term is nebulous though.
That's wrong! Those fall squarely in the application domain. By your argument Ruby and Python are also systems languages because they can be used to write servers and job queues. You're not doing real time programming with Go. Don't make systems programming lose its meaning by promulgating this myth.
I think you're conflating writing device drivers/kernels with systems programming, which includes those things but is not limited by them.
Regardless, the term's meaning can't be lost if its apparently this hazy.