4 ms·

That source file you're referencing is a fairly low-level library doing lots of interop with Java. That's not really what most Clojure code looks like. And fur

That source file you're referencing is a fairly low-level library doing lots of interop with Java. That's not really what most Clojure code looks like. And furthermore: it's just a library, but this library is adding the concept of go blocks (as seen in Go) to the Clojure language. Are you even able to add a new control structure like go blocks to the C# langauge by including a library?

rubber_duck 8y ago
It's not really about Java interop, it's about low level procedural code - Clojure doesn't really look nice when doing it. It does a lot of stuff nicely but there are cases where it just feels wrong to use. But your second point is pretty much the reason why I wouldn't use Clojure in a bigger environment.I had the misfortune of working C# on a project where some smartass decided it was cool to use Maybe monad in C# using LINQ (something like https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad) First it provided no actual value as the code was harder to read, but ignoring that - most of the developers didn't get it and just used it enough to get shit working, it was a hell to debug and maintain. core.async is public and in core - but what about when your team meber X decides to implement that - and now he sprinkles that shit all over your codebase - people keep using it because they don't want to argue. Clojure really lends it self to that kind of a thing where you do that "smart thing" to solve "that one problem" that ends up being a pointless mess that's hard to maintain and reason about.