It's funny how we hear so much about Ruby's decline yet 3 of the highest-valued startups - Stripe, Shopify and AirBnB - are up there making fortunes with it whilst contributing to Ruby's vibrant ecosystem.
Must be recent decision. I was at Stripe last year. They have a ton of Ruby. They were full throttle investing in Ruby.
And yes, Sorbet is magical. They’ve taken good ideas from typesystems such as Typescript including the tooling for code completion, inference and refactoring.
Sorbet truly brought joy to my lift.
Although Ruby is way too dynamic for my liking. Many ways you can shoot yourself with it.
I upvoted you only to get attention. You will need reference for this.
>But nearly all of Stripe’s codebase is implemented in Ruby running on the default Ruby VM (YARV). Not only did we not need Java VM-level interoperability, choosing either alternative Ruby implementation would have made for a difficult migration path.
Not at Stripe, but I guess it was picked as a compromise between efficiency and developer productivity. Dynamic languages like Ruby and Python don't perform well in the first area, native languages like C++ not much in the latter. Rust might be better, but it's still harder to learn than Java and there's less experienced developers to hire. That tradeoff usually leads companies to pick one of Java, C# or Go.
Maybe Java includes the possibility to use Kotlin? At many teams I know its up to the team to write parts of Java libraries or services within Kotlin since it's mostly an implementation detail. But again - I'm not part of Stripe so I can't talk for them.
In my experience it's usually JVM at these companies, not specifically Java, and certainly in recent years more and more teams use Kotlin for backend services.
Anecdotally, TypeScript seems very popular among startups today. And for good reason - between Node.js servers, ReactNative mobile apps and React web apps, you can build everything in a single language. A language that’s naturally very productive while getting a product off the ground, pretty maintainable over time, with good enough performance (and concurrency support) for most use cases.
Agreed that PHP was the #1 startup language in the Facebook era, then Ruby in the GitHub era, and I think TypeScript now. But while they’re all very productive “early days” languages, TS stays much more productive over time.
Go, Java and Python are all popular startup choices too, but I think TS is the top startup choice right now, and a great choice at that.
Yeah, Typescript is a complete no-brainer as a pick - even if you're only picking a backend language. The type system is better than anything this side of Haskell, while still letting you write boring imperative code without getting in your way for every little thing if you just need to pipe some data around.
Performance is really not an issue unless you're doing very CPU-intensive work which you can't offload to a native library for some reason, or you need to scale vertically rather than horizontally (which is even rarer). Compute cost only really starts being a worthwhile optimization target at the "hundreds of billions of requests per day" level, and even then you're not gonna see much of an improvement from moving to Java unless you're actually very good at tuning threadpools (and it might still not be enough of a win compared to whatever else your developers could be doing with that time).
Rust's type system is also better than Typescript, and I would say Dart is slightly better too. But I agree Typescript is very very good, and you get access to such an enormous ecosystem it's worth it in most cases, and it's only a few times slower than C++/Rust. Not 50 times like Python or Ruby.
I'll grant that Rust could make a solid argument for itself with traits and such (though I haven't had a chance to use it myself). What's the five-second rundown on Dart's type system being better than Typescript's? I take a look every couple years and back in the day I remember thinking it was a solid alternative to C#/Java simply for its better null handling but Typescript solved that problem and many others besides.
I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue.
That's not an issue if you code properly. Most statically typed languages only have run-time type information as a sort of "ok fine if you're desperate you can use it, but please don't" feature.
Exceptions are a special exception in Typescript because they can come from pretty much anywhere so it can't realistically know the type at compile time.
For everything else you are probably want discrimination unions.
Yeah, for your own code it’s not really an issue, as long as you’ve got decent team-wide discipline. But when integrating with external libraries, especially JS ones with type definitions tacked on later, it can be an annoyance.
Yeah, the story for handling thrown errors is much worse than it is in Java, and arguably worse than e.g. C#. But it's not a total loss:
1) 99.9%+ of the time, it'll be an instance of `Error` or some child class.
2) There's a recent compiler flag that's been added which defaults caught errors to `unknown` rather than `any`.
3) You still have access to the same tools to inspect unknown errors as you do everything else - `instanceof`, checking the presence/absence of properties, etc.
It's not great but it's something.
I would actually say the propensity of libraries to use exceptions as control flow and then _fail to document anything about those totally expected outcomes_ is a much bigger headache; that truly is an artifact of its JS inheritance.
I'm not sure how this applies to those languages. Ruby has an actual ecosystem via gems, and has a pretty nice syntax and language features so it's not hard to pick up. Pretty modern feeling even on older language versions. I think most of why it lost popularity is because faster ergonomic solutions have appeared, and python is a more popular competitor for dynamic backend langs (mainly due to ecosystem size).
COBOL, PHP, and FORTRAN all lack modern ecosystems (package managers, etc) which hinder them significantly.
COBOL is dead for new development because it has horrible ergonomics compared to modern languages. There's a reason why companies will pay big bucks if you're willing to maintain old COBOL with nearly no qualifications.
PHP is still widely used, but it's also got some language quirks and was mainly aimed at backend work. Since most web dev tries to offload onto the user instead of the server now, it's disappearing for both reasons.
FORTRAN is still widely used in academic research and the modern language version (f90+) is actually pretty nice to work in imo. It's a decent competitor to C/C++ and the compilers are nuts for scaling which is why it sticks around for scientific work. It's practically free to move from single node to a full cluster workload using only compiler flags.
>COBOL, PHP, and FORTRAN all lack modern ecosystems (package managers, etc) which hinder them significantly.
I think your PHP info is wrong, PHP has a package manager named composer. So if you need to connect to amazon S3 amazon published a package (that does't depend on 100 leftpads)
https://packagist.org/packages/aws/aws-sdk-php
Maybe is not modern enoug in your opinion? Then what is missing except lefpad and color-red ?
> COBOL, PHP, and FORTRAN all lack modern ecosystems (package managers, etc) which hinder them significantly.
Its unfortunate that PHP has been clubbed with COBOL :-).
You may not be aware but PHP has a great package manager called composer. It is intensively used in the PHP community for a long time now. The packages are available at https://packagist.org/ .
Packagist houses 300,000+ packages and has received 50 Billion package downloads since 2012 (See https://packagist.org/statistics ). PHP's Packagist would actually would easily rank amongst the biggest package management ecosystems among programming languages.
PHP is certainly not disappearing. While it is no longer as dominant as it used to be and there is a slow, long term decline, it continues to be very active. Ruby's decline actually is sharper than PHP. Here is an interesting resource https://redmonk.com/rstephens/2021/08/05/top-20-june-2021/ . All statistics need to be taken into perspective but if you look at other proxy activity like GitHub PRs, projects, jobs etc. for PHP, it continues to be very strong. Using the word "disappearing" feels wrong to me. Trends are not irreversible. Over the years, languages have gone down, only to come back up.
P.S. Fortran is still going strong also. It is still used extensively in the Scientific Computing community. While, I'm not familiar with the ecosystem there are package managers in Fortran too. I'm not familiar with how good or popular they are though.
Of course it will come back, you just need to wait until dynamic typing becomes fashionable again. Development time is still more important than operational speed.
I very much doubt dynamic typing will ever come back, it's a thing of the past now. No sane new project will ever start in a dynamically typed language.
Modern statically typed languages do everything that dynamic languages do and a lot more.
I don't know about go (some cursory googling reveals a few open source projects, but nothing concrete) but you might be mistaking their work on Android libs for moving their backends to the JVM. For reference, their style guides are for JS and Ruby only so far.
