Live data from Hacker News

Open-sourcing MonkeyType – Let your Python code type-hint itself

engineering.instagram.com

21–30 of 237 posts

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#21

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

I literally just had this exact thought independently of you. I mean if you need to do something like this, doesn't that mean you should be writing code in a statically typed language?

there's a difference between should be and should have been

maybe it's easier to do this half-measure than rewrite your entire code base

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#22

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

I literally just had this exact thought independently of you. I mean if you need to do something like this, doesn't that mean you should be writing code in a statically typed language?

There's still a good deal of people who think of static typing as 'limiting', and dynamic typic as 'human'. Matsumoto said as much during (iirc) last years Ruby conf.

I think the reverse is true. Static typing is liberating for humans because it tames complexity. Because I'm not a machine I cannot possibly keep track of fuzzy programs that arise from dynamic typing.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#23

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

This tool seems to be built for teams that have already created large codebases in non-typed languages. This is a pretty common thing today. They are addressing a very real problem that a lot of people face which is "oh we fucked up, what's the most painless way we can fix it".

We just recently moved our entire codebase from JS to TypeScript which was pretty hard but super worth it.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#24

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

I agree with you but I think it's pretty straightforward how this sort of thing happens:

1. Startup builds thing fast in dynamic language because they need to optimize for development speed and iteration, not maintainability or scalability.

2. Startup grows and continues to hire for expertise in the tech stack they are mostly already using.

3. Repeat for some years and some hundreds of engineers and you arrive at this exact scenario.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#25
post #9

Earlier quoted context omitted.

If lots of successful projects use what you consider the “worst” technology, perhaps the problem is with your perception rather than the technology?

Those people believe that the right choice is assembly unless you can write directly in hex /s

I was taught assembly at the job by an old assembly guru. His first statement to me was something along the lines of: "we'll use an assembler to start with, but it doesn't generate very good code; so, once you're comfortable, we'll hand assemble our machine code".

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#26

Earlier quoted context omitted.

I literally just had this exact thought independently of you. I mean if you need to do something like this, doesn't that mean you should be writing code in a statically typed language?

there's a difference between should be and should have been maybe it's easier to do this half-measure than rewrite your entire code base

I get that part, but for new projects, this perhaps is a hint to do things in Java?

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#27
post #4

"At Instagram we have hundreds of engineers working on well over a million lines of Python 3." It always amazes me that some of the most popular products around are built with the worst technology choices. And now they had to build their own static type checker, which slows down random samples of real users, just to shore up the language's weaknesses? Outstanding.

Let's make this thread useful instead: Please enlighten the HN community at large: Tell us how you'd build instagram, what your tech choices would be and why Python is the "worst technology choice".

(If this goes well maybe you'll get an email from Mike Krieger with the subject line "Here, you do this".)

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#28

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

I literally just had this exact thought independently of you. I mean if you need to do something like this, doesn't that mean you should be writing code in a statically typed language?

Disclaimer, I'm a regular horn tooter for F# but imho this is such a perfect case for the language. It has similar line density to python, but with static type inference. Admittedly you will have to be explicit about using mutables, but I'm going to bet that instagram already cares about that.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#29

Reading this as someone who writes mostly in statically typed languages, the whole exercise seems odd. Having so much dynamically typed code to maintain that you need to run production code using a separate tool just to figure out the types sounds just wrong. Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are look…

I agree with you but I think it's pretty straightforward how this sort of thing happens: 1. Startup builds thing fast in dynamic language because they need to optimize for development speed and iteration, not maintainability or scalability. 2. Startup grows and continues to hire for expertise in the tech stack they are mostly already using. 3. Repeat for some years and some hundreds of engineers and you arrive at thi…

This is exactly it.

People are running a business, not writing an a treatise on code maintenance and hygiene.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#30

Earlier quoted context omitted.

there's a difference between should be and should have been maybe it's easier to do this half-measure than rewrite your entire code base

I get that part, but for new projects, this perhaps is a hint to do things in Java?

80% of startups are going to die before their codebase reaches this size. They should probably not be making tech stack choices based on "what if we succeed beyond all likelihood".
Post reply on HN