[krick]

Everyone is supposed to be cheering for how "fun" it is, but every time I see anything like that I cannot help but think, that I hate the fact it can be implemented in Rust. It never truly was a simple language, but I think it started as something way more manageable than what it has become.

[zxexz]

Rust is definitely not a simple language, I agree there.

I am quite likely a bit naïve here, but I'm having trouble understanding why you hate that this is possible. Now, the macro system definitely can generate near infinitely-complex code, but I'm not getting how implementing a sandboxed lisp using macros is a particularly potent example of the language being less manageable than at its genesis.

On another note, the fact that the type system is turing-complete, like with C++ templates or the Haskell type system (variously dependent on which GHC languages extensions you're using...), makes me want to see a lisp implemented that way!

[quasigloam]

Implementing a lisp in the type system would be fun, that's originally what this project was about until I got distracted with macros. Awesome projects like fortraith (https://github.com/Ashymad/fortraith) already exist, and even far more useful projects like dimensioned (compile time dimensional analysis using type level numbers) are inspiring. These examples, although cool, are probably a worse sign for krick for Rust compared with macro_rules being Turing complete.

[zxexz]

Aha, that's pretty cool! Didn't even scroll more halfway down the page before my lizard brain saw some something resembling Peano numbers.

Thanks for sharing your project, by the way - between this and the other one you linked, I think I know what my leisure time this weekend is going to consist of...

[quasigloam]

No problem! I had fun making it, for such a silly little project it's given me a surprising amount of joy. If you want to look at another cool project that's tangentially related, have a look at Sectorlisp.

[zxexz]

Oh, I'm very well acquainted with Sectorlisp - I even have a scrappy local package on nixos to build, boot and launch a qemu repl for it locally! Somewhere around here there's an HDD in an X200 that probably still has it in the boot sector on its HDD.

I think I objectively suck at lisp, but that doesn't preclude me from being a "Greenspan enjoyer" :) I think all of my projects that used Selenium ended up with a haphazardly-pieced-together lisp interpreter as their scripting tool after I realized whatever I was writing was effectively becoming a DSL in a .ini/.yaml/.toml file. These days, I mostly use nix, but my dream is a lispy NixOS (yes, I know of and have used Guix, but I really just want a lisp<>Nix 'native' compiler, and to be able to use it with nixpkgs without hassle).

[pkolaczk]

> but I think it started as something way more manageable than what it has become.

Hard disagree here. Rust team is continuously making the language easier to work with by removing limitations and making features more orthogonal. A notable example is non lexical lifetimes, impl Trait in return position or async traits. Also they have removed some features eg before it went 1.0, it even had GCed references built in with special syntax.

[rapsey]

The only real change since 1.0 was async. If you want to live without async that is completely up to you. It is an entirely optional part of the language.

If you want a language guided by the principle of simplicity Rust was never that and you have plenty of options elsewhere.

[xedrac]

Except that many crates only provide an async interface. I actually use async for many things, but the whole colored functions thing is really annoying.

[chickdilla]

One trick to get out of this is to wrap any function with an asynchronous interface with pollster::block_on which turns the call back into exactly how it would have run if it had been synchronous (which leads to no color leaking).

[xedrac]

Yes, easy enough but annoying. Going the other direction (async -> sync) is a bit more problematic though. Now you've got to wrap things in spawn_blocking(), which isn't nearly as benign.

[IshKebab]

Nah, it really takes very little for something like this to become possible. I bet you could do it with C macros, which are supposedly simple.

(I checked; I win this bet: https://github.com/kchanqvq/CSP )

[huijzer]

Aren’t macro’s always very powerful but at the same time very tricky? I wouldn’t count the macro side into language complexity. It’s an add-on which you can but don’t have to use (I’m talking about creating macro’s here.)

[josmar]

If it's Turing Complete, there will be a LISP for it