What happens in fast paced startups is that you ship what essentially is a MVP as soon as possible (i.e. you stop at the "make it work" step) because you need to build your customer base, finances, etc.
A better mantra would've been Facebook's "move fast and break things". But, that only works if you can fix the things later. You wouldn't do it if you're building an aircraft for example.
While I don't disagree (broadly speaking) with you about the complexity of webdev, it looks like you don't have a full understanding of what Tailwind is:
a (CSS) code generator.
It happens to be written in JS so it can be integrated as part of existing build steps or bundling. That's the rationale behind it. :)
It's build-time, not something client-side.
hey there, honestly I haven't tried prql yet but I think I already saw it on HN before.
What would you expect from a language integration? I'd like to work on something in Go, which doesn't make it easy to have Rust bindings.
One nice challenge for me would be to rewrite the compiler in pure Go, but maybe it's too complex of a task bringing little value to the project overall :)
What other tools do you need? E.g. what kind of CLIs? What do you mean by alternative backends?
it's fairly concise, the method and the request/response types are well separated and readable
the only thing I could argue with is mixing validation and type defs, as it looks like one of these things that quickly evolve over time and you end up duplicating both in the schema and the business logic
Usually the Go team scrapes from GitHub and open source programs how people use something before breaking them; I suspect they found little usage of { and } in HTTP handler paths. They also provide a way of opting out the new behaviour, so they don't force you to change anything in your code (but yes, it does require you to set a new env var).
The change to the for loop semantic is another example in this release; it effectively is a breaking change.
All Go programs continue to compile and run, though with minor behavioural changes. I think Go took a pragmatic approach, and that was one of the reasons for its success.
From a purist perspective, you're right - the contract has been broken, and a major version should've been incremented.
However, Go has always been more of a pragmatic than a purist language. For example, they've analyzed tons of code and found that most of them had bugs caused by having `for` loop with a single variable being mutated. So they changed the `for` loop (in a technically backwards incompatible way) in order to make all those bugs disappear. In a way, they modified the formal contract to make it more aligned with the de-facto contract that users were expecting.
I personally think that kind of pragmatism beats purism any day. Maybe the fact that I've never personally been affected by Go backwards incompatibilities also plays a role... But I've yet to find a single person who has :)
Solid advice. I also have seen companies not able to follow the simple rules you described, or getting lost in heavyweight frameworks (given that I understand being a single individual vs an entire companies have different problems, my complaint is about underestimating the overhead they create).
Shipping should be a priority, not an afterthought.
Having people with strong opinions is important. Even more important is having a lot more people which will weight the strong ones and put the missing context :)
I believe they're saying that cloudflare will block them just for using a blacklisted client, even if they're legit users and not bots