Does TypeScript play nice with Ramda? I’ve tried using Ramda with Flowtype but it quickly became a noisy nuisance.

No it doesn’t

Things like compose and apply are... Difficult

@lilactown I still don't know that I buy that argument without specifics being mentioned. Clojure has a very very small dev team and community around it, yet it has achieved more then feature parity and polish in many aspects. Also, that answer is kind of side stepping my question. I'm interested in the why so that I can be aware of what specific things are missing from TypedClojure that renders it not as practical or attractive. Maybe it's a case of a thousand small details. So there's a chance you're right, it might be that each little thing just integrated better and was slightly more polished in TypeScript. But before I settle on that, I'm hoping to first eliminate the bigger major difference. But since I only toyed with core.typed and never used Typescript, I'm in no position to do that 😁😩🤤

As a slightly but still related note. I just read this: https://quickbirdstudios.com/blog/keep-87-typeclasses-kotlin/

Reading that article, all I was thinking was, oh cool Kotlin could add support for some form of typeclass. And then slowly I was realizing, man, these type issues and constraints all seem like weird accidental complexity that keeps growing, and making the logic of the code more obscure as more emphasis moves to these abstract types and their supposed safety. That's the kind of exact scenario which I feel might be entering type complexity. And I think core.typed actually suffers from that. Like wanting to achieve too much type safety can result in the overhead of figuring out how to properly design your type just no longer being worth it, as it steals precious time away from design your core logic.

@didibus Isn't TypeScript essentially a superset of JS? i.e., you can take a .js file, rename it to .ts and it's still valid?

Kinda like Groovy and Java -- but in the opposite direction? Rename .java to .groovy and it's still valid, but then you can take away type information.

Typed Clojure isn't like that tho'. You can't take a regular Clojure file and feed it to Typed Clojure and just get a "thumbs up" -- instead you get tons of errors and/or warnings and you have to annotate a lot of code to get it to shut up and accept it.

It's been a while since I last tried to do anything with Typed Clojure, but for a while we tried both Schema and Typed Clojure, going back and forth multiple times before ultimately giving up on both.

Typed Clojure definitely caught real bugs in our code -- but it also threw up a lot of false positives where we had to then wrestle the code into a form that Typed Clojure would accept (or just "give up" and mark code as "don't check this").

Ya, I think you're right on all count. But I'm wondering what's the underlying cause of that, and I think its due to core.typed having soundness as a guarantee and uncompromising tenet. While TypeScript made the trade of to go unsound so that that would not happen.

Wonder if @ambrosebs could chime in on that.

Looks like there is a talk at StrangeLoop that is highly relevant to this! https://thestrangeloop.com/2019/typing-the-untyped-soundness-in-gradual-type-systems.html

Will check for sure. Seems very on point

the clojurians log has a really nice error screen https://clojurians-log.clojureverse.org/cljsjs/2017-01-24

I’ve seen this before - is this http-kit? Looks like Django’s exception handler. Very useful for beginners. Would be great to extract that into some reusable ring handler.

I saw a thing awhile back where a popular Python http module, in dev, will open up a web REPL inside the context where an error occurred

thought that would be pretty nice to have for Clojure too

Nice post about parsing a lisp with rust, https://dev.to/deciduously/rust-your-own-lisp-50an