Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the Java community claiming that Java was the future for programming, and any languages in the future would target the JVM or be phased out. That didn't happen, even though Java did well for itself.
What's really telling is that Java didn't replace C/C++, despite all the hype back then. Those two languages remain widely used.
There is an absolutely enormous amount of Java out there.
That's what is being claimed above, and what some in the Java community were claiming in the 90s. Also, probably some in the Javascript community these days.
But it's never happened. If there was the One True Language to rule them all, then Lisp, C++ or Haskell would have done it by now.
The point with Java is that even though it was targeting the C/C++ crowd specifically, and it became widely popular, did not cause C/C++ to die.
Again, who is claiming this? Can you link me?
If you want to argue with some several post up, please go several posts up. If you want to argue against me, than please do so on the merits of what I said.
The remaining 20% are stuff like device drivers or high performance libraries that are easier to write in C or C++, or legacy MFC applications.
Also if you look at operating systems like Android, Google makes it very explicit that you need a very good reason to down into the NDK dungeons, to the point that the set of allowed libraries only cover the use cases of 3D graphics and bringing native libraries into Android.
Likewise when Android Things was still called Brillo, the plan was to re-write the Android Framework in C++, instead they ended up bringing ART into Brillo.
Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages.
Some people deciding they prefer static typing doesn't constitute some kind of consensus or fact.
I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point you (1) start getting hugely defensive with tests because without close to 100% coverage you just can't know if anything works, and (2) stop making big changes and instead accept that small incremental deployments towards a greater end is the only safe way towards making progress.
I suspect that how much you agree with this statement is strongly correlated to the size of your codebase. I'd be surprised to meet people with codebases on the order of 100k lines or greater that don't largely share this sentiment.
I'll admit, my commercial experience has all been in statically typed languages. But there are a lot of complex, well written pieces of software written using dynamic types. Maybe you don't meet their proponents, but they do exist.
FWIW, I quite like static typing, but I consider it a feature, not a religion.
I like testing as much as the next person and consider it very important, but your tests should be testing business logic rather than whether your syntax is correct. The problem with dynamic languages is that while you're certainly doing the former, you're also doing way too much of the latter. Until you hit runtime, you have no idea whether you misreferenced a variable or invoked a method that doesn't exist, so you end up writing an exaggerated number of tests that are repetitive, slow things down, and end up requiring considerable maintenance.
> (2) is true for pretty much every large statically typed codebase I've worked on.
Yes, incremental deployment is always a good idea, but it's a matter of degree.
Take for example a case where I need to rename a method that's widespread throughout the codebase. In a static language, I wouldn't give this a second thought. If there's a problem my compiler will catch it, and that's the end of the story.
In a dynamic one, this is a dangerous operation: the old method name may still be getting invoked dynamically in a non-obvious way, or another branch may have been merged _after_ I branched but _before_ I deployed that still has an invocation of the old name. Hopefully you have tests on these paths that will reveal the problem, but you might not, and to hedge against that possibility, you have to roll the change out to production carefully and slowly (because even there, it might be some time before some unwitting user inadvertently triggers the bad flow).
https://drive.google.com/file/d/0B0cKsRm-3yprYTR5YTRaRFBfR28...
He said they mostly just test everything at the interfaces. However, it's simplicity also allowed for powerful tools in code generation, refactoring especially, and so on.
So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto all of them, and (2) this is very much my personal opinion.
---
I'd still defend the position though. Every language has merits, but especially for a lot of the older ones, there are so many accumulated problems that it's worth considering newer languages just because they're learned so much for the mistakes of their predecessors. For example, I've been doing Ruby for quite a few years now:
* Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. It buys you a little early productivity, but any honest person with a huge Ruby codebase can tell you that it's a liability.
* The only way to get truly good performance is to write a C extension. The language's whole implementation and performance-sensitive libraries are all C. Contrast this to modern languages where it's an embarrassment if your compiler is _not_ written in the language itself (Rust, Go, Swift, etc.).
* Core build infrastructure (Bundler) and environment management (rbenv) is maintained separately from the language. It works fine, but the reason it's not more core is not because it's better that way, but because the language's original designers didn't realize they'd be necessary, so they had to be developed separately. This has the effect of making the whole toolchain complex and hard for beginners to understand because none of it is integrated.
* The interpreter starts out faster than a compiler, but it breaks down fast. Codebases in the 100,000s of lines or more will take on the order of 10-100 seconds to start up, and the only way to get back to a fast edit-compile-debug loop is through tricks like Zeus. After you resort to that, unreliable runs and weird loading problems become a part of common life.
These aren't small problems. Also, I'm picking on Ruby here, but you could drill into a lot of existing languages and find flaws that are roughly on this level (JS/Python/C++/Erlang are easy, but even fan favorites like Haskell and Scala have pretty serious ones). Newer languages have their problems too, but rarely anything on this sort of existential scale.
We should stop pretending that all languages are equal with their own share of upsides and downsides. Given decades of language building, it would be disappointing if lessons hadn't been learned. Luckily this isn't the case.
In terms of what we write new projects in given a few years, there are other good contenders, but like I said above, I think that Rust has nailed a performance/safety/productivity/ecosystem compromise that's quite a bit above and beyond most of anything else.