Ask HN: Experience using dynamic languages for big projects

3 pointsthrowaway384051y ago3 comments

To give you some context for my question:

I would consider myself an experienced developer and have built software with different languages in different domains. My life runs on Bash and for super small personal projects I love the workflow of dynamic languages like Ruby or Python. I would also consider myself to be quite adequate at TDD to drive my development, use REPLs for rapid feedback etc.. (I mention this, because I often saw people dismissing dynamic languages, which used a workflow which only works with statically typed languages.)

With this context, I observed that many other developers and I have a threshold of N lines of code (3000, 5000, ...?), where they start to prefer languages with static type checkers. (Of course dependent on the domain and give or take.)

Especially when working in teams, I experienced people doing bad things in code w/o a static type checker, and of course when using languages like Golang, TypeScript or Java, the tooling is IMHO on a completly different level.

I am interested in experiences from people using dynamic languages for medium to big >= 10000 LOC projects in teams of 2 or more people which also have enough experience with statically typed languages to make a informed decission. What is your general experience? What kind of projects did you do? Would you use dynamic languages again for this projects? What advice would you give for using dynamic languages successfully and sustainably? What problems did you discover?

3 comments

wavemode1y ago

I once worked at a startup with a few hundred thousand LOCs of JavaScript (nodejs). We were in the process of evaluating TypeScript but were mostly still on plain JS.

The project had good test coverage. The main issue I had working in that codebase was never reliability, it was documentation. It's simply harder to read code that doesn't have types annotated. It takes longer to figure out what the shape of some certain data is, or is supposed to be.

Separately from that job, I've also worked with 1M+ LOC codebases in Ruby as well as Python. The Ruby codebase was statically typechecked with Sorbet and the Python with mypy. Big improvement to developer experience IMO.

It's common to ask, "why even use Ruby/Python and then typecheck it anyway?" But that question misses the point. The power of dynamic languages, in my opinion, isn't really that the types are dynamic. Rather, it is that the environment is dynamic. One thing this unlocks is that types and functions are just values and can be freely inspected, and created, at runtime. Another is that you can attach a REPL to a running system and inspect and debug it, live. Both of these allowed us to develop features and solve problems at a greater velocity than if we'd been working with a more static language.

throwaway38405OP1y ago

Thank you very much for your feedback and insights!

Two follow up questions:

You mention that functions/types are just values and can be created at runtime. IMHO you get the same with Java (8+) and everything running atop the JVM, Golang and some other programming languages. Why is this such a big differentiator for you?

The other thing I find interesting, that you didn't mention tooling at all. For me, navigation in bigger code bases is a killer feature ('one reads code more of ten than write it'). Code navigation/auto complete is IMHO much inferior in dynamic languages, even for small projects and with state of the art IDEs (IDEA...). (And not even mentioning deploying the software to servers/clients.) Did you find issues with the tooling in these projects, don't you care and just use VIM/Emacs or wasn't it just bothering you enough to mention?

wavemode1y ago

> IMHO you get the same with Java (8+) and everything running atop the JVM, Golang and some other programming languages.

I mean... kind of? Java and Go both have reflection, sure. Creating types at runtime (e.g. for mocking) also kind of exists ... kind of. Though it's very hacky in both languages.

The REPL story is also much better in dynamic languages. I've seen production incidents get investigated, diagnosed and resolved in minutes, that would've taken hours at other companies.

Though of course with great power comes great responsibility. I've seen some abhorrent misuses of reflection, and I've seen issues caused by overuse of prod REPLs. It's all a tradeoff at the end of the day.

> Code navigation/auto complete is IMHO much inferior in dynamic languages

With type annotations, I've never had any problems with autocomplete or code navigation in Python (e.g. PyCharm, Python extensions for vscode, etc). Ruby either.

Without type annotations, you're gonna have a hard time.

j / k navigate · click thread line to collapse

Ask HN: Experience using dynamic languages for big projects

3 pointsthrowaway384051y ago3 comments

To give you some context for my question:

3 comments

wavemode1y ago

I once worked at a startup with a few hundred thousand LOCs of JavaScript (nodejs). We were in the process of evaluating TypeScript but were mostly still on plain JS.

throwaway38405OP1y ago

Thank you very much for your feedback and insights!

Two follow up questions:

wavemode1y ago

> IMHO you get the same with Java (8+) and everything running atop the JVM, Golang and some other programming languages.

I mean... kind of? Java and Go both have reflection, sure. Creating types at runtime (e.g. for mocking) also kind of exists ... kind of. Though it's very hacky in both languages.

The REPL story is also much better in dynamic languages. I've seen production incidents get investigated, diagnosed and resolved in minutes, that would've taken hours at other companies.

> Code navigation/auto complete is IMHO much inferior in dynamic languages

With type annotations, I've never had any problems with autocomplete or code navigation in Python (e.g. PyCharm, Python extensions for vscode, etc). Ruby either.

Without type annotations, you're gonna have a hard time.

j / k navigate · click thread line to collapse