4 ms·

> Nice, but the author could join efforts with one of the few attempts to have a native Clojure compiler instead. Clojure has a layer of complexity originating

by exDM69 12y ago

> Nice, but the author could join efforts with one of the few attempts to have a native Clojure compiler instead. Clojure has a layer of complexity originating from the JVM background. It makes sense to not to use the Clojure codebase as is. JVM is the reason I am not using Clojure. I can't be the only one in this position. I need interoperability with native libs, JVM is just a hindrance for me. > Another remark, is that it would have been nicer to have the language being made in itself instead of OCaml. Definitely, but bootstrapping a language is quite a lot of work. Makes a lot of sense to build the "Stage 0" compiler using O'Caml or Haskell (which are excellent languages with good libs for building compilers). If it catches on, I'm sure this project will eventually become self-hosting.

artagnon 12y ago
Many modern high-level languages use some kind of VM (most notably Clojure and V8). This is a means to provide a JIT, do runtime optimizations, and garbage collection. AOT means that you don't have a chance to do anything about the generated code at runtime. That said, the startup time of a monster like JVM is definitely problematic; the approach I'm taking is a thin VM.
- exDM69 12y ago
  > Many modern high-level languages use some kind of VM I don't think this is a good approach and it's very nice to see projects like yours that try to shift the paradigm. LLVM can provide many of the benefits of bytecode based VMs, yet give efficient native code in the end. How did you go about the GC? Did you grab a GC from somewhere else or build your own? Did you use LLVM shadow stacks and/or GC annotations? I guess Lisp is a lot easier to build a GC for than other languages. There are many promises VMs should give, performance, safety and security but in practice not a lot of those promises were ever fulfilled. Performance can be on-par with native code in the best case but usually 2-10x behind, safety may be a bit better but we still get crashes because of incorrect memory use and the Oracle JVM has had more zero day vulnerabilities than any other software I can name. I think it's time to move on.
  - pjmlp 12y ago
    One issue with the current state of affairs with VM runtimes is that most developers without compiler developer knowledge, now think memory safe runtimes == VM. I really think Java did a left turn there, by not providing native compilers as part of the standard toolchain. At least .NET has NGEN and now will get .NET Native compilers as well. Yes, Sun/Oracle JVM had quite a few security vulnerabilities, but many were caused by the native code in the VM stack. While others were indeed caused by real bugs in library code. Still way less exploits that in C and friends. Besides that was one JVM, there are plenty of others out there which share 0% implementation with Oracle's.
  - artagnon 12y ago
    The plan is to eventually stick with LLVM MCJIT with custom optimizations. There's really no point in producing an AOT binary. I don't do GC yet. I suspect it happens because the VM becomes too large and complex for anyone to debug.
    - sklogic 12y ago
      Are you doing some fancy region analysis (e.g., like in Harlan) instead of GC?
enupten 12y ago
> I need interoperability with native libs, JVM is just a hindrance for me. Have you checked out CFFI/Common Lisp ? I've heard Chicken Scheme and Bigloo are also quite good when it comes to this.

by exDM69 12y ago

artagnon 12y ago

Many modern high-level languages use some kind of VM (most notably Clojure and V8). This is a means to provide a JIT, do runtime optimizations, and garbage collection. AOT means that you don't have a chance to do anything about the generated code at runtime. That said, the startup time of a monster like JVM is definitely problematic; the approach I'm taking is a thin VM.

exDM69 12y ago
> Many modern high-level languages use some kind of VM I don't think this is a good approach and it's very nice to see projects like yours that try to shift the paradigm. LLVM can provide many of the benefits of bytecode based VMs, yet give efficient native code in the end. How did you go about the GC? Did you grab a GC from somewhere else or build your own? Did you use LLVM shadow stacks and/or GC annotations? I guess Lisp is a lot easier to build a GC for than other languages. There are many promises VMs should give, performance, safety and security but in practice not a lot of those promises were ever fulfilled. Performance can be on-par with native code in the best case but usually 2-10x behind, safety may be a bit better but we still get crashes because of incorrect memory use and the Oracle JVM has had more zero day vulnerabilities than any other software I can name. I think it's time to move on.
- pjmlp 12y ago
  One issue with the current state of affairs with VM runtimes is that most developers without compiler developer knowledge, now think memory safe runtimes == VM. I really think Java did a left turn there, by not providing native compilers as part of the standard toolchain. At least .NET has NGEN and now will get .NET Native compilers as well. Yes, Sun/Oracle JVM had quite a few security vulnerabilities, but many were caused by the native code in the VM stack. While others were indeed caused by real bugs in library code. Still way less exploits that in C and friends. Besides that was one JVM, there are plenty of others out there which share 0% implementation with Oracle's.
- artagnon 12y ago
  The plan is to eventually stick with LLVM MCJIT with custom optimizations. There's really no point in producing an AOT binary. I don't do GC yet. I suspect it happens because the VM becomes too large and complex for anyone to debug.
  - sklogic 12y ago
    Are you doing some fancy region analysis (e.g., like in Harlan) instead of GC?

enupten 12y ago

> I need interoperability with native libs, JVM is just a hindrance for me. Have you checked out CFFI/Common Lisp ? I've heard Chicken Scheme and Bigloo are also quite good when it comes to this.