519 karma · joined June 19, 2012
Statically typed languages reduce the need to know how the data is structured or manipulated. The market has clearly chosen this benefit over what Clojure can provide.
We've generally adopted strict mode. I think it is now time to come up with and adopt a new no-undefined mode. And yes, it should break the standard library. It is worth it.
This reminds me of thousands of blockchain projects that used the technology to flip on light switch.
On the other hand, we've been "staving off the next ice age" too zealously: https://xkcd.com/1732/
I would start with Scratch and then move to a Basic with 2D drawing capabilities and then to Blitz3D which is a Basic with a 3D engine. Have a look at all the positive reviews.
By the nature of the problem you have to store some kind of a list of tokens. Either a black list as with JWTs or a white list as with classic session tokens. There is no way around it. This makes both approaches practically the same.
One can argue that the black list will in general be shorter than the white list, but in a case of a serious attack, would it really be so?
I am afraid that the community will now abandon JWTs and move to biscuits, macaroons, buns and meringues as they did with classic session tokens, throwing away the tools and security practices.
Fun fact: Henry Kissinger was elected an international member of Russian Academy of Sciences in 2016.
Then they are screwing around with AWS Lambdas and package size, but what is the advantage of the Lambdas if they don't make your deployment easier? Just have a ECS and run whatever you want for better price/performance ratio and much higher performance ceiling.
I don't get which of their tools are improving developer productivity or software quality. It looks like every tool stands in their way. Why won't they just learn SQL and use it? What's is so low productivity about it? It's the highest level data manipulation language there is. Now they are bringing Kysely for supposed type safety. Yeah, good luck debugging, optimizing or changing the queries in any way. You'll have to convert from SQL to TypeScript and back whenever you'd want to develop the query in your SQL console.
What I see is a bunch of poor choices. Shiny tools standing in the way of getting stuff done.
The language is not very approachable for junior programmers. You can grab a Python programmer and graft them on a Java or TS project and the same week they will deliver features and bugfixes. Reading other's people code in Clojure is much harder especially when coming from imperative world. The language is terse. The documentation is terse and lacks examples. Library documentation is insufficient or non-existent. You have to read other people's code. It is a really demanding activity aggravated by lack of static typing. You cannot just hover over a map in your IDE and see its structure. The value may have come through several transformations that add, transform and remove fields. To understand what arguments a function expects you have to decipher destructuring bindings which in real code can be ingenious, i.e. unreadable. And hold on to your butts when a clever teammate invents a flow of control macro and uses it throughout.
These and other reasons make the pool of candidates small, candidates "over-qualified" and expensive. If your expert quits, your whole endeavor is screwed.
I helped to rewrite a Clojure project that stalled due to lack of affordable talent. It's been chugging along since then at a considerable pace. The new language is very popular and much less affected by the mentioned problems.
There is a mention of Penpot in this thread. Mark my words, when it comes a time to scale, they will rewrite the whole thing in a popular statically typed language.