Well, they are wishing to lock you into their ecosystem, so that switching would be a high-friction decision. And then they can simply raise prices without you leaving.
Not anymore they don't (usual caveats apply: no longer work there; big company so YMMV).
It was an option for a while, but getting it to work with the remote filesystems for the monorepo was a bit annoying (e.g. you'd create a new project in IDEA where you'd have to pick what parts of the monorepo you wanted to have in there, but it all happened up front).
I just want to mention that in my personal anecdotal experience, every codebase I have ever worked on, except 1, was underengineered and not overengineered. The last one was just "engineered".
Fairly certain they do something like Anthropic does, they count the acceptance rate or something else that is fairly "optimistic" (my org has a code acceptance rate of 98,5% per the platform dashboard).
So, to clarify, me accepting the suggestion and then correcting it by hand still counts as N LoC accepted.
I'm building a new version control forge around Jujutsu :).
I think GitHub is pretty bad in its UX and I want to build something that is
a) more opinionated than raw git;
b) optimised more around team usage than GitHub is;
c) uses nicer algorithms for diffing, merges;
d) can be scaled slightly better than Git (in the context of entire teams of developers).
Essentially taking a lot of the good ideas already out there and turning it into a coherent product.
My experience has so far been similar to the root commenter - at the stage where you need to have a long cycle with planning it's just slower than doing the writing + theory building on my own.
It's an okay mental energy saver for simpler things, but for me the self review in an actual production code context is much more draining than writing is.
I guess we're seeing the split of people for whom reviewing is easy and writing is difficult and vice versa.
I was really taken in by this premise a while back so I tried building some side projects with server side swift on my windows machine inside WSL.
I really wanted to like it, but the experience was terrible, from the editing side (with vscode) all the way to the performance of existing frameworks (tried both Vapor and grpc-swift-2).
No, but it is a European leader that has ~recently enjoyed that situation, but is no longer in it.
Sorry, but I don't want to spell it out too obviously, for my own privacy.
I understand what you mean, but at this point I don't find it ironic at all. It's been quite similar in my corner of the world, where a leader enjoys great support and visibility externally, but is fairly unpopular internally.
But if you just want a nicely typed interface for your APIs, in my experience gRPC is much more useful, because of all of the other downsides the blog author mentioned.
Not the person you asked, but I hate how it screws up keyboard shortcuts.
It overrode the delete line shortcut with its own inline chat one, for example.
Decided to ditch it for claude code right after that, since I cannot be bothered to go over the entire list of keyboard shortcuts and see what else it overrode/broke.
(Yeah, I'd say your messaging was reasonably clear, but in the context of the whole thread it wasn't obvious whether the poster was putting themselves in that skill bucket.)
I think there's also quite a big spectrum of skill, even when we're talking about compiler optimization and highly skilled software developers. I'd put myself up there, but still I'm no Lars Bak (for whom Google allegedly created an office in Denmark).
Unfortunately, in 95% cases location IS a factor with bigger companies.
I'm in a similar position where I'd like to do something a lot more interesting, but intersection between where the interesting companies have offices and where I'd be willing to live do not really overlap enough justify rooting up my life.
(Unless we're talking about "too good to ignore", that's a different story.)
Not the person you were discussing with, but I have to add that to me the main benefit of using Stubby et al. was exactly the schema that was so nicely searchable.
I currently work in a place where the server-server API clients are generated based on TypeScript API method return types, and it's.. not great. The reality of this situation quickly devolves the types using "extends" from a lot of internal types that are often difficult to reason about.
I know that it's possible for the ProtoBuf types to also push their tendrils quite deep into business code, but my personal experience has been a lot less frustrating with that than the TypeScript return type being generated into an API client.