blandflakes

I agree that automatic resource management is a real prize, and something that Scala 2 had in libraries but was hard to guarantee at compile time. I think I fix a leaked resource a month in our Scala code.

bold-faced lie is just the usual English drift that was actually questioned as incorrect when it first surfaced. If a lie is bold, you don't have to suggest that the user's face is bold when doing it. You can in thirty seconds of google searching find numerous sources explaining that "bold-faced" is a malapropism.

In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.

And the kubernetes code and APIs still read like corporate Java for years after, too

Yeah I have long felt that if we think we need gradle, we should consider doing less crazy stuff in our build. Maven is plenty and any time I get back to a repo that has that instead of gradle or sbt I’m much happier.

Is your disinterest in LiveView because you'd prefer the more common SPA/API separation, or some other reason? I'm curious because as a mostly backend engineer I view LiveView as sort of a killer tool for the sorts of apps or tools I'm likely to build.

This is both a fair response and isn’t! The OP was talking about typical Java stuff you’ll encounter, which is overwhelmingly spring boot. But I also agree that you can do much better than that for resource usage if you’re willing to avoid the common defaults the community has embraced.

This was also true of Amazon's Leadership Principles. They are pretty reasonable guidelines, but in a debate, it really came down to which one you could most reasonably weaponize in favor of your argument, even to the detriment of several others.

Which maybe is also fine, I dunno :)

The trajectories of Go and Scala here tell a much different story (and one that matches my personal experience looking at job postings): https://innovationgraph.github.com/global-metrics/programmin...

Engineers also wrote good code before AI. We don't get to pretend that the speed increase of AI only increases the output of quality code - it also allows engineers to send much more crap!

Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.

> I pick tools by the problem, not loyalty.

Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).

What did you move onto for those next things you started building?

> It is the best idea. This should be the standard. And nothing prevents you from rolling back an individual service. You can still do that. And you can still do individual deploys too. But these are just for patch ups.

There are a ton of reasons it's not the best idea. This flies in the face of a lot of _better_ ideas.

Keeping changesets small so that it's easier to debug when something goes wrong? Blown out of the water by deploying everything at once.

Bringing every service up at once is a great way to create the coldest version of your entire product.

Requiring a monodeployment turns canarying or A/B testing entire classes of changes into a blocking rollout where any other feature work has to move at the pace of the slowest change.

> When you roll back an individual service your entire system is no longer in a valid state. It's in an interim state of repair.

The gold standard is that each version of your service can work with each other version of your service, because in The Real World your service will spend time in those states.

> Monodeploy should be the gold standard, and individual deploys and roll backs are reserved for emergencies.

No, because if it's still possible to mix versions in your services, then a monodeploy doesn't actually solve any issues.

I actually am a big fan of fewer services and deploying bigger artifacts, but if you have multiple services, you have to act like you have multiple services.

Yeah, I think you're preaching to the choir about static checking, the only point I was making is that monorepo doesn't solve some classes of errors and that I've actually seen it generate false confidence in that realm.

> Simple, although I only mentioned repos should be mono, I should've also said deployment should be mono as well. I thought that was a given.

Deploying your service graph as one atomic unit is not a given, and not necessarily even the best idea - you need to be able to roll back an individual service unless you have very small changes between versions, which means that even if they were rolled out atomically, you still run the risk of mixed versions sets.

Well, no, it doesn't. A monorepo does nothing to prevent you from making breaking changes, it just stops you from making changes that don't compile/test. You still have to understand that services aren't deploying as an atomic unit and make sure that your network calls are forward and backward compatible.

> First put all your services in a monorepo have it all build as one under CI. That’s a static check across the entire system.

There are definitely benefits to this approach. My coworkers do fall into the trap of assuming that all the services will be deployed simultaneously, which is not something you can really guarantee (especially if you have to roll one of them back at some point), so the monorepo approach gives them confidence in some breaking changes that it shouldn't (like adding a new required field).

Go seems to have some enduring affection and popularity for new projects and companies. I recently felt like a lot of the recent shift was less about GC and more about runtime characteristics (static binaries, lean resource consumption, lack of an in-your-face virtual machine).

It never felt like Nim, Pony, or Crystal were ever that popular that a diminished hype cycle registered as something thematic to me (not that I really intend to disagree with your perspective here).

If you have to ask an object what its type is, you're probably about to cast it, and these are operations that the language doesn't enforce that you do together (and so the habit of casting can lead to the habit of casting without the check...). There are times when it's appropriate but generally if you have to ask what type an object is, your code is already starting to smell (because typically dispatching on type is handled by polymorphism, not be the programmer manually implementing it).

This isn't a personal website.

It's also pretty insulting to assume that everything is equally easy for all people.

Agreed; I don't actually even care about emulating this particular hardware, but these reports are just interesting reading.

I don't think we have to choose. Naturally finding the "right division of labor" is as infinite as finding the "right level of abstraction", but I think the ideal situation is to strive toward code that is easy to test without having to introduce a lot of mocks or without infinite layers of abstraction.

They also encourage/enable code that is less testable. If you use mockito to get your fake responses/assertions where you need them, you don't have to think about your class's dependencies to make your code testable and therefore better decomposed. I don't even do TDD, but I still find that thinking about how I'd test a class guides me toward better-factored code.

> Static typing doesn't have much value if there are proper unit tests

Wasteful unit tests that assert your types are right don't have much value if there is a proper type system.

> It's called ratting yourself out.

Quit being childish.

This always feels like a bad faith argument. Nobody says that with static types, you don't need any unit tests.

And your suggestion that people who like static types "don't know how to write unit tests" is further bad faith.

Perhaps it's dynamic typing programmers who don't know how to write sound programs? Except I'm not making that claim, because I'm giving you all some benefit of the doubt, a degree of respect you are not giving others.

Elsewhere in this thread, dynamic typing advocates malign the hassle of maintaining types, and it is always coupled with strong advocacy for an entire class of unit tests I don't have to write in statically typed languages.

I still haven't managed to get around to her scifi (but plan to!); but can wholeheartedly endorse The Raven Tower.

Yes; my only critique is that Elixir is already a niche. You could argue it two ways:

1. A niche within a niche is a bad idea 2. If you're going niche, going further niche hardly makes a difference

This is patronizing. I'm a professional and am constantly hiring and being hired. The JVM has far more jobs and engineers willing to do those jobs, _and_ in terms of your own employment, a better salary market, and this is not only self-evident, but reinforced by even a cursory investigation into the trends. In fact, your claim is so outrageous (that I'm wrong and that somehow Elixir has more to offer on either side of the hiring bar) that I think the onus is on you to somehow prove it.