Live data from Hacker News

Nim – Natively compiled language with hot code-reloading at runtime [video]

youtube.com

61–70 of 118 posts

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#61
post #50

I really like Nim. I hope the threading interface improves though, I found it lacking last time I checked about half a year ago.

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

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#62
post #15

I only skimmed the video, but I couldn't see him describing it doing type reloading. Perhaps that is what he is planning on implementing. It is very hard to implement (especially if you can't control the compiler) but very useful for general code reloading. Of course everything is relative, and even if I think it is "very hard" it might be a weekend project for someone else. Generally though, code reloading is one of…

He talks about it at the 27 minute area

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#63
post #47

+1 for Nim. I'm dreaming some day to see a RAD where Lazarus generates Nim code with full LCL support; that would be a truly killer dev system for desktop apps. Lazarus is already a wonderful RAD, one can build native apps on a *PI board and run them directly on that target; Nim support would make it even greater.

Not sure what that would buy over Object Pascal and the plethora of libraries develop since Turbo Pascal/Apple Pascal days.

Admittedly not much on the technical side beyond new languages constructs etc, but the main benefit would be ending for good the wrong argument "Pascal is old therefore Lazarus sucks". Like 20 years ago I've written network code in Delphi that would send and receive binary data between different endianess and word size machines, so I had to align them and manage data down to bitfields in the Pascal equivalent of C unions, that is, the language offers enough bullets and rope to hang then shoot oneself in the foot just like C, but every time I talked with someone about Delphi and later Lazarus, it was just about a matter of minutes before the inevitable "yeah, but Pascal is old".

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#64

Earlier quoted context omitted.

> For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language It would be better for someone to work on an alternate, Python-like input syntax (focusing on readability and good intuition, and perhaps more attractive to novice programmers) for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem t…

> for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem that's already been in development for quite some time Would you still make this point if you were comparing... for example, Rust and C++? ... where Rust is the "young" language? Working on such a young language (and, FWIW, Rust is younger than Nim), you might miss the chance of contribu…

Given that C++ is widely regarded as having unfixable problems (and even the ISO-C++ community is now basically admitting this, with the C++ Core Guidelines being nothing more than a somewhat pointless band-aid), yes I would. If C++ was fixable, Rust would not exist in the first place. (Same goes for e.g. Ada btw - if you could simply fix both the clear lack of openness in the available Ada toolchains, and its lacking anything comparable to the Rust borrow checker, Rust would also not need to exist.)

I can tell why Nim was created - there is a somewhat widely felt need for a systems language (Nim is clearly targeting C/C++ compatibility) with a more Pythonic input syntax! But it's far from clear that Nim itself as it exists today is a sensible answer to these issues.

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#65

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

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.

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#66
post #56
post #41

Earlier quoted context omitted.

Because for an interpreted language you can use it for interactive development. I had thought different reasons would apply to a compiled language but judging by the other replies obviously not!

One can use compilers for interactive development, too. That's not a feature of being 'interpreted'.

Interpreters tend to have repls, which tends to influence how development happens. I'm not stating an absolute law though.

I think you may be misinterpreting my original question. It was asked out of ignorance, it wasn't a challenge. I was hypothesising some kind of self modifying code, or realtime adaptive optimising or something. I was attempting to show you my current level of knowledge so you could ELI7 instead of 5 :)

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#67
I can't tell from the video if the hot code reloading is meant for production workflows or dev only workflows. For example being able to use HCR to update a long-lived TCP server (like a video streaming server) without disconnecting clients.

It seems like it forces pointers for everything which, which seems to me will break a lot of optimizations (like inlining)

Edit: I guess production use is limited anyway since you can't add, modify, or remove types with HCR yet.

Edit2: I just saw in the video they said it's 2x times slower, so definitely can't be used for a lot of workflows in production. Still useful though.

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#68

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…

> For HNers, it's an opportunity to still make a huge difference by contributing to a relatively young language It would be better for someone to work on an alternate, Python-like input syntax (focusing on readability and good intuition, and perhaps more attractive to novice programmers) for some established language, like Rust. Working on a "young" language, you just miss the chance of contributing to an ecosystem t…

There are things about Nim, like the thread local garbage collected heaps, that you can't really replicate in Rust. Sometimes you want garbage collected language because it makes your life easier. Sometimes you don't because you're a library or realtime or you want to optimize the hell out of your code.

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#69

I can't tell from the video if the hot code reloading is meant for production workflows or dev only workflows. For example being able to use HCR to update a long-lived TCP server (like a video streaming server) without disconnecting clients. It seems like it forces pointers for everything which, which seems to me will break a lot of optimizations (like inlining) Edit : I guess production use is limited anyway since y…

that is indeed the case - HCR is meant mainly for development. But if you can stomach the x2-x3-x4 slowdown for production nothing would stop you

Re: Nim – Natively compiled language with hot code-reloading at runtime [video]

#70
post #55

Earlier quoted context omitted.

> Looks like it's still a pre-release feature at this point. It has been merged to devel branch: https://github.com/nim-lang/Nim/pull/10729

What's the situation with the TODOs mentioned in the presentation? Primarily, the missing standard library support cleanup ("Currently no real-world project can be built with HCR")?

those issues will hopefully be addressed in the coming months - when I get the time
Post reply on HN