ClojureCLR VS Roslyn

ClojureCLR can already run on .NET 5.0 , so at least it made it through the .NET Core migration. I'm sure they'll get it to 6.0 at some point.

https://github.com/clojure/clojure-clr/wiki/Getting-started

I recently found there was a clojure implementation for .NET and also one for the BEAM Virtual Machine. Has anyone used the latter? Regards

[1] https://github.com/clojure/clojure-clr

Maybe it's not exactly a scheme, but there's Clojure CLR and it's actively maintained: https://github.com/clojure/clojure-clr/wiki

https://github.com/clojure/clojure-clr/commits/master

I don't have a huge amount of insight into the project but the commits over time don't look super healthy: https://github.com/clojure/clojure-clr/graphs/commit-activit...

Either way it's pretty clearly not a core platform for Clojure.

> I wish ClojureCLR weren't dead too

Is there any reason for saying that? Checking the commits history on Github[1], the project seems still alive.

[1]https://github.com/clojure/clojure-clr/commits/master

Here is a link to the dotnet/roslyn .editorconfig for reference, scroll down to # CSharp code style settings:

It's no surprise that IDEs can do the same thing, and they may even share the same codebase for doing so. For instance, C#'s Roslyn compiler states:

Der Compiler und das Framework sind Open source zB. https://github.com/dotnet/roslyn

Compilador de C#: Licencia MIT.

Sorry to hear that. This seems to be a bug in Roslyn (see https://github.com/dotnet/roslyn/issues/67123). If you'd like to try again, either downgrade the MVVM Toolkit to 8.0 for the time being, which should avoid the issue, or update Visual Studio to 17.6 Preview. They merged several bug fixes in 17.6 which should hopefully resolve the issue you and others were having 🙂

The likely relevant issue is part of Roslyn, so a fix needs to be made over there first. Seems to be a potential fix upstream, will have to see if it works when it makes it way into the IDEs.

Not sure which video you're referring to, but anyway, the correct API is IIncrementalGenerator, which you can find some docs for here. Disclaimer: yes, it's an extremely complicated API to use, and only meant to be used by advanced developers in very specific scenarios. If you do decide to write a generator, don't go in expecting it's something you can figure out in a weekend.

"Everything is mutable" not really, to me this is more like a library problem like EF-core rely on property to be mutable so you can't use record for EF. This is C# rationality on deciding to not support immutable/readonly var, and there is (proposal)[https://github.com/dotnet/csharplang/issues/188] for readonly var already, we just don't know if it's ever became a feature; for me it's more like a programming discipline anyway; The lambda with property are just syntactic sugar, nothing more. I get it you like it short, but C# are much older than Kotlin, it can't have all the nice, nifty trivial syntax kotlin has. (x) => x.Prop is a little bit more verbose, but clean enough in my opinion, and their support can be added later (though not necessary). Despite C# is old, it has nullable type as well, begin with nullable struct since net framework 2 (2005). Nowadays C# has nullable for reference type as well, although it's just compiler service since ref type are nullable, but you can absolutely make C# null safety just as strict as Kotlin. I do that too. Saying C# "what's a struct and what's a class" is weak.

- The feature branch is 32k commits behind main (no update since July 2020...)