Rust also has great tooling. Clippy, Rust analyzer (the LSP). Developing Rust in NeoVim is just as fun as Go.
Other languages that do ok are OCaml, Elixir/Gleam, Typescript. Go and Rust just have what I consider a "cut above" the others when it comes to both tooling and standar language features.
I once worked with a dev that implemented his own forEach in JavaScript. And literally used an ECMAScript version 6 feature to do so! (native forEach in JS showed up in ECMAScript 5) Meanwhile, that project already had jQuery and Underscore... which also had their own versions of forEach! It was a bizarre choice.
Although I'm not a Microsoft fan, their docs for F# are worlds ahead of anything I've seen for OCaml (I know a few OCaml folks are working to fix this).
I've considered trying it for Advent of Code this year.
I get that. Having read Real World OCaml back when it was an O'Reilly book, I had a hard time not thinking Core was the defacto OCaml std lib. And its horrible documentation made me think the OCaml community was dead - or at least brain-dead. It appealed to one type of learner: Someone who just needs to see type signatures and has no interest in examples of how it could be used.
After reading OCaml From The Very Beginning my stance softened. Learning PURE OCaml is a must. (if you want to do AoC with it). You may find yourself bringing in Core or Base, after you've got a good idea of a solution.
It's definitely a fun language for doing AoC... but it can become extraordinarily frustrating when you hit a wall and all the StackOverflow answers assume Core.
No, I dont think this is the case. While a lot of devs use Chrome while developing, we're all well aware that 50% or more of US users are using an iPhone. And that's Safari no matter what. So many do a ton of testing there as well. Firefox often gets the shaft.
Agreed, the old Visual Basic, Visual C++, Borland Delphi, Visual C# experiences were how I dove into the deep end of several languages back in the late 90's/early 2000's. Things were VERY discoverable at that point. Obviously a deeper understanding of a language is necessary for doing real work, but noodling around just trying to get a feel for what can be done, is a great way to get started.
I see this pattern all over the place, not just PHP. When leveraging containers, what's a better option? Certainly Java, Rust, even NodeJS all have decent enough connection pools for PG. But telling those apps that are running in those containers, "uhhh, you're just one among many so, your pooling strategy may not represent reality". I've seen folks try to solve this by literally doing replica math when an app boots up (are there 8 replicas running? ok, divide Postgres' default 100 connections by that). Moving the pool outside the app container seems like a better move.
And while that's super awesome that someone feels passionately enough about a piece of tech - that they're willing to spend their precious resources helping others... that kind of charity is untenable. You can't expect that person to be there at 3am when systems are down and your nightly processing jobs are failing.
I have a couple Quarkus apps that I've run in Lambdas that start in about a second. This is without using GraalVM too! Good enough for what I was doing (taking a list of file names, finding them in an S3 bucket and zipping them into a single payload)
I was never a fan of codegen. Having all these files in my project that I didn't write felt wrong. While of course, most apps we write are full of code that we didn't write, relegating it to a classpath, or "node_modules" folder felt better. After using sqlc on a side project for a few months, I was totally sold! The code it generates sure is ugly but... isn't most lib code? It does the job so well. I've even begun to look at the code and just thank my lucky stars that I didn't have to write it. The docs around handling JOINs is a bit fuzzy. So far I've only been able to JOIN and pull every column from the joined table - but I have some GitHub issues I need to read. I'm sure there's a method that I'm overlooking.
>If not for components that were invented in VSCode (LSP) then no one would be using vim these days
I hate to tell you but, Vim has always had a pretty strong user base. There are folks like me that used it before LSP, and never had interest in leaving. Now your statement might be more accurate if you said, "If it were not for LSP, no one would be leaving VSCode for NeoVim."
> There are plenty of hills to die on that's much more noble than "I like this editor"
I agree. Use whatever you want. But don't make misinformed statements about WHY folks choose something other than your choice.
I notice you're mentioning: "We support Next.js frontends" and "Idiomatic Next.js APIs". What is it about your product that is NextJS specific? Can someone who has no interest in using NextJS still use your product?
In the case of the Challenger accident, the actual orbiter wasn't the problem. The seals on the solid rocket boosters were. That said, I don't know who was responsible for their design/manufacture.
I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. Our current in-house tool is a drag and drop editor that allows slices of content to be stacked. Each of these slices has preprogrammed selectable options for things like colors, sizes, body copy, headlines, etc. We consider this far too limiting. Now I will agree that my use of Webflow had me beating my fist against my desk. I could do the same thing in straight HTML in 15 minutes, that took me an hour or so in Webflow. Much of that was the learning curve; figuring out "the Webflow way". I see a future where we have tons of people who are good at these low-code/no-code tools. Sure I can run circles around them by being able to write all the code by hand. But for most things they'll be "good enough".
It's frustrating at best. On any tiling WM on Linux, I can hit Meta+<#> and be taken to that workspace.
On macOS, the moment I fullscreen an app, it's taken out of that flow. So for so many years, I've had my terminal full screen on workspace 2. Meta+2 it in my muscle memory for "go to terminal".
Show them a Quentin Tarantino film? ...or any film for that matter where the main characters seem so "cool, unfazed and untouchable". To a young (mostly male) mind, that's the ultimate goal; to be in charge. For most beginning smokers, it's not about the inhalation of tobacco, but the subversive "screw the rules, those don't apply to me" façade. This might sound obvious but, if we want 7th graders not to glorify smoking, we quit glorifying it in our media. Make the stupid guy in the movie the one that's dumb enough to smoke. Make everyone laugh at him every time he tries to look cool.
I've had 50/50. These days I'm fairly okay with just taking the Macbook Pro. I did have one instance where I got one my first week and used my Dell XPS with Linux the entire 10 months I was at the place. I returned the Macbook basically unused.
Only one time did I interview with a place where I asked if I'd be given a choice what hardware/OS I could use. The response was "We use Windows". My response was, "no we do not. Either I will not be using Windows with you, or I will not be using Windows NOT with you". I didn't get an offer. I was cool with it.
They had Core. Base is their new attempt at sort of a "standard" lib. Not all OCaml-ers use JS libs though. There are some Batteries users out there. When I do Advent of Code, I almost always try to do it with OCaml's built in standard lib.
I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from other languages. (For better or for worse) So I'm super hyped that we'd have a "compiles TO Go" language, but I'm not as excited as using it as a catalyst to get new (and perhaps wrong for the language) features into Go.
I've built POC apps with both this and Elysia recently. Elysia is really cool, it has a bit of its own ecosystem. Eden Treaty for example, is the way it handles backend to frontend type-safety. Hono on the other hand, seems like such a nice ExpressJS replacement. I wouldn't hesitate to ship either one.
This definitely kills the low-intent watcher. Twitch sends me daily emails to hop on and watch streamers that I follow. Every once in awhile, I'm not busy so I click the link, "Sure I'll watch that person write OCaml...". And 30 seconds in, I'm almost ALWAYS, "nah... I'm not into sitting here this long, I didn't even intend to be here".
If they could let someone watch like 3 to 5 minutes, they could likely increase engagement.
You can, and that is effectively doing something similar to putting a style tag in the head of your document. It'll block until the styles are parsed and applied. If you have a ton of styles, your Lighthouse score will suffer because your first contentful paint will take longer.
Unfortunately, it's not likely to help with FOUC. Flash of unstyled content happens when CSS isn't parsed and applied before the DOM is loaded and displayed. Even if one applies classes directly to DOM elements, if the stylesheet is still loading, you're going to see that flash. The only way to deal with it, is block rendering until the styles are parsed. (put it in the HEAD of the doc, etc)
You have basically found the Reddit /r/technology contingency. Most stories I see there are laughing at a single man's failures. There's just a lot of hate. I wanted a Tesla because other friends and family let me ride in theirs. I liked the car. I also like Chick-fil-a Chicken, and Papa Johns Pizza. From time to time, I visit Hobby Lobby. If I did digging on EVERY CEO, and found things that I disagreed with, I'd likely have few places left to shop. Instead, I try to focus on the other "non-crazy" folks that work at these places.
When it comes to Tesla technology... it's actually really good.