Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Joker: A small interpreted dialect of Clojure written in Go

joker-lang.org

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Joker: A small interpreted dialect of Clojure written in Go

#51

Post by didibus »

didibus wrote: post #41

Some clarification for those interested: Joker is not a dialect of Clojure hosted on the Go runtime. Joker is a dialect of Clojure using its own interpreted runtime, that happens to be implemented in Go. That means you cannot use Joker to build statically linked Go binaries and you cannot interop with Go from your own code. And if you're interested in the idea of having an interpreted implementation of Clojure, for s…

A small correction, Babashka is implemented in Clojure, not Java, but, as such, it can also make use of Java libraries as part of its implementation. So Babashka can bundle both Clojure or Java libraries inside itself.

Re: Joker: A small interpreted dialect of Clojure written in Go

#52

Post by didibus »

cutler wrote: post #50

For me the most interesting compilation target for Clojure is Dart. Writing Flutter apps in Clojure would be the dog's spherical objects. David Nolen thinks likewise and has commented on it in a recent defn podcast. Christophe Grand and Baptiste Dupuch are the brains behind it: https://twitter.com/cgrand/status/1350063059864346624?lang=e...

Has Flutter really become that popular and awesome? I feel I'm still seeing a lot more of React Native or Electron and other JS based front-ends in the wild, for which ClojureScript is best suited. I'm not sure I'm convinced Flutter will be able to break through those even with Google behind it.

Re: Joker: A small interpreted dialect of Clojure written in Go

#53

Post by nkozyra »

didibus wrote: post #52
cutler wrote: post #50

For me the most interesting compilation target for Clojure is Dart. Writing Flutter apps in Clojure would be the dog's spherical objects. David Nolen thinks likewise and has commented on it in a recent defn podcast. Christophe Grand and Baptiste Dupuch are the brains behind it: https://twitter.com/cgrand/status/1350063059864346624?lang=e...

Has Flutter really become that popular and awesome? I feel I'm still seeing a lot more of React Native or Electron and other JS based front-ends in the wild, for which ClojureScript is best suited. I'm not sure I'm convinced Flutter will be able to break through those even with Google behind it.

I feel like it's picking up steam.

I've written a few things in it and found fewer footguns than React Native.

Granted, it comes with its own set of idiosyncracies, breaking version changes, half baked community libraries and developer ecosystem, but that's par for the course.

Re: Joker: A small interpreted dialect of Clojure written in Go

#54

Post by didibus »

zerr wrote: post #16
masijo wrote: post #3

This project looks awesome, though I'm a bit sad that "performance" is a non-goal as stated in the README. Clojure being able to compile to a single shippable binary is just what I need in my life. Kudos to the author.

What would be the advantage over other Lisps if you won't be able to leverage JVM ecosystem?

Depending who you ask, Clojure provides some benefits over other Lisps unrelated to its ability to leverage the JVM.

Some of those are:

    - Default efficient immutable collections
    - Good support for safe concurrency and multi-core programming
    - Extended homoiconicity to include maps, vectors and sets as well as lists
    - Convenient short lambda syntax
    - Extensible data representation
    - Distinguishes between nil and empty list
    - Distinguishes between keywords and symbols
    - Real boolean types
    - Function arity overloading
    - Well thought out abstractions and set of standard functions: collections are abstractions, lazy sequences, transducers, relational set manipulation, etc.
    - Only two kinds of equality: by value or by reference, with the former being the default
    - Is a lisp-1 like Scheme, but also with more batteries included like Common Lisp
    - Slightly different visual appearance in its syntax, due to support for literal maps and vectors as well as lists, which can make things easier to visually parse.

Re: Joker: A small interpreted dialect of Clojure written in Go

#55

Post by skybrian »

geeio wrote: post #47
skybrian wrote: post #37

Earlier quoted context omitted.

For one thing you have C unions. You can store different types in the same place and use information stored elsewhere to know what the bits really mean. It’s horribly unsafe compared to a Go interface or the tagged unions in other languages, but uses less space. Also, there is the NaN boxing trick [1], which allows you to store a value that is essentially a tagged union that is either a double, a pointer, or an integ…

I think you could do the pointerless version (the one using an int32 index) of this in go via unsafe casting. I’ll try it out later

Yes, the problem is that you still need pointers, and furthermore, pointers to different kinds of objects, of different sizes. Also, Go’s garbage collector should know about the pointers.

You could represent the heap as an array, use array offsets instead of pointers, and do your own garbage collection, but that’s pretty low level and you might as well compile to WebAssembly.

Re: Joker: A small interpreted dialect of Clojure written in Go

#57

Post by didibus »

geokon wrote: post #43
dig1 wrote: post #34

Earlier quoted context omitted.

> some weird corner cases (like how `(first ..)` is slower than `(nth .. 0)` I would not consider this a corner case; it is stated in (first) docstring. (first) will create seq [1] object, then it will fetch the first element. (nth), on other hand, will not create seq object. > The STL is very strict on the "zero cost abstraction" front. Many edge cases which are lost in myriad of classes. For example, vector will al…

I mean, I didn't say it's undocumented behavior :) but when the default performance of a basic function like `first` is not O(1) then that strongly suggests that performance is secondary to composability/flexibility (I'm actually not clear why it doesn't alias to `(nth .. 0)` .. I'm sure there is a good reason) In Clojure you don't really reason about vector's run time behavior at all like in C++. You can't even ensu…

> function like `first` is not O(1)

The Clojure `first` function on lists and vectors is O(1), not sure why you think it isn't. Are you thinking of `last` ?

Re: Joker: A small interpreted dialect of Clojure written in Go

#58

Post by geeio »

skybrian wrote: post #55
geeio wrote: post #47

Earlier quoted context omitted.

I think you could do the pointerless version (the one using an int32 index) of this in go via unsafe casting. I’ll try it out later

Yes, the problem is that you still need pointers, and furthermore, pointers to different kinds of objects, of different sizes. Also, Go’s garbage collector should know about the pointers. You could represent the heap as an array, use array offsets instead of pointers, and do your own garbage collection, but that’s pretty low level and you might as well compile to WebAssembly.

Agreed, when you start to need these kind of optimizations, go might not be the best choice

Re: Joker: A small interpreted dialect of Clojure written in Go

#59

Post by geokon »

didibus wrote: post #57
geokon wrote: post #43

Earlier quoted context omitted.

I mean, I didn't say it's undocumented behavior :) but when the default performance of a basic function like `first` is not O(1) then that strongly suggests that performance is secondary to composability/flexibility (I'm actually not clear why it doesn't alias to `(nth .. 0)` .. I'm sure there is a good reason) In Clojure you don't really reason about vector's run time behavior at all like in C++. You can't even ensu…

> function like `first` is not O(1) The Clojure `first` function on lists and vectors is O(1), not sure why you think it isn't. Are you thinking of `last` ?

I wasn't exactly able to find it's complexity - but here is a blurb about it's performance issues:

https://tech.redplanetlabs.com/2020/09/02/clojure-faster/#fi...

I think I'm may have been wrong and it's not a complexity issue, but just incredibly slow.

Re: Joker: A small interpreted dialect of Clojure written in Go

#60

Post by iainctduncan »

vnorilo wrote: post #23
geokon wrote: post #20

Earlier quoted context omitted.

I think recreating Clojure point by point is not optimal. There is some middle ground between full on Clojure and the straightjacket of the STL datastructures. - Clojure is kinda difficult to reason about performance wise. The lazyness.. some weird corner cases (like how `(first ..)` is slower than `(nth .. 0)` - The STL is very strict on the "zero cost abstraction" front. Maybe something like Immer but with some syn…

You see, I'd like to write more of my software in Clojure (or any functionally inclined Lisp). If there was a really good interop story with a non-gc:d native lang I could do more of it. Clojure is a hosted language, so hosting it on C++ (or Rust etc.) would be sweet for me personally. Also, I like compiler projects.

You could check out s7 Scheme. I'm using it for music apps, and it shares a lot of Clojure's design decisions, like being fundamentally a lisp-1 but having many CL inspired features. It's very minimal, and super easy to embed in a C/C++ host. And liberally licensed.
Post reply on HN