I've experience severe problems with Scala in teams with different skill levels or programming styles. Sometimes Scala code was very cryptic. As much as I like the elegance of the language as such, I've given up on it completely because it is not a good fit for industrial software development in my opinion.
An interesting example to look at is Java vs. Kotlin. While Kotlin is a bit easier and definetly more fun, it didn't manage to gain a big market share in the Java space so far. I guess that this is the case, because Java is good enough and seems to be the safer bet (at least for managers).
I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)
On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.
Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.
At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.
i am building my own framework on top of it[1].
the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.
This article looks a bit superficial to me. The cloud has definitely advantages, like having the same data on all devices and it provides some kind of backup. The mentioned downsides could be adressed by better software archticture or e2e encryption.
> The cloud has definitely advantages, like having the same data on all devices
That's not an advantage for the user at all, is it?
> and it provides some kind of backup.
You can backup user data in an offline-first app. Better even: you can let the user backup their data themselves!
> The mentioned downsides could be adressed by better software archticture or e2e encryption.
The article is superficial, but they mention at least one thing that cannot be addressed this way: what happens when you are offline or have a very slow connection?
It really boils down to one simple fact, IMHO: offline-first is harder to do. It is better for the users, but it is harder to do for the company doing it, which means it is more expensive. Companies are there for the profit, not to please the users.
> That's not an advantage for the user at all, is it
Of course it is an advantage. I tend to access most of my apps and services from both the PC and the smartphone, having data shared across the two is a deal breaker for the very vast majority of them.
> Better even: you can let the user backup their data themselves!
Whilst that's better for a small audience of techy types (most here, I'd guess), you know that's not true for most users, right?
Like people used to lose work on hard drives and laptops that they hadn't backed up all the time and its much, much rarer now (OK, I don't have data beyond anecdata but still).
I do yes. It's good to have a choice. Many times the reason there is not a proper local export is that it would take more work to implement properly, and it doesn't bring money to the company.
Again: companies exist to maximise profit. When making the product worse (or not making it better) improves their margin, they go for that. They don't care about the users, that's a big lie. A company fundamentally cares about profit. If competition or regulations mean that their profit is correlated to the users satisfaction, then they will have to work for that. But they don't do it "because they care about the users", ever.
The better software architecture is huge - if done right. It's the difference between cloud-only, local-only, and local-first. Not all apps are entirely easy as local-first, but you can often get 80-90% of what you need as that; and leave sync and collisions as rare situations to be handled manually.
Somehow money seem to damage personality. It's the same with David Heinemeier Hansson (who know Tobias Lütke in person), Elon Musk and many other folks.
That is basically true for every such system. Trust Signal? They could ship a backdoor in the next release. Same with Threema, WhatsApp (if you want to trust it today) and other services. You can expand that to the operating system as well. And who able to verify hardware security, anyway?
Interesting point of view. JSON is also not the right thing to use in many scenarios, but it is the de-facto standard now. Maybe something like protobuf is the way to go.
At least XML is hated for the wrong reasons (e.g. verbosity, esthetics) most of the time. There was for sure an era where it was overused (see Apache Cocoon from 2006 https://en.wikipedia.org/wiki/Apache_Cocoon). But XML is still a pretty good format to exchange (and store) data and make sure the data conforms to a certain schema. JSON Schema in comparison is not nearly as powerful.
1. What, in your view, are the right reasons to hate XML?
2. To me, verbosity and aesthetics seem like perfectly valid reasons to hate XML. Once you learn S expressions, XML looks disgusting. They implemented half of Common Lisp in a markup language.
> They implemented half of Common Lisp in a markup language
Come on, S expressions are just trees, they are not God's gift to humankind.. and just because a language has an AST (surprise, a tree again!) doesn't make it a lisp. I can write a C program's AST as sexprs or a Haskell program's, yet neither will be a lisp.
S expressions are just trees. XML is just trees. But S expressions are much less verbose trees. Once you see that they're both trees, then XML looks disgustingly verbose.
XSLT is what I meant by "half of common Lisp". It's probably an exaggeration, but once you can use XML to transform XML trees into other XML trees...
The right reason to hate XML would be some technical limitation or technical issues with it. But XML works quite well and is reasonable powerful. So the complaints usually boil down to: It is ugly and verbose.
I mean, it's also a taste issue. The verboseness is ugly. I don't like it.
But it's a technical issue. You have to parse all of that verbosity, every time you read it, which is inefficient. If you're hand-generating it, which happens in the development process, you have to get all of that verbosity right, or it doesn't work. These days nobody hand-rolls a parser, but the interface to the parser is more clumsy than it needs to be, because it mirrors the structure of XML.
