Stripe is building a Ruby typechecker • Hacker News Board

Re: Stripe is building a Ruby typechecker

#21

Post by Tehnix » Sun, Jun 03, 2018, 10:12 PM UTC

iamleppert wrote: post #17

People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…

> Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter.

I don't see how seeking to add types precludes also understanding "closures, concurrency passing or functional programming", especially since these are in no way foreign concepts in statically typed languages.

> If you want a statically typed language, use one. Use one that was designed for deterministic behavior and static correctness.

I definitely see what you're trying to say, but as I understand it, these projects to "add types" often come on later, when the project is so big, that it is simply less time consuming to just develop a type checker, than it is to rewrite your entire codebase in a new language.

Re: Stripe is building a Ruby typechecker

#22

Post by Kiro » Sun, Jun 03, 2018, 10:14 PM UTC

iamleppert wrote: post #17

People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…

But let's say you have a function that takes an integer and goes completely bonkers when you pass in a string. Why would you not want to prevent that?

Re: Stripe is building a Ruby typechecker

#23

Post by shaneos » Sun, Jun 03, 2018, 10:20 PM UTC

paulddraper wrote: post #4

Interesting choice, considering that Stripe is a massive Scala user. Is it really cheaper to write type checking for one of the most dynamic languages ever, than port to their other language? Seems to be strong evidence against the "stack doesn't really matter" viewpoint.

Yes it is. Stripe can do this with three (badass) engineers while the hundreds of other engineers continue to build their applications in Ruby. Stripe's Ruby code base is far larger than their Scala codebase, with each being used for the types of uses that play to their strengths. Rewriting millions of lines of Ruby into another language would more or less involve pausing all application development for one to two years, which simply is not feasible.

This way, a small team of skilled engineers make this typer work, and guide its general adoption, getting the codebase well typed over the course of years, all the while Stripe continues to grow its product suite and further conquer the world of e-commerce.

Twitter did a huge Scala rewrite. There are many lessons to be taken from their lack of product velocity while doing so that the Stripe team took onboard when making this decision.

Re: Stripe is building a Ruby typechecker

#24

Post by Tehnix » Sun, Jun 03, 2018, 10:21 PM UTC

pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

What languages have you worked with before, with static types?

If it's something like Java, C, C++, etc, then I can see your point, but if you pick any of the languages with type inference (like Elm, Haskell, PureScript, OCaml, F#, etc), then you rarely actually have to write types.

Working with the type system is a different way of working. It's more beneficial to see the compiler as a helping friend, instead of an adversary that is just there to complain.

Some interesting reads might be:

- http://elm-lang.org/blog/compilers-as-assistants

- https://matthew.brecknell.net/post/hole-driven-haskell/

- http://bitemyapp.com/posts/2017-09-23-please-stop-using-type...

Personally, I honestly hate every time I don't have a time system to rely on. I don't make any false pretenses that I have the whole program in my head 100% of the time. I don't want to have to think about things that a computer can solve for me, hence I like my compiler to do as much work as possible.

As for unit testing, a type system is never supposed to remove the need for unit testing, and if you see anyone promote a language because of this, they are probably (hopefully) over simplifying. What it does do though, is significantly cut down the need for certain types of tests, since you can model so much more logic via types (ADTs, Union types, etc), and get it checked by the compiler.

As an aside: I simply do not believe you've never run into a type error, unless you've only written projects that 100 lines of code, and even then it's quite easy to run into type errors.

Re: Stripe is building a Ruby typechecker

#25

Post by Tehnix » Sun, Jun 03, 2018, 10:25 PM UTC

pg_bot wrote: post #12

matchbok wrote: post #8

Earlier quoted context omitted.

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript,…

I would disagree with the statement that coding is faster in statically typed projects. The ease of onboarding new devs is solely based on the code quality of the project. Well written programs are easy to understand regardless of typing. Terribly written programs are opaque regardless of typing.

Sure, any code base can be horrible to learn, but two equally well written code bases, types can help significantly. When your new employee can be confident that changes something in one place, won't invisibly break something in another place, they are more prone to start making changes.

Vimal Kumaar touches on how it has helped them get employees contributing to the code a lot quicker, after they moved to PureScript https://www.youtube.com/watch?v=HLEwYghBjo8 (I think around 24+ minutes in, but I recommend the whole talk).

Re: Stripe is building a Ruby typechecker

#26

Post by veebat » Sun, Jun 03, 2018, 10:31 PM UTC

pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

Well, what kind of projects? And what order of magnitude big?

Whether dynamic type errors become an issue depends a lot on how often all codepaths are run.

If what you're running is a batch processing script, it's likely to crash out as quickly as a type-checking compiler, and then static types have no direct appeal.

On the other hand, if it's a long-running server with a lot of finite state machines(maybe it's running a multiplayer game or something) it's really hard to reach type errors without an extensive manual test.

This becomes a relatively bigger issue as the codebase gets bigger, again depending on the type of code. If the main way the system expands is by handling a more diverse set of data types, dynamic types allow less code to be written, but also make it harder to verify.

In practice what I tend to see happening is that a glue layer appears that needs dynamic behavior, while the codepaths underneath that benefit more from static typing.

Re: Stripe is building a Ruby typechecker

#27

Post by matchbok » Sun, Jun 03, 2018, 11:04 PM UTC

mping wrote: post #15

matchbok wrote: post #8

Earlier quoted context omitted.

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript,…

It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases t…

I've heard the "mentally model" argument a few times, and tbh I don't quite understand it. You have to model the object regardless, either with types or tons of extra checks to make sure that object has what you need. I've seen so much javascript code do exactly that because the methods had no idea what they were going to be given. The contract of static typing eases that load, I think.

Re: Stripe is building a Ruby typechecker

#28

Post by matchbok » Sun, Jun 03, 2018, 11:07 PM UTC

pg_bot wrote: post #12

matchbok wrote: post #8

Earlier quoted context omitted.

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript,…

I would disagree with the statement that coding is faster in statically typed projects. The ease of onboarding new devs is solely based on the code quality of the project. Well written programs are easy to understand regardless of typing. Terribly written programs are opaque regardless of typing.

If I have to connect a couple classes in separate files with a few objects/stuff inside of them, I'd bet good money that a statically typed language will provide a faster coding experience. Especially if you have leveraging third party libraries. Working in huge libs in JS (Sequelize comes to mind) is a horrible development experience that requires you to have the documentation open.

Re: Stripe is building a Ruby typechecker

#29

Post by markmark » Sun, Jun 03, 2018, 11:19 PM UTC

mping wrote: post #15

matchbok wrote: post #8

Earlier quoted context omitted.

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript,…

It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases t…

When using a dynamic language you need to know what properties are on an object right? So you can work with them, access them, whatever. So just write it down so everyone else knows too. There, that was easy.

Re: Stripe is building a Ruby typechecker

#30

Post by rickyc091 » Sun, Jun 03, 2018, 11:19 PM UTC

pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

The usefulness really depends on the team. If you're working with another engineer or two and they're all senior engineers that you've coded with for a while, then it's probably not necessary since you'll understand each other.

However, if you work with a junior team or you have to inherit a project, then I've found static typing to be extremely useful. One might argue that code review is suppose to solve for that, and while you can catch some of the problems, you won't catch all.

It's definitely helped to make refactoring faster. Specs will help to some degree, but static typing will traverse through every function to ensure the parameter you're passing is as expected.

No more is this suppose to be a nil, a blank value? You can specifically define what you expect. While some people hate optionals with Swift, I've found it to be an interesting concept.