Yea, you're probably right. I meant more stylistically, in that python lets you export functions from files, and it's style of OOP feels way more basic and bolted on than ruby, which gives you lots of different ways to do OOP and throw state around (classes, modules, etc).
The original wired piece is effectively a lot of words that swirl around one poorly argued point: ruby is falling behind because of it's lack of static typing support. "Seriousness" is an ironically unserious way to evaluate, well, anything, but if you were trying to force a definition based on the rest of the poorly formed narrative, it must be "static typing". Performance doesn't work as serious critique, because...python, and it probably shouldn't anyway (within some semi-reasonable range).
Except for static typing and ruby's particular style of metaprogramming (one could argue python enables decorator-based "meta" programming, but whatever), ruby and python are basically the same language, with some obvious semantic differences. Of course there is much about ruby and python that is very different -- adoption, library support, community, vibe, whatever. And you could say that python is at it's core functional with OOP layered on top, while ruby is the opposite, it's all sort of irrelevant, they are basically the same, in the fundamental daily experience of using the two languages, in that ruby/python and go (or java, or elixir, whatever) are very much NOT the same. Minus static typing support.
I'm optimistic ruby will figure this out soon, because the sort of static typing support that has propelled javascript and python is the kind that ruby can and should support. By that I mean neither really have static types. Typescript is another language that compiles to javascript, and python's typing support remains and probably always will be optional, and like javascript, is enabled by external tools (mypy, pyright, etc). Neither python nor javascript have a type-centric/aware runtime, or even one in which types are considered at all. They are still both very much dynamic languages that basically have nice developer tooling to help developers write "type-safe" code, but really, in production, we're just pretending that the types we work with in development exist at all in the runtime.
This is not so much a critique of the approach, but the mass pretending we do when we critique a language like ruby for "not having types" and praising javascript or python for "having types" which they clearly do not. But the approach is good, at least if you agree that optional typing is better than java/go style static typing.
I don't know what's holding ruby back from better supporting optional typing, but i hope they fix it soon. My sense is, to over-simplify, sorbet got too popular, but it's fundamentally an approach you would take if you had to build a type system around the language rather than in the language.
> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:
- Wander around the filesystem
- Edit arbitrary files
- Launch its own shell PTY processes
- Persist itself
When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.
I hate to break this to you, but typescript ain't type-safe. There's a lot I like about typescript, but your runtime is still node, so any "type-safety" is mostly illusory. Not to mention every typescript codebase I've ever looked at includes a copious amount of Any, so...there's that.
Also, typescript has OOP support for a reason -- lots of typescript codebases make copious use of classes. Javascript tried to remain mostly functional for a long time, and people kept trying to make class-based OOP, so, they added it.
Finally, React is not a full-stack framework -- it's a framework for generating UIs. It has recently added support for server-side rendering, and NextJS has added support for that, but Rails and NextJS are very different. Rails is batteries included, NextJS is bring your own [everything] that happens on the server.
YMMV/to each their own/etc etc etc, but referring Rails as "fundamentally unserious" (github, stripe, shopify, i could go on) reflects the opinion of someone who either has an axe to grind with ruby/rails, or is willfully ignorant of it's capability.
Will echo what many have said here already, but with a slight twist:
1. Anti-trust activity takes a HUGE portion of the liquidity that does M&A out of the market. That has a dynamic effect -- other players who are not under direct anti-trust scrutiny think twice about their potential M&A activity. This, in theory, should reduce M&A prices (reduction in supply supply), but this is probably largely offset by point 2.
2. Inflated valuations from 2021 era. Lots of companies raised ridiculous late stage rounds around this period. Then interest rates rose. Now your company that raised on 100x ARR is worth a lot less than it was. But the company still has to grow into and beat it's last valuation. Combined with the M&A dynamics, it's much harder to justify a post-money above what your last raise was if that raise was a post-covid valuation, unless the business is just truly on ripping (e.g. Wiz).
Important distinction: this is for a growth fund ("mature companies" in the article). Growth funds are typically fund dedicated to either later stage financings or follow ons from earlier stage rounds that the firm invested in. Growth funds are heavily reliant on an active M&A market, or companies that are likely to IPO. M&A is effectively dead right now, and many late stage companies have valuations that are too high to IPO without taking a big valuation haircut.