Twitter | Search | |
Dmitry Petrashko
It's public now: is building a typechecker for with emphasis on scalability and user-friendliness. Currently presenting it at with and . Try it: . See it at Tachibana room at
Reply Retweet Like More
Alexy Khrabrov [AKA Dr. Like Duh] May 30
Replying to @darkdimius @posco and 3 others
Is it, um, scalac?:)
Reply Retweet Like
Felix Mulder May 30
Congratulations Dima!
Reply Retweet Like
Denys Shabalin May 31
Any technical details out yet? Would be interesting to hear how it works under the hood.
Reply Retweet Like
Dmitry Petrashko May 31
We currently do 100k lines per core and scale linearly up to 64 cores(didn't test further). I wish this would have been possible based on scalac. It's written in modern C++.
Reply Retweet Like
Dmitry Petrashko May 31
Replying to @darkdimius
Technical details: - 9 month of work by 3 people; - real thing, runs over all code of - is ridiculously fast, 100k lines\second\core non-incremental mode - written in modern C++; - currently in beta: Stripe engineers can opt-in for it; (continued)
Reply Retweet Like
Dmitry Petrashko May 31
Replying to @darkdimius
(continued) - focus on practicality; - the entire thing is designed with nice error messages in mind; - local type inference, no need to declare local variables; - non-nillable types by default; - smart control-flow dependent typing; - union and intersection types.
Reply Retweet Like
Jake Craige May 31
This looks cool! Is it available to start experimenting in local projects with or not yet?
Reply Retweet Like
@nelhage May 31
Not yet, sadly! We intend to open source but haven't had the resources to split out the Stripe-specific bits and are still focusing primarily on the internal deployment.
Reply Retweet Like
Sam Clopton May 31
Can the overhead of it be disabled for production code and only run in dev/CI?
Reply Retweet Like
Daniel Patterson Jun 1
Type checkers don’t have production overhead. They run beforehand, analyzing code and producing errors, in development, testing, perhaps in commithooks, etc.
Reply Retweet Like
Alexy Khrabrov [AKA Dr. Like Duh] Jun 1
Replying to @darkdimius @posco and 4 others
Submit it to for sure!
Reply Retweet Like
Caleb Albritton Jun 1
So I found a custom typed Ruby interpreter in GitHub interprise that looked really interesting and now works at Stripe. Then stripe builds a public one. Coincidence? πŸ€”
Reply Retweet Like
Caleb Albritton Jun 1
*Enterprise
Reply Retweet Like
Ben Lavender Jun 1
Yep :) stripe used 's parser to start out but I have nothing to do with it :)
Reply Retweet Like
Marc β˜…β˜…β˜…β˜…β˜† Jun 1
Replying to @darkdimius
How would you check a "this returns a boolean" signature? :) I guess Ruby doesn't really have a common Ancestor of TrueClass and FalseClass, so I guess you wouldn't be able to say "returns True/False" ?
Reply Retweet Like
Dmitry Petrashko Jun 1
Replying to @rb2k
It can, as we support union(and) types. We also support type alias to create a shorter syntax. Here's how you can do this:
Reply Retweet Like
Tony Arcieri Jun 2
Would be good to chat (again). I'm presently mentoring a Ruby GSoC project to add a type annotations syntax to MRI (exposed through Ripper then erased w\ no typechecking). I think a project like this would benefit, especially if it got upstream.
Reply Retweet Like
Vlad Ureche Jun 3
Cool! Congrats Dima + team! Any idea when you'll open-source it?
Reply Retweet Like
John Weir Jun 3
This looks great! There is a way to declare signature receiving/returning a class/module instead of an instance?
Reply Retweet Like