Degorath

The IDE experience on Linux doesn't make it any better either.

Oh how I wish I could have a working Swift :(.

My guy, obviously I tell the person they're pulling a dick move first.

We're not talking some entry level staffers here, it's senior engineer FTEs who are employed at a tech company who are doing this.

I've decided to fight it the same way I fight tactical tornadoes - by leaving those people negative reviews at mid-year review.

(I also find the people who simply paste LLM output to you in chat are the much bigger evil)

(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.

Living in a place is quite a bit different to travelling there.

I really _want_ to like Swift, but the development experience was so abysmal that it turned me off the language entirely.

I have been entertaining the thought of writing an LLVM frontend for Gleam, though. (I don't know what I'm doing, I don't know if this is doable, etc.)

I agree with the OP that it sort of is. Moving around in the EU is a lot more difficult than moving around the US, so a lot of great talent just doesn't want to.

In my opinion they need to invest a lot more time and money into it for that. The development experience on VSCode was pretty bad (I think the LSP has a memory leak), and some important (for me) libraries aren't tuned very well yet (a Vapor webserver can sit around 100 MiB memory, whereas putting a bunch of load on the grpc implementation balloons the memory usage to >1 GiB).

Swift on Linux has been a fairly horrible experience, but the language looks promising.

Nowhere in this quote are these fresh grads equated to "lousy programmers", though (which the flamebaity comment did).

And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.

Can't say anything about perforce as I've never used it, but I'd give my left nut to get Google's Piper instead of git at work :)

Actually curious - where have they? Zuck's claim didn't seem to be true. I'd imagine a few places that have low technical acumen have tried, but I'll want to see how much they pay for SWEs willing to clean that codebase after they let LLMs run amok on it.

Stubby calls (at least in Java) just use something called a GenericServiceMocker which is akin to a more specialised mockito.

Bit late to the party, but it looks like the author created a "framework" that allows for extremely rapid development of the simplest kind of CRUD app. Everything is fine and dandy as long as nothing needs to change, or if it needs to be changed, then the changer is the author themselves.

I applaud the author for their intellectual pursuit, but I don't think it's fair to compare this to codebases where one does not simply pass the POST request body into the database.

That's not necessarily the case, depending on how their pipeline was set up and what their VCS supports.

For example, you can always `git mv` the Java file to the Kotlin file and only then transform it, which keeps your history.

This should be short enough to read: https://github.com/Artamus/git-split/

It's not a good implementation of ownership tags, unfortunately :(

Couldn't flutter work as public-first that then gets vendored into third_party? Or is that literally the fork strategy you are talking about that I'm too dense to understand?

What did it say?

Sorry for the less-than-useful reply, but I tried out most of the TEA TUI frameworks in OCaml and none of them worked very well or well updated.

I do not recall what problem I had with that particular one, but I ended up just using raw Notty in the end.

But that way you make stacked diffs/changes/PRs really hard, so is it really worth it?

I firmly believe GitHub makes reviewing individual commits in a PR so painful that I'd rather not do that.

I understand why the `use` syntax is preferable for its generalizability to many different "callback style" things, but the whole construct of `use foo <- result.try(bar())` is so much worse than defining let* in ocaml and being able to write `let* foo = bar() in`...

GitHub's quirks definitely make life much harder than it needs to be, but I've been using `git machete` for months now with great success in my team. The __one__ thing GitHub has that makes it all work is the fact that if you merge the parentmost branch, its immediate child will retarget its base branch.

I think if I had full "control" over my company's SCM workflows I would use a tool that considers a branch as a workspace and every commit in the branch becomes its own PR (personal preference, but in my experience it also motivates people to split changes more), but alas.

Refactor first and overarchitecting up front are completely different things, though.

While I like abstracting storage into a repository class of sorts, this crap of "userService" needs to die already. I've seen too many bad codebases that stick everything user related into that one service that ends up having 8+ completely noncohesive functions.

As an OCaml beginner I've mostly seen it used for inner functions in lieu of calling the inner function `f_impl`.

Sad to hear your team was like that, mine definitely went the way of "if you know which way you're going to solve a problem anyway, why bother writing a design doc?" and I never felt burdened by them.

The problem here is also that it's not just annoying, some EU member states are not supported for PSN accounts and according the TOS you can get your PSN account banned if you sign up with the wrong country!