Live data from Hacker News

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

youtube.com

21–30 of 118 posts

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

#21
post #18

Can someone give me some pointers to reading material on this. I'm aware of hot code reloading for interpreted languages, google just gives links to web page loading. I'm also aware of it at the OS level. I don't really understand why you'd want this in a compiled language.

> Can someone give me some pointers to reading material on this.

Wish I could help you with this, but I have been out of the loop with Nim recently.

> I don't really understand why you'd want this in a compiled language.

Quick iteration in development. Not needing to manually recompile every time you make a small change.

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

#22
post #18

Can someone give me some pointers to reading material on this. I'm aware of hot code reloading for interpreted languages, google just gives links to web page loading. I'm also aware of it at the OS level. I don't really understand why you'd want this in a compiled language.

> I don't really understand why you'd want this in a compiled language.

Why not?

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

#23
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…

> The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed. Very few languages except for Erlang are able to do that correctly. Some languages claim to support that, but when you experiment with them you discover "quirks" making it impossible in practice.

You can kind of do it with node.js, but man do things get ugly fast when you manage state/connections in modules on reload.

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

#24
post #16

You can hotpatch C function too : https://news.ycombinator.com/item?id=11403263

Loading and unloading dynamic libraries (dlopen in Unix, LoadLibrary in Windows ...) and operating system kernel modules are also examples of hot code reloading in C.

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

#25
post #18

Can someone give me some pointers to reading material on this. I'm aware of hot code reloading for interpreted languages, google just gives links to web page loading. I'm also aware of it at the OS level. I don't really understand why you'd want this in a compiled language.

> why you'd want this in a compiled language.

Shared-library-based plugins, kernel modules, ...

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

#26
post #18

Can someone give me some pointers to reading material on this. I'm aware of hot code reloading for interpreted languages, google just gives links to web page loading. I'm also aware of it at the OS level. I don't really understand why you'd want this in a compiled language.

If you understand why people have it in interpreted languages, why do those reasons not apply to compiled languages?

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

#27

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…

> Until then, if you are looking for a systems programming language, you owe it to yourself to investigate Nim[3], alongside Go, Crystal, Julia, D, Rust, Haskell, etc.

Go, Crystal, Julia, Haskell and Nim all have a runtime that sort of precludes their use as a true systems lang. I agree with your other points, and I like Nim, I wish it was more popular, but I can't convince myself it's worth the time investment to learn it. I know Rust and Haskell already, between those two there isn't much space where Nim would be a good fit that the others aren't.

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

#28
post #19

I remember using "edit and continue" in Visual C++ 6, seems that this feature still exists in newer versions[1], but I don't know what limitations it has. [1] https://docs.microsoft.com/en-us/visualstudio/debugger/edit-...

That's a great doc page. In the "Supported Code Changes" for C++ and C# it has a helpful list of what isn't supported too. Java also has the feature in the JVM (IDEs / mvn-hotswap plugin can hook into it), but it's similarly limited. There's a proprietary java agent called JRebel that significantly expands the support (https://jrebel.com/software/jrebel/features/comparison-matri...), and a couple open source versions I haven't tried, but it's still got some limitations.

It's worth a comparison to Common Lisp which thought about this feature a lot more and built it into the language rather than having it hacked in by external tools... e.g. if you redefine a class definition in Java say to add a new storage field, well you can't using default hotswap but with JRebel you can, but still any existing objects will continue to point to the "old class"'s code and the new field won't be available... Common Lisp defines a generic function 'update-instance-for-redefined-class that you extend before you do the class edit, and now your existing objects will work with the new code.

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

#29
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…

If you put your mind to it just a bit (i.e., I wouldn't call this "automatic" exactly but it's not too hard to use the support the language, runtime, and libraries have), Erlang can even do a harder thing, which is update the code handling a given socket connection or something live, in a principled manner, while never dropping the connection.

Since HTTP is transient, it's actually a bit easier than a raw socket since you can expect it to go away soon, or even in the case of HTTP2, you can often expect to just close a socket as long as it's not currently active and get away with it. Many languages can smoothly upgrade an HTTP server by handing off a listening socket to a new process with new code. But even that won't save you for live sockets, because even if you hand off the socket, you haven't got a clean mechanism for handing off its accompanying state.

Several interpreted languages can sort of do this, but I'd call it in an "unprincipled" manner by just slamming new code in place and hoping for the best. Erlang explicitly upgrades the gen_* instances and you can provide a function for converting the old state to the new state cleanly.

Post reply on HN