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.
I'd focus on the back part. Why was programming joyful then? Why is it not now?
Maybe it's the environment? The language? The community?
I think certain people's brains work better with different languages. Often there's an overlap with community. I started my career in ruby, and still write it as much as I can, though these days, not usually for "work". I love writing it, and it's creator wrote it to be loved when you're writing it. Even though python shares a lot of similarity with Ruby, I find it frustrating in a lot of the little details and design decisions, and I just don't enjoy writing it like I enjoy writing Ruby.
I don't particularly enjoy writing javascript, but I've always enjoyed writing Swift. I also enjoy go, though find some of it's design decisions on the margins perplexing, pedantic and annoying.
Experiment with different languages. Find something you understand, that your brain doesn't have to fight with.
Also, get a hobby that has absolutely nothing to do with computers. Do something tactile -- baking, carpentry, fixing things. The raw difficulty of manipulating things in the real world is both deeply satisfying, and gives me a deeper appreciation for the ease and elegance of manipulating computers with software.
Their event pricing would require you to log something on the order of tens of millions of events to get at a 10k monthly bill. If you were turning it on in a high-volume environment, how did you unexpectedly run up a 10k bill after doing the math in half a day? Something about this doesn't add up.
Lots of experience with Fly's paid support here. tl;dr Absurdly good.
FAR better wrt both response times and technical expertise than you'll get with any large public cloud provider.
I was dealing with some annoying cert + app migration stuff (migrating most of an app from AWS to Fly), and Kurt (CEO) was personally sending me haproxy configs bc I'm not smart enough to know how to configure low-level tcp stuff in haproxy. Not to put him on the spot here -- I doubt he'll have time to do that level of support going forward -- but that's my experience of the company's dedication to support and technical expertise.
Complaining about companies raising venture capital on hacker news! What!? No way!?
This is going to sound wild, but believe it or not it takes quite a bit of capital to reserve capacity in data centers ALL OVER THE WORLD in order to, like, deliver on your core value prop of enabling deploying normal apps AT THE EDGE. This used to just be called making a capital investment (because it takes a lot of upfront capital), but then it became en vogue to whine about venture capital.
You may want your hosting provider to be capital poor and running a razor thin balance sheet on the brink of insolvency (aka bootstrapped) but I don't. Or you might want to lease your own space in a colo and rack your own servers and hire your own remote hands and your own sysadmins and dev ops with 24/7 coverage so if you have a hardware failure you can deal with it asap but I don't. Not having to do all that shit takes...capital.
Where would you have them fetch said necessary capital if not from venture capital firms?
Honestly, do you even know what you're bitching about? A theoretical monopolistic reality that a. does not exist and b. would not exist if fly did not theoretically create a product so good it made all their competitors irrelevant (note: this is not a monopoly, it's market dominance; they are very different)?
And honestly, if they're still around in 5 years, they probably should raise prices so they can continue to be around. Fly is literally orders of magnitude cheaper than running on AWS, and orders of magnitude easier.
If CEOs were as replaceable and disconnected from the outcome of a business as the author suggests, boards would've started doing this long ago and CEO salaries would come down as a result (lots of people want to be CEOs, and by this author's logic, virtually anyone can do it). This is so disconnected from reality it reads like satire.
The fact that other countries have defaulted and the US never has is one of the key reasons why US govt bonds are considered "riskless", and contributes hugely to reserve currency status. Which is to say, market actors use it for lots of stuff they don't even think twice about b/c there is an implicit assumption that the US will never default on it's obligations.