Ask HN: Are there senior devs who liked switching from static to dynamic typing? I'm curious if there are any senior engineers who have swapped from using statically typed languages to dynamically typed languages later in their career and prefer this way of working? I've met many senior engineers (myself included) who have made the opposite transition (dynamic -> static) and now the thought of using a dynamic language for anything outside of small scripts is uncomfortable. |
i will say that mocking/stubbing is much easier to do with dynamic languages, but this, in theory, forces cleaner integration points in static languages (i.e. accept interfaces, return types)
recently I regretted using C for a big library as I had to tack on dynamic-like features, like huge hash tables for all it's objects and methods, so that I can dispatch dynamically. in a proper dynamic language the project would be 10x smaller and safer.
Professionally, over about 12 years, I have used Java, C++, Golang, Rust, Dart, Python, Perl, and Swift. Since learning Rust, every other type system seems slightly broken. Fixing a red-underline takes a few seconds. Debugging runtime errors takes 10-times as long. And debugging runtime errors in a long CI run can take 100-times as long. Because static types let us catch errors earlier, they speed up writing and changing code.
90% of the issues that come up on the teams I've been a part of are caused by developers who are lacking architecture (and related) skills, regardless of the language we're working in. They struggle to find the core metaphors for the problem space they're working in, they struggle to name things, they struggle to find clear and effective refactor points, they struggle to consider the medium and long term implications of their decisions, they struggle to organize code well, etc.
(The other 10% of issues are constantly changing business requirements.)
Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.
Personally, my most recent stint with a statically typed language (Swift) was hella frustrating. I felt like I was fighting the type system all the time. (Several of my biggest complaints have been address since I moved on from Swift, to be fair). But some people just love it — and good for them!
For me, Ruby is the closest language to how my brain works. It has the least friction between Idea and Running Code. I hope to write in Ruby (or similar) for the rest of my life.
If I really want a static analyzer for my Ruby, I can try Sorbet. If I desperately need to be running a compiled binary for speed or flexibility, I'll have to choose something else. These are just the tradeoffs.
The world is a big place. I'd want everyone to be able to find a niche where you can write the code you want in the language(s) you want.
> find clear and effective refactor points
> organize code well, etc.
> Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.
It's interesting because, having converted from Python to Haskell, I find a powerful static type system helps tremendously for those three things.
However, on very large Ruby projects I have inherited I do see a common flaw of a large (often insane) amount of exceptions being thrown due to type errors. Undefined method blah on nil class. Some of these apps have had 100s of developers working on them of various skill levels. For mission critical code paths I am often the biggest proponent of Sorbet.
While my personal projects involve heavy use of meta programming and taking advantage of duck typing, I have altered my writing style and opinions for large projects.
Part of my frustration with Ruby type system could be explained by the fact great Ruby developers are becoming pretty hard to come by and I have often had to work with developers who are picking it up.
Watching juniors at work, I find that it takes them less time to complete a task in dynamic languages, but I think they get better results when the language forces them to think a bit harder.
I'm in a bit of a minority on gradual typing. Give me static types or none at all. Python's approach to typing gives me the heebie-jeebies.
I use Go at work but mostly Python for personal projects currently, and am pushing towards Clojure for personal projects in the future. But that’s because personal programming for me is a cathartic escape from the straitjacket of zero abstraction power and the tedium of manual error handling; I care about my own satisfaction more than I care about scalability to a team of varying skill levels in that context.
But with constant attrition, only being able to mostly hire juniors, with the mid/senior hires lacking knowledge of Clojure, there's a risk in doing so with Clojure. If there's half the team familiar and knowledgeable in it it can sustain onboarding, but Pandemic has caused a 90% refresh, so we lost our pipeline for training people to Clojure.
Doing the same with statically typed languages is possible, Java + JSON will get you there for example, but it's a lot more tedious and roundabout, and simply less pleasant. On the other hand, people unfamiliar with a language and generally still with lots to learn about proper abstractions, code structure, meta-models, and dynamism will struggle to ramp-up and produce good code, a catch 22.
I'd happily use Elixir as well, another dynamic language, if I had that option and couldn't use Clojure.
Only when I can't use those would I go back to Java, Kotlin, Scala, C# or C++ (all which I have prior experience with).
With static languages, on the other hand, writing routine things becomes a chore and people end up needing crutches in the form of advanced IDEs to generate boilerplate code that is a pain to read because of templating and such. Of course, error messages when templating/generics becomes involved are just horrible. Without generics you tend to lose a bit of the benefit of statically typed languages.
At the end of the day it's the size of the codebase, team discipline, and an emphasis on simplicity that matters more.
It is my experience, though, that people start out enamored of dynamically typed languages because of their expressivity and high productivity but then end up gravitating towards statically typed languages for large codebases, because they are more willing to trade convenience and coolness for safety and reliability the more senior they are.
(I'm a Rubyist)
With type-hinting etc it’s getting better now, but they’re still a big problem in dynamic languages.
For context, I usually work in <50 size engineering dpts, if not companies. If you're scaling to thousands you can spare the scale, probably.
Then there is the debugging support in Visual Studio Full. Yes, there is debugging in vs code / typescript, but it is far away from how easy it is to debug a C# application in Visual Studio. Too often I have to resort to printf type of debugging to gain insight into which code line was the last line to run before the error.
Yes, I like dynamic languages because some of your things you can do with them are freaking awesome, but at the end of the day I like the comfort feeling that Visual Studio and a static language provides.
I dont know if c# has a future outside of games and big corps. I face palm everytime I see Microsoft launch something open source and cross platform and leave linux out of it and instead say that "the community must create something amazing for linux". If Microsoft starts to build the first version of shiny new thing for linux and launch it at the same time as the launch it for windows, mac, android, then i cam move outside those niches because doing that will create good will
I'm happy to use Python for a lot of stuff. I also use C or C++ for a lot of stuff. It's usually pretty obvious what the right choice is.
Using a more dynamic language for larger projects takes more discipline, and that effort reduces the productivity that is otherwise the hallmark of dynamic typing. There's a point where static typing becomes a net win.
For me, Python's type annotations extend that cross-over point. Both as documentation for humans, and driving IDE or CI-based type checks, I think they've made Python more scalable.
If I've been doing heavy C++ work for a while, switching back to Python is like throwing off a whole lot of bureaucratic overhead: it feels like you can turn ideas into running code almost effortlessly. Going from Python to C++ feels like being super defensive and precise: every single thing is nailed down hard, and has to be just 100% lined up. It's satisfying, gratifying, solid, in a way Python code isn't.
Different projects, different goals, different timescales. Both can be good.
C++ coded like C or like Java will be exactly as miserable as coding C or Java, but that is entirely a matter of choice.
In contrast, Python (and other dynamically-typed languages) avoid all of that.
In addition, the compile-time cost of all this is significant. Cup-of-coffee builds are a definite burden on productivity.
I spent a lot of time in Haskell and the type system is great, the issues I ran were the stuff around it: an ecosystem often missing libraries available in other languages, Haskell solutionism, and working on code bases where Haskell language experts were empowered (not necessarily the best software engineers), which caused the company to re-invent a lot of services we could have just bought.
I really do think Haskell is the world class typed functional programming language, but I'm also not convinced using typed FP is the panacea some claim it to be. Typed FP doesn't make up for bad architecture or poor dev practices, and it's still 100% possible to code your applications into a mess even with outstanding and talented devs.
So right now I like Typescript, JS, the nvim support that took 20 minutes to set up and the incredible amount of libraries and dev tools. I've only been using typescript for a month or two, so maybe my opinion will change...
What's most important also is making sure that you take away and learn from every language you work in and apply those lessons to other languages as well. Type hints on otherwise dynamic languages are a great middle ground.
What static typing offers you though is the ability to refactor large project with much greater ease.
I spend most of my time refactoring a large C# codebase (10m+ loc) while other people are actively working on the code as well.
This just wouldn’t be possible without some kind of static typing. If there is a type that is used in 500 places and you have to update all uses, static typing gives you some form of insurance that you’re not breaking much.
In large constant systems, code is read more times it is written. Documentation is usually worth the pain.
In small, transitory, or experimental systems, documentation may not be worth the additional burden.
I also think that parameter strong typing and splitting code into service helps to design better, more clear messaging between components. Having done that for some time we can train ourselves to always pay attention to it, and it will help up to build larger code bases in a maintainable way. (I think larger code bases are more efficient from “time spent” point of view)
I often see people do same mistake: they trying very hard not to repeat themselves, and the highly reusable functions become very dangerous piece to refactor. I would rather have code copied in different modules, unless it’s very general thing that never change like array sorting or date formatting
Then I started Ruby and was carried away by amazing devx even though missed static typing sometimes.
Then I discovered Typescript.
Typescript has found the perfect balance between flexibility and type checking.
Now i feel literally pain when I have to deal with static languages. It’s like im thrown to jail.
Not to mention terrible devx of the most of them.
So, probably the question should be for people with, explicitly, 20 years' professional experience, if it is to mean anything.
What did I feel during the transition: Feel like an insulted because of the under-expressiveness. Everyday I find some ideas that are natural to me and non-tech people couldn't be codified directly.
Although statically typed languages are getting better each year, I still think there's a trade-off among three camps:
1. Dynamic (Ruby, JavaScript)
2. Under-expressive static (Java, C#)
3. Expressive static (Scala, TypeScript)
I worked on a full-stack project and people have different backgrounds and have to switch from time to time, here's my impression:
- Most "underexpressive-static -> dynamic" people hate dynamic programming, because they mostly lose typing for nothing - they usually don't leverage the expressiveness because that is how they were coding all along.
- Some "dynamic -> underexpressive-static" people liked the discipline, while some hated the under-expressiveness, it depends.
- The "Expressive static" was the new thing. Everybody need to learn some part. Usually, there's a learning curve, some people like the challenge while some people hate it. That also depends on how steep the curve is (TypeScript is very smooth but not Scala).
Even though I think it's still trade-off, I can see the balance is shifting toward the "expressive static" camp:
- People get more familiar when they're exposed to the concepts. Higher-order functions like map/filter/reduce were considered exotic in the 90s, but now they're everywhere. Monadic-like programming like Promise or Optional is also popularized, they're not hard at all once "everybody else" learned that. Advanced type systems are no different.
- Language creators have more experience in choosing trade-offs that makes sense. Scala was getting a bad rap during its day, but Kotlin didn't. In other words, the creators are getting better at spending their "novelty budgets"[0] to yield optimal results.
P.S. I still couldn't wrap my head that Dart spent NO "novelty budget" whatsoever... They have zero chance against TypeScript if there was no Flutter or other Google platforms that use Dart.
https://henrikwarne.com/2014/06/22/switching-from-java-to-py...
(There is probably no choice if your "static language" is Java [0]. But Java is always a choice: you can always quit and go where Java isn't, especially nowadays where everything is remote.)
A powerful static language (i.e. not Java, C, or their analogs) in a well designed system involves no boilerplate and can be a joy to use.
[0] https://blog.plover.com/prog/Java.html : "I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product."
Java is definitely like this and it also emerged in an era of overengineering because microservices weren't a thing. However, I'm willing to bet that Go will soon go this way with generics. Most average programmers do not care about programming with types, type traits and so on, and are simply not equipped to deal with byzantine compiler errors (gcc/clang error messages and warnings about C++ templates were the ugliest things I have ever seen), and this is where the tradeoff is facilitated with pre-written libraries and code generators that take away the need to deal with these things explicitly. They are not going away, and relying on them is not Doing Things Wrong. It's just doing things and getting on with life, period.
As we used to say, "you can code FORTRAN in any language", and code in those languages can be as unpleasant as anywhere. But they don't have to be.
https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
"Byzantine compiler errors" is what I guess you have come to expect from (mis-)use of pre-C++20 templates. But the overwhelming majority of type operations in actually high-level languages like C++ and Haskell cannot result in compiler error messages, and simply perform useful busy-work you therefore need not.
A .net stack comes with the comforting knowledge that this technology will never be made obsolete. It will undergo active development and will have support for many years to come. One day, long into the future, it will be super seeded by something else. When that happens, you know there will be a migration path because Microsoft has based their own business on it, and they need it for themselves, and all of their customers need it. .net does not go away tomorrow because something shinier showed up. That's nice to know.
You will find that you will have a very stable and mature stack that is well integrated with Azure making deployment and testing easy.
Was I to build a microservice application, I would not choose Kubernetes. I would choose the Microsoft Service Fabric Actor model over anything else that is out there.
Service Fabric is Microsoft Secret Sause. It is the technology that underpins the Azure Platform itself. Service Fabric has a beautiful actor model that makes the development of cloud-based applications as simple as writing a single threaded console application.
Service Fabric and Kubernetes: community comparison [1]
The Actor Model [2]
[1] https://docs.microsoft.com/en-us/archive/blogs/azuredev/serv...
So far what's caught my interest is Blazor as a Node.Js replacement. If you have had any experience, what's working with Blazor been like? How do you think it compares to other server-side frameworks like Node, Django, Pyramid, or Spring in terms of performance, feature-set, and maturity?
Having written extensively in several statically typed languages, it was still possible to send messages to nil and end up crashing, or just be lazy and not deal with every possible conditional when parsing incoming data from an API and end up crashing, etc. (I use these examples because these seem to be what people reference the most — perhaps you are referring to something else).
Like, it just does not happen (in my experience, to be fair), that someone is passing a Car into a method expecting a Flower. It's nice that the compiler would flag that for me, but it's just so rare in my experience.
If you are dealing with priority lanes, all of the methods could be written to only accept Carpool types, even if a Carpool struct has the exact same fields as a Car. Then you only need to parse a Car to a Carpool once and never worry about validating the passenger count after that.
Static typing only seems like a verbose straightjacket in the context of verbose languages like Java and Go. In reality it can help you write way less code. I don't expect the world to switch to Haskell, but I am excited by the direction TS is heading. I think "parse don't validate" will become common wisdom eventually.
Also, the crash cases you mention could be avoided elegantly with Option types.
Everything in moderation. TDD is good, but I've watched people write extensive tests before writing a line of code to test, and it often ends badly -- not too badly, they usually just needed to rewrite the tests once they figured out that they had the wrong API (oops, at least one example was a case for DOD, because the API was perfectly obvious from that lens) but sometimes that can trigger multiple refactors along the way. I've seen the same thing happen with documentation-first. I've seen top-down problems and bottom-up problems and code that ships before tests or docs were ever written/validated. In my not-even-remotely humble opinion, people need to be familiar with all the design patterns, and figure out which is best at project inception.
I can't speak for Rust, but in Haskell you can just do something like
f >=> g >=> h
All of this has nothing to do with Go's specific typing discipline or syntax around it, of course. I was just commenting on how the most popular static languages probably aren't the prettiest or most reliable examples of the approach. Plus Go is far more likely to shit the bed at runtime in spite of its typing.