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.
Examples and code snippets in the official docs of course default to the new syntax, making them well readable for all people accustomed to Scala's new syntax.
> If I recall correctly, later they added a switch allowing one to choose between syntax versions in the online docs.
Stating this, which is not, and never was true creates the impression you're talking about things you have no clue about.
The point is: Removing braces really makes code much easier to read for people who get distracted by useless line noise!
> So reading unfamiliar syntax is literally harder.
> […]
> Source: have a degree in neurophysiology.
You need a degree to understand something such obvious? Never mind…
The point is: New syntax is only new in the first few hours of contact with it.
Anybody who uses more than one language knows that switching languages is in fact a bit distracting, but at latest on the second day you completely stop thinking about syntax, and than switching back to whatever was before is as hard as the previous switch to the current thing. Usually this happens already after a few hours for languages you already know.
As we're talking about neurophysiology: As a matter of fact filtering "noise" — irrelevant information — from sensory input is a hard task for the brain. So having less distracting useless noise in the input helps to concentrate on the stuff that actually matters!
Braces in code are 100% redundant, useless noise. The only reason they were added in the first place was to make code simpler to parse for computers, something that does not matter any more since many decades. So there is no rational reason any more to pollute code with useless, distracting noise.
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.
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.
The website is a private undertaking which started literally a few days ago. It's not some official complete tracker.
The point was to show that big corps are dependent on Scala, often at their core.
Scala is likely not for everybody, but where you need to write safe high level code there is more or less no alternative, not even on the horizon. Scala is simply very likely where Rust will end up after the honeymoon, when people realize that feature rich, safety first languages aren't for the mass market, where mostly only the cost of initial development counts.
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.
> But safety is not the only important aspect of a programming language.
That's also part of what I've said.
The point still being: Where you need a safe language there is no way around it, and Scala is still one of the very few options you have at all. Scala is in that regard indispensable.
> I feel that Scala 3 really hurt the community angle
I don't see that.
Everything relevant, besides Spark, is now on Scala 3, and this is already like that since a few years.
But I agree that Scala documentation / references / tutorials are to this very day lacking. This was and still is a real issue, and that's actually a very relevant one. I really hope this gets better with time.
The sub-optimal situation regarding docs does though not prevent people from starting new projects in Scala.
In fact Scala 3 is again ahead of the pack. It provides features not seen so far in any real world language and will almost certainly again pioneer the implementation of new language concepts in the large, as it did already in the past with its pragmatic approach to a OOP / FP fusion.
Just see for yourself what is currently happening:
USD in bank accounts is definitely fungible. They may track who sends what money to whom. But this transaction data is not tied to specific 'dollars' just to 'dollars' in general. So yes, perfectly fungible.
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.
This examples don't mean the dollars aren't fungible only that where they are stored can make them less accessible or subject to fees. Its like the difference between a gold nugget in your hand and one that's buried deep in the ground. The gold itself is inter-changeable, one nugget is worth the same as the other if side by side. Only one is in a more inaccessible location and you'd have to pay the cost of retrieving it. If you magically switched the two nuggets, the situation would be exactly the same from a value perspective.
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.
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.
> So even if mass-market smartphones become locked-down completely, we will still have alternatives. [...] (Fairphone and PinePhone come to mind, I'm sure there are more)
You're not looking far ahead enough. Use of these alternatives will be banned.
I already cannot use any of these alternatives: all cell phones must be certified to be imported into Brazil, and so far I could find none of these alternatives certified by ANATEL. My only options are Android, Apple, or non-smartphone "feature phones" (they still exist). Yes, Brazil is one of the first countries on the list for this change from Google, and Apple already does something similar.
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?
The import is rejected by customs. 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), buying the phone there, and bringing it back with you.
I don't know whether the carriers do reject phones with IMEI pointing to a non-homologated model used with a SIM registered to a Brazilian carrier (that is, not roaming).
> If it's IMEI-based, then probably you can still have an alternative phone that will use WiFi hotspot from the "certified" one.
That takes me back, it's exactly how I used my pre-smartphone PDA, tethering to my phone through Bluetooth. Yeah, that would work (it's exactly how I use my laptop when I can't use the normal Internet connection), were I able to import the thing in the first place.
> 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).
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.
I was looking at Shiftphone but haven't been able to identify a single advantage over Fairphone. More vendors isn't bad, but it's so niche, I think more people actively use F-Droid (and that's already niche) than know the name Shiftphone! They'd stand stronger and be a more realistic option if they collaborated on some level
I'm curious if you know of any reason to buy Shift besides specifically supporting German economy instead of the Dutch one
And would you know why they don't work together? At least on the software side that's easy to do remotely. I know Fairphone has been struggling to catch up with the machine learning and other services other vendors are adding on top of e.g. the camera sensor to get good photos. They seem to be doing better now but Shift seems to still have a lot of software bugs, eyeing their forums
Shift has more products to offer. They also have a slightly different concept. For example, the batteries are compatible across device categories (put the phone battery in the tablet keyboard) and the make sure that only ONE type of screw is needed for the complete phone. They also have hardware kill switches on their devices
Shift is more or less a non-profit (their type of LLC/Gmbh has a special status) and they have a broader opinion on what „fair“ means.
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.
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?
"inline(always)" I expect matches Clang's "always_inline", and Clang's documentation makes what it does clearer:
> Inlining heuristics are disabled and inlining is always attempted regardless of optimization level.
So it should be interpreted as "always attempt to inline", as opposed to "this must be inlined", or other attributes that instead influence the "should this be inlined" heuristic.
EDIT: as curious an attribute as it might be, I didn't mean to be talking about inclines
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.
reply