nobleach

I've worked for multiple shops that basically just moved to Java 8 and then bolted an anchor to the nearest pylon. A few made one move to JDK 11 for the "LTS" experience. I can understand their reluctance to move on as the move from <8 to 8 brought a lot of pain. Those old apps had a lot of cruft. Your modern Spring Boot app shouldn't be as tough though. (ByteBuddy maybe an issue). Even the folks that have moved on, aren't really using any of the new functionality. I realize every shop is different, this is just my experience.

I think it speaks to an incredibly pragmatic viewpoint though. When you take a look at your flagship language/ecosystem and you say, "hey, this is great for building entire systems for doctor/patient data... or perhaps even banking software"... but recognize that "it's probably not the best thing for building a compiler/tooling". Google themselves show the same pragmatism when NOT using Go for Android. They prefer Kotlin these days.

I find these oddities far more realistic than the Wat video from a long time ago. Many of the things in that video had me asking, "sure but...what programmer would blindly try these things and then be shocked when they didn't work?" The examples in this article are actual "gotchas" that could silently bite someone.

For me it's the metal studs in my walls. WiFi reception is truly awful. Fortunately it was prewired with Cat5e. But that will need to be replaced some day.

I truly enjoy the Primeagen. I've watched him since he started on Twitch. I don't ever really see him pushing any particular agendas at all. Mostly he's either trying new things, or working on projects. That's pretty much been his jam since day one. He has opinions, sometimes they're counter to the typical dev takes. Theo is much more likely to have a commonly shared opinion. That's not necessarily a bad thing if you're into NextJS (I'm not). I just don't feel like either of those guys are trying to get me to buy stuff.

But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.

I get why you might feel that way. Ryan and Michael used to run a company based around React training. They created React Router which some people love to complain about. They've since moved over to working for Shopify. Shopify pays for their development on React Router/Remix. They do NOT sell training anymore.

Kent on the other hand, worked with them for a short time. He makes his living selling training. Filling in a gap (selling training) isn't really a grift is it? The dude's got a family and he's found something he can sell.

While that is possible, I think a good manager recognizes these pitfalls. My philosophy is "everyone has to scrub toilets once in awhile - that includes me". You'd have to ask my direct reports but, I'd like to say I lean more toward taking the "grunt tasks" that I don't think are super helpful for my folks' career growth.

Then again, I've been called a bad manager on Hacker News so...

This is assuming that many of the folks who put their time and effort into the Linux kernel would have instead worked on Hurd. The thing is, nothing was stopping them from making that choice - other than maybe the popularity of Linux. I would love to see that timeline though.

LinModem for me! I got my US Robotics 33.6 (with X2 software upgrade-ability) working and was so amazed. Then my dad's ISP got rid of a bunch of external serial 56k modems and I was in heaven. Those "just worked". Oddly, it was probably 6 months later that DSL started making a splash and I was trying to figure out ways to use my Alcatel USB "stingray" model with Linux. I ended up buying an external "gateway" that required me to set the MTU to 1492 instead of 1500. It screwed up my Redhat 7.2 downloads so badly. The checksum would never match so the install would always fail.

Somehow I still refer to these as "the good old days".

It definitely feels like JetBrains won this battle. I used NetBeans for Rails development of all things (JRuby).

I suppose that's fair.

There's a wonderful Kafka Children's book that I always suggest every team I work with read: https://www.gentlydownthe.stream/

The way I describe Kafka is, "an event has transpired... sometimes you care, and choose to take an action based on that event"

The way I describe RabbitMQ is, "there's a new ticket in the lineup... it needs to be grabbed for action or left in the lineup... or discarded"

Definitely not perfect analogies. But they get the point across that Kafka is designed to be reactive and message queues/job queues are meant to be more imperative.

To beat my example into the ground.

If I were to put a fuel injector (system under test) into a vehicle, and drive it around a parking lot (E2E test), only to have the vehicle stall out. Is the fuel injector at fault? How would you prove that?

No, you pull out the component and you "bench test" it. Believe me, after many MANY hours spend fighting bugs where the extensive E2E suite passed, we finally had to go back to adding in unit tests for the small units under the surface. Not all... but many places.

It's pointless if one is just trying to put "points on the board" and see a bunch of green in their console. Knowing what to test is important. Should every function be tested? Probably not. Should every function that has conditional logic be tested? Maybe? I totally get that integration tests have immense value. Where I disagree is that, "the closer your tests are to the way a user would use your app" is a good way to use testing. Functional/Acceptance/E2E tests are but one tool in an aresenal. Telling new software developers to ignore 25 years of history because React components were hard to test in isolation (Enzyme - the package Kent's React Test Library is built to replace) is irresponsible. Telling them that it's "best practice" is disingenuous.

I absolutely appreciate respectful disagreement!

The point I often try to make is just how easy it is to get the right result, for the wrong reasons. (especially in loose languages like JavaScript). It goes from making more scientific proofs to, "I saw what I wanted to see on the screen - I can't exactly say why, but I think it's because my code is sound".

It's the equivalent to, "this new flea killer kills twice as many fleas". "What did you change?" "Four different things", "which one ended up being the thing that actually made it work?", "dunno, but now we're seeing twice as many fleas dead!".

Like I mentioned:

``` function setButtonState() { const res = this.fetchSomeResult(); // returns an unfulfilled promise if (res) { return true; }

  return false;

} ```

as a unit test would quickly fail when you want it to. An E2E test would pass, but for the wrong reasons. This has nothing to do with app state, and everything to do with not being scientific, and testing all sorts of variable things at once just because, "that's what the user sees".

Or, write code that _can_ work in isolation. (Pure functions). You can bet when GM builds fuel injectors, they have a harness that they can place them in to make sure that JUST the injector gets tested... putting it in a car and driving around is the wrong approach.

The same is often true for software. Ensuring that things integrate is vital. Ensuring that functions run in isolation also has value.

Eh, I knew this would somehow come back to that Kent C Dodds stuff. I can respect the guy, but his opinion on valuable testing differs from mine and quite a lot of others. His opinion is "the more your tests represent the way your users use your app, the better they are". For E2E tests, yes, absolutely. For unit tests, no... not at all. As a very short example, an E2E test will prove that yes, I did indeed show a button on the screen. A unit test will prove the code that put it there worked. The code can "fail open" for many reasons. (In JavaScript for example, forgetting an `await` keyword can return a truthy value!).

The worst part about it is that he called himself a thought leader, called his approach a "best practice" and had nothing really to back that up. Now people go around repeating it all the time. It's frustrating.

When I was learning SCUBA, one of our sessions happened in Tea Lake (learning how to do an emergency swim ascent). I can vouch for its name accurately representing its properties.

Same. Although I haven't tried VSCode in a lot of years. I did at one time have it set up to emulate vim quite well. I used it as a daily driver for over 6 months. It would puke the bed at least once a day, reseting the theme, losing all keyboard shortcuts. I'd restart it and go on my merry way.

I keep my Kotlin LSP for NeoVim up to date but it's just not a great experience. I often have to open IntelliJ to sort out import issues. The entire Java community is built on "don't worry about knowing where your imports are coming from, your IDE will do that magic for you". So much is this the case, that the first Manning Kotlin book even said it. Because of this, I was eager to give Fleet a shot. My impression was, "you won't build an LSP because you're afraid of losing revenue... but you'll build this?" Ok. I guess that makes sense - keep people on your playground.

I sure do LOVE Kotlin as a language. But telling me I have to use your product to write it? I'd rather write Go... or even Typescript at that point. Both of those have really nice experiences in a simple text editor + LSP.

I've used it a total of 2 times since I first saw the ability in Atom back in 2017. Once was more for the "this seems neat, let's try it" factor. The other was a legitimate, let's troubleshoot an issue while staring at the same massive screen together. It's not a bad feature, it just never stuck with my workflow - I typically hop on a Zoom call now days, someone shares their screen and pair program the old fashioned way (by yelling out stuff like one does when someone else is playing solitaire)

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and Tuples going too! You can skip that silly Pipe-syntax war if you want!"

Indeed I forgot Stack-Up!

Never forget, they had Rob the robot. And to my recollection, he only worked with Gyromite.

"Jumping up and down like a Jack-Russel Terrier" as one commedian put it.

This is a fair take. Especially after reading the two linked blogs (which have also enjoyed some time here on HackerNews).

I have personally fallen into the category of "you can say you don't like Go, but you can't say it's not well designed". I've admitted as much here in years past. What has changed though is that I've written a few more apps/services with it and come to love the no-nonsense value-add. Go compiles fast, the tooling is great (The LSP for NeoVim just works) and the code written by seniors isn't vastly different than code written by mid/juniors. While I'm still not wild about the community attitude of "just build that yourself" I'm glad that the standard lib includes enough to make it possible.

I'll take the boring "easy to read" code over the "let me show you how much I know about Category Theory" most days. Please excuse the dig on FP - I do truly love OCaml, Elixir and now Gleam... I also just like the simple life some days.

I'm confused at what your comment was designed to achieve. It seems like an attempt to troll. But here it is:

Formatting tooling was chosen before several members joined my team. It was chosen due to having far fewer dependencies than ESLint+Typescript+Prettier etc. One package... one setup.

Secondly, what exactly do you think managing is? Someone has to make the ultimate decision and be responsible for it. Perhaps you think a manager is someone who's constantly wandering around taking a vote from everyone on how they want to steer the ship? While I do strive to find concensus among my team that's not leading. Agree to disagree there.

I feel the exact same way. I've had various iterations of this ftplugin for a couple of years now but... everyone else has figured out how to just install an LSP and move on. Why is Java such a special snowflake here?

I have an engineer on my team that loves RubyMine. I can't even argue with her choice... JetBrains does indeed make very solid products. I'm just not a fan though. Even still, I never want the code I write, or the tools I choose to be IDE/editor specific. Right now we're trying to figure out how to get Biome (JavaScript linter/formatter) to play nicely with RubyMine... it's not as simple as NeoVim/VSCode.