Stripe is building a Ruby typechecker • Hacker News Board

Re: Stripe is building a Ruby typechecker

#131

Post by Kalium » Mon, Jun 04, 2018, 3:58 PM UTC

random3 wrote: post #127

Kalium wrote: post #42

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.

I think making Ruby typed is a cool endeavor. It's just that it's a bit hard to justify from a business perspective.. It's not like changing to typed Ruby wouldn't affect the code bases. They'll end up having something that will resemble Ruby, but likely won't be quite Ruby. It's unlikely they could automate it. They'll have to rewrite a lot of code and typically, when you do that you also want to refactor obvious pr…

I think it becomes a reasonable business pitch if you look at it as a tool that significantly reduces the defect rate and improves on-time delivery.

Re: Stripe is building a Ruby typechecker

#132

Post by amelius » Mon, Jun 04, 2018, 4:01 PM UTC

Kalium wrote: post #111

amelius wrote: post #108

Earlier quoted context omitted.

> boiling any number of oceans How many lines of code are we talking about here?

How many services do you think a big company like Stripe has? Let's be exceptionally conservative and assume fifty, with a minimum of a million LoC between them. All of them need to keep working for the business to keep working.

Ok, but they also have a lot of developers.

Re: Stripe is building a Ruby typechecker

#133

Post by Willamin » Mon, Jun 04, 2018, 4:11 PM UTC

exabrial wrote: post #40

Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?

If larger companies (eg. Stripe) would put more effort into improving Crystal instead of improving Ruby, Crystal would absolutely blow Ruby out of the water. Instead we get improvements to Ruby because larger companies have larger codebases and don't want to refactor everything all at once. They'd rather slowly add type annotations to their Ruby codebase until eventually it's all done. I get it, it's better from a business perspective short term. In the long term, Crystal would be able to run at least hundreds of times faster than Ruby.

Re: Stripe is building a Ruby typechecker

#134

Post by workinthehead » Mon, Jun 04, 2018, 4:15 PM UTC

Kalium wrote: post #65

qop wrote: post #60

Earlier quoted context omitted.

With Ruby getting an AST, and potentially a type system in the future, I think that ruby 3 could lend itself to bring transpiled to crystal relatively easily, depending on exactly how much type information there is, how difficult / possible it is to correlate that with the AST. Scala 3 is doing the typed AST thing, so hell, why not?

You're absolutely right! Any Turing-complete language can be transpiled to any other. That said, you can't always expect sensible or human-brain-friendly results if you're moving between two languages that work very different.

Why must you keep telling people "You're absolutely right!" It seems insincere and condescending at best. If you really think you know better than the person you're responding to, use evidence and logic, not cheap conversational ploys.

Re: Stripe is building a Ruby typechecker

#135

Post by draw_down » Mon, Jun 04, 2018, 4:19 PM UTC

mbesto wrote: post #106

So you know when people ask "why does X startup have X,000 developers? what do they do all day for a single app[0]. Here is your answer: "Technical details: - 9 month of work by 3 people; - real thing, runs over all code of #Stripe" https://twitter.com/darkdimius/status/1002103748875902978 Now let's look at this from a financial perspective: So let's say average $175k salary per employee + benefits and you're looking…

Plus, since builds take forever, projects like this give you something interesting to read about while you wait 30-40 min for your code to make it into master. (Yes, seriously)

Re: Stripe is building a Ruby typechecker

#136

Post by Willamin » Mon, Jun 04, 2018, 4:20 PM UTC

qop wrote: post #50

I think the most fascinating thing that Ruby 3 could approach is an approach similar to Dart 1's optional types. That way a fast unchecked mode could be available for developing, and REPL usage, and then a separate switch could be flicked for building a release. Seeing the Ruby devs take compatibility so seriously is such a confidence builder for me, either way. Ruby is such a joy to program in, and for certain proje…

A lot of people that love Ruby and dislike Crystal seem to dislike Crystal for reasons like what you mentioned. I'm pretty sure that you can get a sorted list of methods in Crystal (not with the same syntax unfortunately) at compile time in macros. I'm not sure why you would ever want to dynamically get a sorted list of methods at runtime... unless you're adding methods at runtime.

Re: Stripe is building a Ruby typechecker

#137

Post by Kalium » Mon, Jun 04, 2018, 4:23 PM UTC

workinthehead wrote: post #134

Kalium wrote: post #65

Earlier quoted context omitted.

You're absolutely right! Any Turing-complete language can be transpiled to any other. That said, you can't always expect sensible or human-brain-friendly results if you're moving between two languages that work very different.

Why must you keep telling people "You're absolutely right!" It seems insincere and condescending at best. If you really think you know better than the person you're responding to, use evidence and logic, not cheap conversational ploys.

I do need to mix up the verbiage more.

In practical terms, people respond much better to having their egos stroked than they do to being told they're wrong. Evidence and logic work much better when someone doesn't feel like their ego is at stake. Telling someone they're right before pointing out that they could be more right is one way to do this. Telling people that they're wrong is more likely to provoke a defensive reaction and a closed mind than it is genuine thoughtfulness and consideration. We've all seen people refuse logic, reason, and evidence because they feel personally attacked, I suspect.

This is a lesson I gleaned from the (in)famous "How To Make Friends And Influence People". It's not wrong, it's just cynical.

So of course it's insincere. Human interaction is greased with little insincerities. It's how we deal with egos.

Re: Stripe is building a Ruby typechecker

#138

Post by darkdimius » Mon, Jun 04, 2018, 4:27 PM UTC

olingern wrote: post #128

I was at RubyKaigi. This presentation was one of the best delivered, so kudos to the Stripe team for all the work put into it. A question I didn't get to ask while there is -- will there be some sort of type sharing system introduced? I've been a user of both Typescript and Flow (both great tools), but saw Typescript's popularity soar because of community written types.

> A question I didn't get to ask while there is -- will there be some sort of type sharing system introduced?

Yes. This was one of goals of our talks. We wanted implementors of type systems for ruby to start collaborating, in particular on a repository of typed shims.

The details of how this would work out might be different. Typescript and Flow change syntax and thus they cannot be included inline in arbitrary JavaScript libraries. We're intentionally compatible with Ruby syntax. Thus we would like this "repository of types for libraries" to only contain types intermittently, until types have been accepted to upstream of respective library.

Re: Stripe is building a Ruby typechecker

#139

Post by vidarh » Mon, Jun 04, 2018, 4:28 PM UTC

emodendroket wrote: post #121

vidarh wrote: post #91

Earlier quoted context omitted.

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirem…

> A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby. It probably won't be idiomatic (maybe just add interfaces?) but I think duck-typing is overrated anyway. Just because an object responds to a method doesn't mean it's going to do anything like what you expect. To take a contrived example, Array.Shift and Keyboard.Shift are probably unrelated methods…

You don't have that guarantee with interfaces either - you're trusting that the developer isn't lying to you. My experience is that I've more often run into developers that have artificially barred me from doing what I wanted by checking for a given class, than that I've accidentally passed in something that satisfies a given type but does something different.

Re: Stripe is building a Ruby typechecker

#140

Post by Kalium » Mon, Jun 04, 2018, 4:30 PM UTC

toasterlovin wrote: post #130

Kalium wrote: post #125

Earlier quoted context omitted.

All other things being equal, that's probably true!

If only all other things were equal...

That's the catch, yes. All other things are very rarely equal. There are almost always other factors worth paying attention to when forming a long-term strategy. A handful that spring to mind are availability of talent, software runtime performance, schedule impact of static vs dynamic typing, and expected runway of the business.

Producing a statically typed system that runs slowly and correctly after the business has folded is not always more valuable than producing a buggy one in time to start producing revenue.