skiko VS Petalisp

All I know is that they use skiko.

It built on a render framework named skia, JetBrains create a kotlin mapping which named skiko for it.

I was curious to give it a go but unusable on Gnome 42.5; the window lags so much that simply trying to drag to reposition it on the screen is impossible seems related an issue with Skiko and OpenGL reported here: https://github.com/JetBrains/skiko/issues/494

Fleet does not use Compose, but it does use Skiko[1], which also provides binding for Skia[2] (the native graphics library also used by Chrome & Flutter).

The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.

[1] https://github.com/JetBrains/skiko

[2] https://skia.org/

How about skiko?

JetBrains is moving from skija to skiko, but it could be interesting either way!

They Merged today the functions that will be usaged on Compose for opening, closing and handling text inputs https://github.com/JetBrains/skiko/pull/455 (if I understand correctly). Currently, the examples rely on xcodegen file, based on the currently plugin that Compose has for Desktop, it provide alot of things including packaging for desktop, I think they will provide a xcodegen file automatically and use xcodegen behind the scenes to generate everything needed.

https://github.com/JetBrains/skiko (a Kotlin MPP binding for Skia). Skiko Does not contain build for iOS. Now Skiko contains build for iOS, MAC arm processor via Kotlin/Native. So we can use Skiko for pure canvas rendering in all platform. It is matter of time they release compose for iOS. So UI also goes multiplatform.

But it does seem like the solution they're using for Fleet is different. Skia is the same graphics library used by Chromium and Flutter. I'll remain cautiously optimistic for now, but the quality of the text rendering and customization options will make or break it for me personally.

While not "as fast as C" (C is not the absolute pinnacle of performance), Common Lisp is incredibly fast compared to the majority of programming languages around today. There is even a huge amount of ongoing work being done to make it faster still. We are seeing many interesting projects that make better use of the hardware in your computer (e.g. https://github.com/marcoheisig/Petalisp).

i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC

https://github.com/marcoheisig/Petalisp

However, if you have a lisp library that puts those semantics to use, then you could get it to employ magicl/ext-blas and cl-bmas to speed it up. (petalisp looks relevant, but I lack the background to compare it with APL.)

> his means cl pagckages can be "done".

this is true if there is nothing functional that can be added to a package. however its very much not true for ml frameworks right now. new things are being added all the time in the field. however even in the package i linked you have the necessary ingredients for any deep learning model: cuda and back propagation. the other person mentioned convolution which i think is pretty trivial to implement but still, if you expect everything for you to be ready made then you should probably stick to tf and pytorch. if you want to explore the cutting edge and push the boundaries then i think common lisp is a good tool. as an aside it might also be interesting to note that a common lisp package (Petalisp) is being used for high performance computing by a german university

https://github.com/marcoheisig/Petalisp

One trick is that Common Lisp can generate and compile code at runtime, whereas static languages typically do not have a compiler available at runtime. This lets you make your own lazy person's JIT/staged compiler, which is useful if some part of the problem is not known at compile-time. Such an approach has been used at least for array munging, type munging and regular expression munging.