The most important metric for Startups is time to market, developer productivity, fast iteration times and developer ecosystem which is why most startups (and many of the most popular websites) still use dynamic languages today.
Once their core feature-set is established and they've developed the product they want they can go back and optimize accordingly and rewrite parts of their code-base to use the most appropriate language, e.g. rewriting hot spots in C/C++/Rust/Go, highly concurrent features in Erlang/Go, etc. If code-maintenance becomes problematic they can explore annotating their code-base with Types, adopt linters or even rewrite into a statically-typed language. None of this is a mistake, languages/technologies are a tool to achieve your business objectives, if adopting a dynamic language lets you get an MVP quicker and add/change features based on Customer feedback quicker, then that's likely the best choice.
End users don't care what language servers are written in and it's definitely not a mistake to start with a dynamic language, even today.
Of course if you feel most productive with a statically-typed language that's a fine option as well which may result in less technical debt/rewrites later at the cost of initial velocity upfront.
I believe that we tend to get causality wrong on this one. I don't think dynamic languages have some intrinsic property that makes us more productive or facilitate faster time to market.
Rather, I believe that people who are concerned about the soundness, consistency and maintainability of their code, and hence favor powerful static type systems, are incapable of prioritising time to market.
Statically typed languages increase productivity by catching errors early, but decrease productivity by making users jump through hoops.
e.g. at one end of the spectrum is Java, which everything has to be a class. Even if you want to write a function, it has to be expressed as a static method in a class. In Java it's just not possible to implement ideas in the most obvious way, it has to be done in the Java way.
Conversely, TypeScript was designed to work with JavaScript (which is very dynamic), so it has a very capable structural type system. The productivity penalty is negligible.
What I love about TS is that it's up to me how much effort I want to put into the type system. I find that I end up using TS even for very small projects, because I can use it for only 'the important' bits.
That said, my background is mostly Ruby/Python/JS/PHP, so for all I know this is true of many statically typed languages (but from what I read this is not the case).
Still, for those with a background similar to mine I can highly recommend TS as a great starting point for more statically-typed code, precisely because it's opt-in if you want it to be.
End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws.
Now there is no guarantee that a dynamic language will have those issues more than a static language, but I for one sleep better at night knowing my compiler is doing so much more work for me.
> End users absolutely care when the program or service is slow
A Ruby API with a good caching strategy is faster than a C/C++ binary with none and it's much easier to implement sophisticated caching strategies in dynamic languages.
> unstable, drains your battery, is constantly offline
Servers don't drain battery. Unstable, constantly offline has no correlation and is not limited to dynamic languages
> but I for one sleep better at night knowing my compiler is doing so much more work for me.
Right, choose whatever helps you sleep at night, but your language/tech choices isn't always what helps everyone else sleep.
A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline.
Servers don't drain battery, but they cost money, so inefficiency matters server-side as well.
And comparing a fully-featured dynamic language implementation with a less-featured implementation in a fairly weak statically typed language isn't really a productive comparison, is it.
No bad developers create unstable software that's slow and offline all the time, not dynamic languages. The largest Internet sites were built on dynamic languages, they wouldn't have achieved their market position if they were slow, unstable or offline all the time - it's amateur hour to think it has any correlation with being implemented in a dynamic language.
Again a good caching strategy makes every language fast and in the law of large numbers scalability is more important that script execution performance. Servers of failed Startups also consume less energy then successful ones - another great example for spending precious dev cycles optimizing on the wrong thing.
Mose developers are average developers. If I have an average developer writing my mvp or adding user-defined features, I'd rather have a static type system to save them time. Otherwise they have to write more tests or fly by the seat of their pants, which may lead to all the issues I raised.
Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies. And plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve.
Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software.
And if you get to that point, where time is no longer a factor, then choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
Your preferences helps you, other developers have their own language and tooling preferences they choose to help make them more productive.
> Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies.
Talented resources is usually an ingredient that's shared amongst most successful companies and there is no shortage of talented developers preferring dynamic languages. Dynamic languages like python are also extremely popular in complicated fields like science, AI and machine learning, etc.
> And plenty of those companies had plenty of scaling issues and growing
Inefficient software can be written in any language and scaling issues are more often the result of poor architecture and unoptimal implementation than language performance. A successful company with growing pains is also more valuable than a failed company without.
> Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software.
That's incredibly naive. Developer iteration times are much faster in dynamic languages, tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity and are commonly born from dynamic languages. A rich developer ecosystem is also an important factor in being able to quickly adopt well-written tested and hardened libraries which popular dynamic languages have aplenty which is a direct result of being able to attract a large pool of talented developers, languages that can do this are more popular than ones that don't, irrespective of their type systems.
> other developers have their own language and tooling preferences
Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.
> there is no shortage of talented developers preferring dynamic languages
There is also no shortage of talented developers preferring static languages. And given the two, I know which developer I prefer. Especially since I've never worked with an infallible developer, even in the upper echelons.
> Developer iteration times are much faster in dynamic languages
I disagree, I find I'm about as productive in either, but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.
> tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity
> Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.
I've not once mentioned my preference. My preference and where I spend the majority of my time developing server libraries and Services C# which I consider the most well-balanced modern statically-typed language available.
But I'm not naive enough to think everyone would be better off developing in C#, most startups prefer dynamic languages with good reasons stemming from being quicker to market, faster iteration times, more malleable in implementing customer requirements and having a rich pool of talented resources available. There are a lot of smart people sharing the same opinion, like Alan Kay:
> If you’re using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you’ve already done. You can’t reformulate things that easily.
Smalltalk was first released 45 years ago and it still has live programming features like being able to re-program its IDE while it's running that I've never seen any static language been able to do. There's a whole class of software I can't imagine being built in a static language, like Wordpress rich extensibility and plugin ecosystem, I've implemented a few Wordpress sites and custom plugins which would've taken an inordinate amount of time in a statically typed language. I've spent a few years developing PHP and I very much dislike PHP based on its language merits, but I have an appreciation of what it's been able to be built with it.
There are other classes of software that are extremely hard to implement in a statically typed language like React which IMO is revolutionary in developing complex UIs.
I also think it's infeasible for tools like Webpack to have been written in a typed language, where its able to import any kind of asset in the source files that use them, being able to easily chain loaders together, running incremental watched builds that transpile source code, generate source maps, inline images, cache-breakers, etc. Webpack's Hot reloading feature would also take significantly more effort to develop in a statically-typed language. Tools like this are born from dynamic languages because it's simply much easier to do which would've taken significantly more effort in a statically-typed language.
I also develop and maintain http://techstacks.io (Server in C#, not that it matters) and see the amazing number of successful products being built with dynamic languages, not in-spite of them. From what I've seen a large majority of successful SV startups use dynamic languages.
Languages and technology should be a tool to achieve your objectives, many technology choices involves trade-offs, dismissing and throwing shade on successful companies usage of dynamic languages prevents you from seeing the benefits they have in using them, what advantages they have and which scenarios where they'd offer the most compelling value. The reason why many amazing software and talented engineers use dynamic languages isn't because they don't know statically-typed languages exist - it's a mistake to write-off other people's choices because they don't share your same views.
That's fine, no one was talking about you specifically.
> I'm not naive enough to think everyone would be better off developing in C#
That's good. Neither am I, so I'm not sure why it is being mentioned.
> There are a lot of smart people sharing the same opinion, like Alan Kay
Smart people also have the opposite opinion. It doesn't mean anything; that part is all subjective.
> There's a whole class of software I can't imagine being built in a static language
A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.
> There are other classes of software that are extremely hard to implement in a statically typed language like React
Define "extremely hard". Would you consider Elm "extremely hard", for example? And why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.
> throwing shade on successful companies usage of dynamic languages
All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.
I have no qualms about which companies use which programming languages, as long as the result is a quality product from my (the user's) point of view.
If they get that quality through dynamic languages, good for them. I think they worked harder than they should have, and I think they are spending more money on server infrastructure than necessary, but that's their choice.
But I don't believe for a second that the quality, performance, or the end user experience was improved because a dynamic language was chosen. And this discussion (at least, where I chimed in) was precisely the point where the end user experience was called into question.
> A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.
In almost all cases runtime "holes" in static type languages provides a sub par development experience that's worse than both dynamic and static typing, it's definitely not a strategy for developing the same class of software on and it's not comparable to using a first class dynamically typed language. The places where it works is in static type systems are used to annotate a dynamic runtime like TypeScript, Hack and (less so) Dart.
> All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.
Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.
> why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.
It doesn't exist because it's simpler, requires significantly less effort and is more naturally suitable to implement in a dynamic language. In these classes of software choosing a static language is the wrong choice that will always yield inferior results due to their lack of dynamic capabilities and interested resources who naturally gravitate around dynamic language ecosystem. No doubt many devs will still try using their preferred static language but they will all fail to achieve anywhere near the level of success, featureset and penetration of equivalent dynamic language implementations.
Of course as it's software, given enough resources anything is possible, like Apple is able to do with Swift Playgrounds but they're in the unique position of being able to change Swift's language and runtime to introduce the capabilities needed to make Swift Playgrounds feasible - which is major strategic project for Apple which I still hold would require significantly less effort using a dynamic language. Google has the same benefits with what they're able to do with Dart where their flutter project offers a compelling live programming experience for developing native mobile Apps. Both would be considerably harder if they weren't able to change the language and runtime to make it easier for them, e.g. snapshots would be nigh impossible without language/runtime support.
Likewise their exists classes of performance and mission critical software that's not suitable for dynamic languages, but it's not always a mistake to start with a dynamic language first to prototype quickly then rewrite once the system requirements have been identified and solidified.
> Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.
What I suggested, if you go back and read my initial comment, was that static type systems give you a higher chance of improving performance, efficiency, and quality. I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.
And there's plenty of basis in reality.
> It doesn't exist
It does exist.
> requires significantly less effort and is more naturally suitable to implement in a dynamic language
Maybe since dynamic languages are popular. I'm not convinced that dynamic typing made this easier, or if it just so happens that most people know dynamically-typed languages.
But that's beside the point completely.
The point was pretty simple (I thought...): Quality is visible to the end user, and all other things being equal, a static type system has a higher chance of resulting in quality software.
Now in the real world, of course, all other things aren't equal (otherwise everyone would just use statically typed languages). But choosing a dynamically typed language for those other reasons (your developers are more familiar with it, it has more libraries that you need) should be a conscious choice made knowing full well that you are opening your self up to a class of errors that you could have automatically avoided. If that trade-off is worth it to you (it is worth it to many) so be it. But the trade-off is still there, and when it does cause quality issues, users will notice.
I'm not saying using a dynamic language is a mistake and I'm not saying using a dynamic language guarantees the quality of the result will be lower (nor am I saying a static language guarantees the quality will be higher, although I believe it helps a lot), so arguing against those points is falling on deaf ears.
I've provided a number of examples, you've provided exactly none.
> I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.
Your comments are full of snide comments against dynamic languages:
> That does correlate with being unstable and offline.
> plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve
> choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
> You either have to write more unit tests, or pray, or be infallible.
> but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.
> and all other things being equal, a static type system has a higher chance of resulting in quality software.
Which is categorically False. Software quality refers to how well it adheres to its fitness of purpose and how it competes with competing alternatives.
Users generally prefer to use software which are easier to use and provides them the most value where by being able to iterate
quickly holds the most value, which is arguably an inherent benefit in dynamic languages and why they're a popular choice amongst startups. Especially when you're competing in a new market category, velocity is of utmost importance.
In fact almost all successful companies that I can think of that were competing in a new software category were developed using dynamic languages including: Facebook, YouTube, Instagram, Spotify, Dropbox, GitHub, Pintrest, Reddit, AirBnB, Uber, Slack, Khan Academy, Coursera, Twitch, Hulu, Kick Starter, Patreon, Trello, etc. Results are overwhelmingly in favor of building new products in a dynamic language. I struggle to think of any recent successful Startups that were able to out compete their competitors and achieved their dominance starting out with a static language. The major ones I can think of predominantly built with typed languages are: LinkedIn (2002), Netflix (1997), Ebay (1995), Amazon (1994). The most recent one I can think of is Stack Exchange (2009) (which I know of because I used to work there :). Of course once they've established market dominance and implemented their core feature-set many go back and focus on optimizing their system of which many identify and rewrite hotspots in more appropriate languages. Which remains a strong case for starting out with a dynamic language first.
> But the trade-off is still there, and when it does cause quality issues, users will notice.
There's a trade-off on whether adopting a static language is worth it, of which most successful SV Startups don't agree with - and their users are better off for it.
> Your comments are full of snide comments against dynamic languages
They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.
Half or more of the things you quoted aren't even about dynamic languages, and the other half are true (or do you care to refute them? For example, if you don't write tests to take the place of static typing, and you aren't praying, then you are either infallible (ha!) or you are lying).
> Which is categorically False
Believe what you want; it's clear you aren't interested in opening your eyes. So be it!
And that big list of companies has nothing to do with the discussion. Of course they use dynamic languages. Almost everyone does, because they are popular and because some tasks seem easier in them. But there are still quality issues that could have been prevented.
> They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.
> Believe what you want; it's clear you aren't interested in opening your eyes. So be it!
You forgot "Calling the Kettle Black". But I'm more than comfortable with my experience with multiple languages in each style enough to be able to identify their strengths and weaknesses and which scenarios each are better suited to, of which I've listed several examples which are better suited to dynamic languages. Likewise there are many that are not.
> if you don't write tests to take the place of static typing
Tests are essential to software quality and static typing does not absolve you from writing tests. Static Typing enforces Type correctness, it does not enforce program correctness.
> And that big list of companies has nothing to do with the discussion.
It has everything to do with which language yields the most benefits and whether Startups have made a mistake in adopting them, I posit they haven't and Empirical evidence suggests that they're a more suitable choice for Startups.
> Of course they use dynamic languages.
Of course.
> Almost everyone does,
Ok.
> because they are popular and because some tasks seem easier in them.
It's because they provide more value than not.
> But there are still quality issues that could have been prevented.
For which they often provide more benefits then they give up, which is entirely the point, that adopting dynamic languages is not a mistake.
My proposition was that dynamic languages offer better velocity which lets you get to market quicker. Static Typing helps with type correctness and maintenance of large code-bases and it's a perfectly fine strategy to rapidly prototype with a dynamic language first then rewrite identified hotspots and problem areas in a more appropriate language. Script execution performance is often not the bottleneck, a good caching strategy can make any language fast, areas which don't benefit from caching, i.e. high writes / high concurrency would benefit from a rewrite and in a growing user-base, scalability is more important than script execution performance.
> Tests are essential to software quality and static typing does not absolve you from writing tests.
No one said they did. You have to write fewer tests with static typing, not zero tests.
> My proposition was that dynamic languages offer better velocity which lets you get to market quicker
Velocity is subjective - perhaps for the developers in question dynamic languages are quicker to market, but I argue that is more because of familiarity and popularity, and less because of dynamic typing.
For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing, and in the long run they don't need to rewrite or chase typing bugs or spend more money on scaling inefficient software.
> No one said they did. You have to write fewer tests with static typing, not zero tests.
Typing is not a substitute for tests, you test for desired functionality in both. Albeit there's a stronger culture for testing in dynamic languages given they're more of a necessity.
> Velocity is subjective
No, Velocity can be measured.
> but I argue that is more because of familiarity and popularity, and less because of dynamic typing.
That's no argument, it's a weak and sheltered assumption showing a lack of first-hand experience. Don't presume to know that of which you don't know.
> For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing,
Of course you can't know that for sure, but it sure fits your thwarted view of them quite nicely. If that were true most Startups whose existence are hinged on their ability to get to market would not be overwhelmingly be in favor of using dynamic languages. Your goals as a technologist should be to adopt an unbiased view, identify strengths and weaknesses of each tool so you're able to make informed decisions about which use-cases are best solved by either. Your unknowledgeable and disparaging remarks on them wreaks that you're more interested in trying to confirm your own biases than you are on from ever being able to benefit from them in any capacity. Learning the idioms and being proficient in multiple languages will make you a better programmer, you'll learn elegant techniques, new perspectives and be able to identify friction that you can apply back in your primary language. You'll also be more productive in the large number of use-cases where they're naturally better suited. Add one to your toolbox today!
> in dynamic languages given they're more of a necessity
Sounds like you came around.
> No
Not everyone agrees that dynamic languages lead to faster velocity. Velocity is a function of many things (environment, culture, tooling, existing code bases, developer skill and familiarity with a language, how low you set your quality bar for your mvp, etc) and as I mentioned a few times now, different developers have a better velocity when working in statically typed languages.
"Improved velocity" is not an inherent property of dynamic languages, it depends on many other factors as well. I'm not sure why you keep ignoring that point (well I have an idea why...)
> it's a weak and sheltered assumption showing a lack of first-hand experience
It's not an assumption, it's an observation that I think extends beyond my direct experience.
I've trained many developers who were huge dynamic language proponents much in the way you are right now: any mention of an advantage found in a static type system sent them off into vague or straw-man arguments about how productive they found themselves in their dynamic languages, how flexible it made them, and how handcuffed they thought they'd be if they tried a statically-typed language.
In reality, they had never taken the time to learn any of the decent statically-typed languages, and when I probe as to why, the reason is usually because it takes more effort and because those languages aren't as popular (and sometimes a fear of the unknown).
Once they get up to speed, they find themselves just as productive, writing fewer tests, and producing higher quality software.
Of course it helps that the culture around me fosters that kind of thing: we write or provide tooling, and we have the senior developer resources to help other developers where a quick stack overflow answer won't solve their immediate problem, but as I said a few times now, those points are all orthogonal to mine.
> [Long string of ad hominem remarks]
I'm not sure why you think you know me, my experience, or what I'm proficient in, but you are mistaken (and if you had read the comments you replied to more carefully you might have realized that).
Since that's not a productive way to discuss a topic, I'll leave things here. If you wish to change the way you converse, I may be back, but it's unlikely.
I wanted to leave it, but it's full of misguided assumptions, so I'll keep try it short.
> Sounds like you came around.
No my experience hasn't changed, I've delivered solutions in multiple languages (with a majority of them in static languages) and am familiar with realities and cultures in each. I'm a proponent of technology and adopting the best language/tool for each use-case. I could list all the areas where dynamic > static and vice-versa but you're not interested in learning where they provide the most value so I wont bother. Using a single language/tool for everything is an inefficient use of developer resources. When I started out I also used to hold an affinity to my preferred language, but that eroded over time as I became aware of where my preferred language and ecosystem deficiencies and where their strengths lie, my primary concern is adopting the best technology that creates the most value with the least time and effort where I regularly use and explore different languages and frameworks to gain experience in them so I can identify their strengths, techniques, approaches and which areas they excel at.
> Not everyone agrees that dynamic languages lead to faster velocity.
An overwhelming majority of successful Startups do, you've yet to show any evidence suggesting otherwise, just biased hearsay. The most valuable Internet properties and successful startups are built on dynamic languages so your disparaging remarks suggesting they're "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is a completely false straw-man that amateurs would say - those are not a function of language or in anyway represent the value created or talented engineers using them. If you actually believe this, it shows you don't have any first-hand knowledge or experience using them so I can only assume your remarks are used to reaffirm your own technology confirmation biases, either way that's how it comes across when delivered as a baseless slur. Personally I would've liked to see some examples and empirical evidence backing up your theories, because as it stands none of them hold any water.
You continue to argue against points that were never made and you claim my position is something which it is not. At this point I have to assume you are doing it intentionally, but either way, I'm not interested in being misrepresented constantly.
Once their core feature-set is established and they've developed the product they want they can go back and optimize accordingly and rewrite parts of their code-base to use the most appropriate language, e.g. rewriting hot spots in C/C++/Rust/Go, highly concurrent features in Erlang/Go, etc. If code-maintenance becomes problematic they can explore annotating their code-base with Types, adopt linters or even rewrite into a statically-typed language. None of this is a mistake, languages/technologies are a tool to achieve your business objectives, if adopting a dynamic language lets you get an MVP quicker and add/change features based on Customer feedback quicker, then that's likely the best choice.
End users don't care what language servers are written in and it's definitely not a mistake to start with a dynamic language, even today.
Of course if you feel most productive with a statically-typed language that's a fine option as well which may result in less technical debt/rewrites later at the cost of initial velocity upfront.