blandflakes

5 ms·

1.
by blandflakes 28d ago
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
2.
by blandflakes 28d ago
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
3.
by blandflakes 2mo ago
And the kubernetes code and APIs still read like corporate Java for years after, too
4.
by blandflakes 4mo ago
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.
5.
by blandflakes 4mo ago
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
6.
by blandflakes 5mo ago
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
7.
by blandflakes 5mo ago
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 seve
8.
by blandflakes 5mo ago
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...
9.
by blandflakes 6mo ago
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!
10.
by blandflakes 6mo ago
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 appro
11.
by blandflakes 6mo ago
> 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).
12.
by blandflakes 7mo ago
> 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 o
13.
by blandflakes 7mo ago
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.
14.
by blandflakes 7mo ago
> 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
15.
by blandflakes 7mo ago
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
16.
by blandflakes 7mo ago
> 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 se
17.
by blandflakes 8mo ago
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, lac
18.
by blandflakes 8mo ago
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
19.
by blandflakes 8mo ago
This isn't a personal website.
20.
by blandflakes 8mo ago
It's also pretty insulting to assume that everything is equally easy for all people.
21.
by blandflakes 9mo ago
Agreed; I don't actually even care about emulating this particular hardware, but these reports are just interesting reading.
22.
by blandflakes 9mo ago
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 t
23.
by blandflakes 9mo ago
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
24.
by blandflakes 9mo ago
> 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. Qui
25.
by blandflakes 9mo ago
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 fa
26.
by blandflakes 9mo ago
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.
27.
by blandflakes 9mo ago
I still haven't managed to get around to her scifi (but plan to!); but can wholeheartedly endorse The Raven Tower.
28.
by blandflakes 9mo ago
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
29.
by blandflakes 9mo ago
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 sel
30.
by blandflakes 9mo ago
I think they're pretty different, but there are some places where you can compare them: 1. Hiring and job market - the JVM is simply more employable 2. Ecosystem - in general you can expect the JVM to have library support for most thin

More ›