Hacker News Reader

Comment by Jeaye | Hacker News Reader

Folks interested in this should absolutely look at the open source Cling project, which uses Clang/LLVM to JIT compile C++ in-process. https://github.com/root-project/cling

I'm using Cling, as part of jank, a native Clojure dialect on LLVM, with C++ interop. This allows me to have truly interactive, dynamic programming, while still reaching into native code. jank source compiles to C++, which is then JIT compiled by Cling. In recent benchmarks, it can be several times faster than Clojure JVM. https://jank-lang.org/

View on HN

My personal experience with ROOT REPL is that it's quite stateful, some error may make you want to restart the session I avoid it for anything longer than a few minutes of use

This. I haven't used it for a while, but my experience is that this whole idea is not worth the trouble. If you want to rapidly design and test algorithms in a JIT environment, just use Python. It's designed for that. You can always port it to c++ in the end if performance is an issue.

I understand that frustration. Fortunately, Clojure (and jank) gets around this entirely. Functions can be redefined at any time, even with different signatures, globals as well. References to the will stay intact and will use the latest value; this is also thread-safe.

Ultimately, this isn't something Cling needs to worry about. You can have your cake and eat it, too. If that sounds too good to be true, know that it's how Clojure devs write all programs. We spin up the process and then send code to it from our editors, without needing to tear it down.

jank gives you this, in C++ land, including support for inline C++ within your Clojure code. I'll have a lot more demos coming out this year, but you can also check out the jank blog or my talks at ROOT's compiler research group and Clojure Conj 2023.

I think this would have been great 15 years ago. Today I really can't see the need for something like it anymore.

Game industry is one example of such need, hence why Unreal has this kind of tooling integration, or why Visual C++ keeps improving it.

And it's unbelievably bad in Unreal as well. They do so much shady hooks and memory management / GC under the hood that Unreal C++ is effectively more like Java or C# at this point. They would save devs a ton of headache if they just went all the way like Unity. C++ has its uses - but those are definitely not it.

C++ was already Java and C# before they came to be, as experienced in tooling like Energize C++, Visual Age for C++, and C++ Builder.

The problem is that too many people insist in using it like C.

Is as if one changes the JavaScript file extension to Typescript, and then keeps writing JavaScript ES3 on it.

That's true and it's why C++ development has become a nightmare over the past decades. I don't see why people need to cram every idea into a single language, especially one that was designed to be so close to hardware. If I want the comfort of high level stuff, I use a high level language.

you might be getting downvoted for conflating REPL with JIT, but there's definitely a place for a C++ REPL (and anyway, with ROOT/cppyy you can basically use inline C++ in python REPLs)

REPL is just an interface on top. It complicates the whole thing even further, but it's not the root (no pun intended) of the problem.

>you can basically use inline C++ in python REPLs

That's exactly what I was getting at. There's no need for a pure C++ interactive environment. Just use python at this point.

No, in my experience with Python and its REPLey incarnations, I would have felt much more at peace if there was a good and reliable C++/Rust REPL.

And if that's in a familiar language, then even better. Clojure is a good choice, but I am still learning it.

Note: I am a lone programmer building Quant Engineering subsystems for personal purposes. So evaluate (pun intended :D) my opinion in that context.

>in my experience with Python and its REPLey incarnations, I would have felt much more at peace if there was a good and reliable C++/Rust REPL

How so? My experience is exactly the opposite.

Stateful Hot-Reload/REPL Workflows that I used/use: I have used Emacs+Jupyter in the past, also played around with Jurigged, and currently I use the 'Send to Repl' functionality available in PyCharm.

Still, there are rough edges,

1. Rough: No (ergonomic) expression-evaluation available at the moment, hopefully tree-sitter based tools will solve this in the future.

2. Rougher: In the general case, I can't redefine a function/class. The 'global' namespace can be used to 'some extent' to achieve 'deterministic redefinition', but the code strays away from idiomatic Python.

3. Roughest: I have found Python performance to always be a concern. Maybe I am biased towards C/C++/Rust for performance purposes, aka Optimal Resource Utilization.

The only thing I can agree on here is performance, but I already included that aspect before. I don't see how existing expression evaluation could be more or less "ergonomic." It is what it is and it's already far better than anything for C/C++. And since classes and functions are all objects in python and there are no private members, everything is trivial to redefine in practice. I do this constantly.

There's also C++/CLI.

Recently updated to C++20, although not all of it.

https://devblogs.microsoft.com/cppblog/cpp20-support-comes-t...

Reply on news.ycombinator.com