Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe is building a Ruby typechecker

medium.com

Post reply on HN
Print view View original

11–20 of 187 posts

Re: Stripe is building a Ruby typechecker

#11

Post by zarvox »

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.

It's substantially less risky, less invasive, and easier to do in parallel with other ongoing feature development than a port to another language would be. It's much easier to get incremental value for the investment if you're keeping the same language and codebase than if you're trying to replace everything all at once.

Re: Stripe is building a Ruby typechecker

#12

Post by pg_bot »

matchbok wrote: post #8
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.

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.

Re: Stripe is building a Ruby typechecker

#13

Post by parvenu74 »

masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.

Re: Stripe is building a Ruby typechecker

#15

Post by mping »

matchbok wrote: post #8
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.

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 that dynamic, but then again depends on what convetions are used. I don't care much about autocomplete unless I have to type ReallyLongClassNamesThatAreSupposedToBeMeaningful; besides coding is mostly about avoiding errors, not typing faster.

In the end, whatever floats your boat but dyn langs surely have their place.

Re: Stripe is building a Ruby typechecker

#16

Post by chrisseaton »

parvenu74 wrote: post #13
masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.

> Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project

No. So the idea pretty much stops there.

Re: Stripe is building a Ruby typechecker

#17

Post by iamleppert »

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 language, use one. Use one that was designed for deterministic behavior and static correctness.

If you have a huge codebase in Ruby that is full of bugs and is unpredictable, don’t blame the language or lack of types.

There are plenty of ruby codebases that are bug free and work well without static typing. How do they exist?

Re: Stripe is building a Ruby typechecker

#18

Post by adamnemecek »

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…

> There are plenty of ruby codebases that are bug free and work well without static typing. How do they exist?

This is a bad question. Refactoring Rails is AFAIK a nightmare. Given enough devs it can probably be done, however it might be painful.

Re: Stripe is building a Ruby typechecker

#19

Post by bogdanu »

I know the editor is not the news, and it's used just for demo, but more info about it: currently it's an ACE editor strapped to a wasm that performs the checking. The integration looks more like a quick poc since it's not using an webworker for performing the checks nor does it use the editor's markers for errors.

Re: Stripe is building a Ruby typechecker

#20

Post by f00_ »

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…

what's wrong with adding type hints in python? It's literally just a linting tool. It's jsut some extra documentation so someone can tell what types a function expects and what types it return. You can run something like mypy or pyre and you can have some static checking done on your code

"will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter."

you sound like a pompous cunt honestly

Post reply on HN