I feel that I need to preface my answer with the defusing disclaimer: I understand that you love the language very much. And statements like the ones I make may hurt, because they say bad stuff about the thing you love. But getting defensive might detract from otherwise interesting discussion.
In fact, I also love Scala. I've dedicated lots of my time to working with it (almost 15 years at this point!), I've been with it since 2.8.x days. And I really lament that it fell out of favor and huge swaths of the community left.
> Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.
Of course it is possible that I have misremembered, so I went and checked. It was a mistake on my part to make such a statement and not to provide an actual link.
All the code examples there use the new syntax. And I would guess that "Scala 3 reference" is the document that Scala 2 veterans (like myself) would have been using when learning about new features and contemplating migration to the new version.
> You need a degree to understand something such obvious? Never mind…
It might be obvious, but I felt that it wasn't obvious to some people (including the ones that were in charge of the documentation for Scala 3), so I wanted to expand a bit on that.
> The point is: New syntax is only new in the first few hours of contact with it.
Of course, but these "first few hours" are exactly the hours that were spent reading the documentation for the Scala 3, and I feel that making those hours harder wasn't the smart choice.
I think that Scala development team made a decision to chase growth, focusing on attracting new users and disregarding the old ones. Looks like they lost that bet - new users didn't come, and many old users were disappointed and left.
New syntax isn't the only problem of Scala 3, and probably it isn't even the biggest one. But it was the most glaring and visible issue - for me, almost every code example in the reference really felt like a spit in the face. Exactly this kind of off-hand dismissal of old-time users was one of the reasons some of the users started moving away from Scala (myself included).
> Braces in code are 100% redundant, useless noise.
The debate about "braces vs significant whitespace" is raging literally for decades. Like many similar debates, it seems that there's no "true solution" and no "true winner" - both sides have heaps of valid arguments.
I assume that both sides have their merits, and it's always a tradeoff between pros and cons of each approach. I use languages that have braces, and I use languages that use indentation - I see pros and cons of each approach. Outright dismissing the other side of the debate by saying that it's "100% useless" seems to be missing lots of nuance.
True, Scala (the language) offers lots of great functionality. And Scala 3 brought some important improvements.
But safety is not the only important aspect of a programming language. For me personally the community (libraries, tools, forums, blogs, etc) became much more important over the years, and I feel that Scala 3 really hurt the community angle.
They didn't explicitly propose replacing the syntax, true. But to an outsider, it sure looked like the new syntax was a priority - all the examples and code snippets in the official docs defaulted to the new syntax, making them infuriating to read for someone accustomed to braces.
If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs. But it wasn't done right from the start, and when that was finally added most of the damage was done, people already lost interest.
I understand that removing braces might feel harmless - but it really makes the code harder to read for people that use braces all the time.
If someone's brain is accustomed to seeing braces everywhere, reading code with them becomes almost automatic, handled by "low-level" parts of the brain. If the syntax is changed, then "low-level" brain areas have to pass work to "higher-level" areas, which increases energy requirements and processing latency. So reading unfamiliar syntax is literally harder.
Incidentally, that's also why many people are so picky about grammar - grammatical errors make the text noticeably harder to read.
I don't see the chart with changes of number of companies using Scala over time. But even without the chart - if after 15 years there are less than 300 companies in total, that's a bit depressing.
Of course legacy never goes away, and even 20 years down the line there will still be some demand for Scala programmers. Similar to how Cobol still lives on. But in my experience the language isn't growing anymore, even slowly dwindling in userbase. And this became way worse after Scala 3 mess.
Inside a single bank - definitely. But if you have dollars in different banks then they suddenly start having very different value. Couple examples just in case:
1. Spending dollars on US soil from an US bank account won't incur extra fees (at least visible to the person - I know about interchange fees, but they are borne by the merchant), while using card issued by a foreign bank can incur fees for cross-border transactions (at the level of 2-3% usually).
2. Sanctions and KYC concerns also make different dollars have different value. Money in US bank account of an US company employee can be used at face value - money in some less-favored country bank, not so much.
Without -S, `uv run --script` would be treated as a binary name (including spaces) and you will get an error like "env: ‘uv run --script’: No such file or directory".
-S causes the string to be split on spaces and so the arguments are passed correctly.
> Yes, this means there's the small loophole of traveling to another country (which is usually a long travel, this country is huge and the ocean is wide)
I'm a frequent traveler, so I tend to overlook that not all people have that option, apologies for that.
But in many countries where there are some restrictions or crushing import taxes, I saw that there usually quickly appeared a flourishing network of people that utilize the travel loophole to bring in the necessary items - some even build sort-of-a-business out of that. Many just ask their travelling friends to bring them phones they desire (I've been such a friend on multiple occasions).
Thanks for the info! They do look nice and the prices are very affordable.
I'm a bit worried by their lack of focus, though - looks like they are spreading themselves a bit thin, they are trying to build a lot of different gadgets all at once (keyboards, speakers, laptops, headphones, etc). Building a phone is hard enough, trying to build all other things might dilute the valuable development resources.
I've got this covered :) I use a separate phone for these apps. So I have a "normal" phone that I use regularly and can do whatever I want with it, and a "certified" phone that has these pesky apps - and nothing else.
That sounds quite dystopian. I did consider this possibility, but thought that it was sufficiently far in the future. Sad that this future already arrived :(
But can you elaborate on how this is enforced? Probably by requiring IMEI registration? (supposedly with a carve-out for tourists, something like "a new IMEI can be used for two weeks without registration, after that it stops working")
If it's IMEI-based, then probably you can still have an alternative phone that will use WiFi hotspot from the "certified" one. Speaking from experience here - we had a problem in Indonesia where we were unable to register a phone due to bureaucratic shortcomings, and so we bought a cheap phone to serve as a hotspot.
Inconvenient, true, but still workable.
Also, I don't know how IMEIs are implemented at hardware/software level. Maybe there are ways to spoof them somehow?
I see a lot of comments here talking about "end of free computing" and similar stuff. However, I'm trying to find ways to be somewhat optimistic.
There are already companies that attempt to make smartphones that actually try to preserve our freedoms (Fairphone and PinePhone come to mind, I'm sure there are more).
So even if mass-market smartphones become locked-down completely, we will still have alternatives. Sure, in some ways these alternatives might be less convenient, and they might be expensive - but if you can put a price tag on your freedom then you might not need it too much in the end.
Sounds like attempting to always inline a recursive function should be an error instead. But it's probably undesirable to make that change because it would likely break existing crates and thus backwards compatibility as well?
Wasn't for latency or throughput - I didn't notice any difference in latency, and difference in throughput is only visible when cat'ing 3MB of text.
However, for me the selling point was a text config file, which I can edit, backup, or store in git (unlike gnome-terminal, where customization was done either in GUI or in gconf, and while it's also text files somewhere they are difficult to work with).
It's specifically about cursor lag, but I think that's because it's more difficult to experimentally measure app rendering latency.