jiyinyiyong

again https://www.moonbitlang.com/

Creator of Cirru here. Cirru is confusing since it's a syntax of data, not a standalone language. Calcit(<https://calcit-lang.org/>) is the language I built. However Calcit does not store source code in files called `blabla.calcit` or something. Instead, Calcit stores code in data, which is called "Cirru EDN" since it's a variant of Clojure EDN. And it uses Cirru as a data format so stored in files called `compact.cirru` or `calcit.cirru`, which might confuse you PLDB data.

I've used Trunk in my personal project for years. Very glad we have a handy tool to match the experience we develop with JavaScript. Now there are more and more front-end web devtools rewritted from Node.js to Rust for performance, Trunk is already in Rust since created.

curious which model of Xiaomi phone you are using

another way to understand 3D rotation is using geometric algebra, which regard a 3D rotation with 2 reflections within an angle in the reflection planes. It's very interesting and also available calculating with 3D vectors.

https://marctenbosch.com/quaternions/#h_5 https://www.bilibili.com/video/BV1Ey4y1P782/?vd_source=85697...

I use it to setup local development env with self signed HTTPS support. Easier than using Nginx Webpack combined.

I have a HackerNews UI for myself as well https://r.tiye.me/Memkits/hn-reader/?id=38824070

GitHub: https://github.com/Memkits/hn-reader/

I prefer saying it's more like a lisp-like language like Ruby or Python...

kind of dup https://news.ycombinator.com/item?id=35089240

While virtual DOM solution has problems, I believe Dioxus https://dioxuslabs.com/ can be a better solution than Solid/Svelte solutions. We should try to optimize it with macros and other memory techniques to make it fast, rather than giving it up.

People may hold opinion that Solid/Svelte are excellent. However that's going towards another direction. Virtual DOM decouples how you declare UI and how it's rendered/updated by framework. Solid/Svelte couple them.

I built a Clojure dialect in Rust called Calcit https://github.com/calcit-lang/calcit . It's ClojureScript at core, despite its indentation-based syntax.

Congratulations to Clojure! I used ClojureScript for several years and I still consider it the best designed dynamic language in the open community. JavaScript might be great in many aspects due to huge contributions from Google and Mozilla, but it can hardly fix its young and immature designs made in last century.

Personally I moved to my own language Calcit for my own projects using dynamic language tools. Calcit is still following lots of designs from Clojure.

ReScript was advertised to be a great language for powering up React in the years of ReasonML. It may be opinionated, but people grew interest in ReScript along with React.

Chrome Canary only I suppose.

it was shown on caniuse.com that Firefox Nightly has optional webgpu support, however it does not run webgpu triangle demos. confused :(

This library is really inspiring to me in many aspects. WebGPU is interesting, declarative programming on WebGPU is fantastic.

I made Calcit http://calcit-lang.org/ it's also using indentations to implement S-Expressions. The syntax part is called Cirru http://text.cirru.org/ , just using very similar ideas.

while it's a sign that Clojure ecosystem is evolving, I won't like an ending being like this.

good idea. I will post Cirru there.

I have several more articles/videos posted in Chinese, not ready to push all that forward yet... there are too many repos under Cirru and Calcit, many of them are not well maintained I'm afraid. :D

I made myself a scripting language called Calcit http://calcit-lang.org/ , features persistent data function, macros, higher-order functions, and also compiles to JavaScript. Now I use it as a replacement for ClojureScript since I make Calcit compile to JavaScript in ES6 module, which works seamlessly with Vite!

If anyone feel interested, please give a try.

One thing to notice is Calcit is using indentation-based syntax while supporting macros. It's strange, but it works really well.

Rust really has a great support for WASM. I made a tiny language as well, and managed to build targeting WASM in a few steps https://github.com/calcit-lang/wasi-calcit/blob/main/.github... .

Tips to notice is WASM runs inside a sandbox, which means threads, random numbers generator(not sure for WASI), FFIs, etc. have to be moved out of the core to prevent them being compiled to WASM, which would probably fail. For major part of the code, they can be compiled to WASM and WASI(WASM System Interface) very easily.

...based on toolchains of Cirru and Calcit.

- Demo for Pads https://repo.cirru.org/tree-layout/ - Code https://github.com/Cirru/tree-layout

partially agreed, I would love to see tools and supports of WASM being put on a higher priority and people improves dev experiences there. JavaScript syntax is already coupled with too many factors being a scripting platform or a compilation target.

> From the browser's point of view, it would essentially treat the type annotations and type declarations as comments.

V8 still has to updater its parser. Other tools that handle JavaScript parsing need to do that as well.

> You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server.

Nope, it's not using TypeScript directly, but just another language very similar to TypeScript.

I'm programming my tools with Calcit(http://calcit-lang.org/), which is more like my personal flavored implementation of ClojureScript. It's like a combination of the ideas I learnt from Clojure community and my own ideas. It's far from optimal but I enjoy the feeling that I have access to all details of this language and the tooling.

You are right. When tools are not being friendly to indentation based syntax, the code with indentations would be a mess. Parentheses and curly braces are lot like "defensive programming" against unfriendly tools.

To explore ways of bringing Lisp to wider ranges of audiences, I prefer indentation based syntax like:

    ->
      range 100
      map $ fn (x)
        * x x
      foldl 0 &+
      println

which is S-Expressions with indentations, with in-line paren pairs. It looks a lot like Python by still using prefixed operators and it's still S-Expressions after parsing to remain homoiconic.

And my prototype language http://calcit-lang.org/ .

Not much, I would say. Something important in CoffeeScript is "everything is an expression". That was a feature in Lisps, in Haskell, in Rust, but would never be default behavior for JavaScript. JavaScript is becoming less odd with modern features, but still far from being liked.

a bad aspect of CoffeeScript I see is "it's not an industry language". too flexible, insufficient integrations with standard tools, slow fixes and new features. The industry definitely need as lot of features for pushing and also controlling work.

Nim is very attractive to a previous CoffeeScript user like me. I used it to build my own [ClojureScript clone](http://calcit-lang.org/), but finally found I really want ADT and pattern matching, which drove my to Rust.

Object variants could support this need. But I was already amazed by those Haskell features.

having built my own Lisp by learning Clojure I think Clojure does broke some ability of homoiconicity in small features.

Say I have `{:a 1}`, which is equivalent to `(hash-map :a 1)`, I take it as data and I can recreate the expression with the later form:

    user=> (quote (hash-map :a 1))
    (hash-map :a 1)
    user=> (def a (quote (hash-map :a 1)))
    #'user/a
    user=> (list (nth a 0) (nth a 1) (nth a 2))
    (hash-map :a 1)

but for `{:a 1}`, I got error since it's a bit different:

    user=> (def b (quote {:a 1}))
    #'user/b
    user=> (list (nth b 0) (nth b 1) (nth b 2))
    Execution error (UnsupportedOperationException) at user/eval12 (REPL:1).
    nth not supported on this type: PersistentArrayMap
    user=> b
    {:a 1}

now it's different, it's no longer homoiconic in this syntax.

    user=> (first b)
    [:a 1]

I would rather not using this syntax in my own lisp and still using a prefixed version.