> I wouldn't even be against requiring a professional certification organization for developers before they're allowed to publish software to the masses
Is Google that organization? Because they themselves have decided that they are. I think what people are worried about is that Google is positioning itself to be the judge, jury, and executioner within such a licensing framework, not necessarily the licensing itself.
> This is just to address malicious code.
Yes, and if Google had shown that it's capable of identifying and rejecting malicious code distributed via its own app store, then maybe their proposed expansion of that security program to the entirety of the Android app ecosystem would carry some weight. But as it stands, their Play Store is full of user-hostile and often malicious apps[1].
> If you publish software for a private group of people, there should be no restrictions. If you're publishing it on a platform that would expose your software to billions of people, get a license after id verification
But that's exactly the opposite of what Google is doing, here, and why people are mad. Google isn't adding a new policy to their app distribution platform (the play store that grants exposure to billions of users), but rather they are forcing ID verification on any form of app distribution: If you want any regular user to be able to install your code, no matter how small the audience, you'll need to first give your identity to Google, and obtain a (paid[1]?) license. So the restrictions do apply to "a private group of people" too.
The crux, and what has people up in arms I think, is the overreach of Google's peoposed licensing policy to cover not only their own app distribution ecosystem, but all others targeting Android.
Many technical users of Android consider it to be a general purpose computing platform, and they want to retain the freedom to install and run whatever software they trust.
Google should focus their supposed concerns about regular user's safety on the user-hostile apps that they allow to exist in their own app store, rather than grasping for broader control that they'll "probably use at some point but only for good things like user security".
I agree, it isn't and shouldn't be, an industry self-regulating org is needed, like the CA/B forum for browsers. Maybe one day we can transition to that.
> Yes, and if Google had shown that it's capable of identifying and rejecting malicious code distributed via its own app store,
You're making the opposite point there, they can't do a good job at scanning their appstore, so requiring devs to id themselves is a better option, so that anyone publishing malicious code might risk real-world criminal penalties. That's a better deterrent than google scanning code.
> If you want any regular user to be able to install your code, no matter how small the audience, you'll need to first give your identity to Google, and obtain a (paid[1]?) license. So the restrictions do apply to "a private group of people" too.
This applies to google certified phones, and such phones at the time of certification are sold to the public, not to a private audience. Private audiences need to buy non-google-certified phones (which exist). The question of google certification is one you need to have with phone vendors not Google. Samsung can opt to avoid google certification just fine. They have every right to demand that a phone with their stamp on it can only run apps by devs they authenticated, this is the price of their seal of approval.
> Many technical users of Android consider it to be a general purpose computing platform, and they want to retain the freedom to install and run whatever software they trust.
Yeah, for example I have an x86 android VM, it won't be affected because it isn't google certified. If you came up with a custom tablet or laptop that runs android, you can load random apps on it just fine.
> Google should focus their supposed concerns about regular user's safety on the user-hostile apps..
They can do multiple things, but this helps with that as well. the dev making user hostile apps now has to use his real name and their reputation will now follow them forever.
Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created:
We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and which could divide the ecosystem[1].
Yet somehow PHP was not limited by these hypotheticals, and simply gave people the feature they wanted, in exactly the form it makes most sense in.
Am I correct in my understanding that you're saying that the developers of the most widely used JS engine saying "hey we can't see a way to implement this without tanking performance" is a silly hypothetical that should be ignored?
With JS' async/await system basically running on creating temporary closures, I don't think things will change all that much to be honest.
Furthermore, I don't see why engines should police what is or isn't acceptable performance. Using functional interfaces (map/forEach/etc.) is slower than using for loops in most cases, but that didn't stop them from implementing those interfaces either.
I don't think there's that much of a performance impact when comparing
const x = fun1(abc);
const y = fun2(x);
const z = fun3(y);
fun4(z);
They can't implement function application without tanking performance? I find that hard to believe. Especially considering that function application is already a commonly used (and, dare I say: essential) feature in the language, eg: `Math.sqrt(2)`.
All we're asking for is the ability to rewrite that as `2 |> Math.sqrt`.
What they're afraid of, my understanding goes, is that people hypothetically, may start leaning more on closures, which themselves perform worse than classes.
However I'm of the opinion that the engine implementors shouldn't really concern themselves to that extent with how people write their code. People can always write slow code, and that's their own responsibility. So I don't know about "silly", but I don't agree with it.
Unless I misunderstood and somehow doing function application a little different is actually a really hard problem. Who knows.
Your simple example (`2 |> Math.sqrt`) looks great, but when the code gets more complex, then the advantage of the pipe syntax is less obvious. For example,
foo(1, bar(2, baz(3)), 3)
becomes something like
1 (2, (3 |> baz) > bar), 3 |> foo
or
(3 |> baz) |> (2, % |> bar) |> (1, %, 3 |> foo)
That looks like just another way to write a thing in JavaScript, and it is not easier to read. What is the advantage?
Uhm, don't do it, then. That's like arguing that the addition of the ternary operator is a bad one because not all if/else blocks look better when translated into it.
The goal is to linearlize unary function application, not to make all code look better.
I think the commenter meant that once the new syntax is approved and adopted by the community, you have no choice to not use the syntax. You'll eventually change your project and will be forced to deal with reviewing this code.
_You_ might not use it, but somebody's going to send a PR, or some LLM is going to spit it out, or some previous maintainer put it in there, or will be in some tutorial, or it will be in some API documentation.
You are going to have to deal with it as a mess at some point. One of the downfalls of perl was the myriad of ways of doing any particular thing. We would laugh that perl was a write only language - nobody knew all the little syntax tricks.
Closures won over OOP in Javascript a long time ago (eg, React switching from classes to functions + closures), but they still keep trying to force garbage like private variables on the community.
Loads of features have been added to JS that have worse performance or theoretically enable worse performance, but that never stopped them before.
Some concrete (not-exhaustive) examples:
* Private variables are generally 30-50% slower than non-private variables (and also break proxies).
* let/const are a few percent slower than var.
* Generators are slower than loops.
* Iterators are often slower due to generating garbage for return values.
* Rest/spread operators hide that you're allocating new arrays and objects.
* Proxies cause insane slowdowns of your code.
* Allowing sub-classing of builtins makes everything slow.
* BigInt as designs is almost always slower than the engine's inferred 31-bit integers.
Meanwhile, Google and Mozilla refuse to implement proper tail calls even though they would INCREASE performance for a lot of code. They killed their SIMD projects (despite having them already implemented) which also reduced performance for the most performance-sensitive applications.
It seems obvious that performance is a non-issue when it's something they want to add and an easy excuse when it's something they don't want to add.
I wish I could upvote this more than once. I really liked the F# inspired pipe operator proposal and even used it a bit when I used to lean on 6to4/babel more, but it just sat and languished forever it seems. I can't really think of any other language feature I've seen since that I would have wanted more. The new Temporal being one exception.
It seems like none of the really good language proposals have much traction. Proper Tail Calls have been in the language for TEN YEARS now, but v8 and Spidermonkey still violate the spec and refuse to implement for no good reason.
Record/tuple was killed off despite being the best proposed answer for eliminating hidden class mutation, providing deep O(1) comparisons, and making webworkers/threads/actors worth using because data transfer wouldn't be a bottleneck.
Pattern matching, do expressions, for/while/if/else expressions, binary AST, and others have languished for years without the spec committee seemingly caring that these would have real, tangible upsides for devs and/or users without adding much complexity to the JIT.
I'm convinced that most of the committee is completely divorced from the people who actually use JS day-to-day.
I think it’s mainly because they struggled to get consensus on which syntax to go with for pipelines, since people were divided into three different camps. I wish they would just standardize all three options with a slightly different operator for each one
It used to be said that "Lisp programmers know the value of everything and the cost of nothing."
This applies to MOST devs today in my experience and doubly to JS and Python devs as a whole largely due to a lack of education. I'm fine with devs who never went to college, but it becomes an issue when they never bothered to study on their own either.
I've worked with a lot of JS devs who have absolutely no understand of how the system works. Allocation and garbage collection are pure magic. They also have no understanding of pointers or the difference between the stack and heap. All they know is that it's the magic that makes their code run. For these kinds of devs, spread just makes the object they want and they don't understand that it has a performance impact.
Even among knowledgeable devs, you often get the argument that "it's fast enough" and maybe something about optimizing down the road if we need it. The result is a kind of "slow by a thousand small allocations" where your whole application drags more than it should and there's no obvious hot spot because the whole thing is one giant, unoptimized ball of code.
At the end of the day, ease of use, developer ignorance, and deadline pressure means performance is almost always the dead-last priority.
I know that was the reasoning for the Records/Tuples proposal being shot down. I haven't dug too deeply into the pipeline operators other than to get a feel for both proposals.
Most of the more interesting proposals tend to languish these days. When you look at everything that's advanced to Stage 3-4, it's like. "ok, I'm certain this has some amazing perf bump for some feature I don't even use... but do I really care?"
I guess partially my fault, but even in the article, you can see how the Hack syntax is much nicer to work with than the functional one.
Another angle is “how much rewriting does a change require”, in this case, what if I want to add another argument to the rhs function call. (I obv. don’t consider currying and point-free style a good solution)
I am wondering if PHP explicitly rejecting Hack-style pipes (especially given the close ties between PHP and Hack, and that PHP doesn't have partial application, but JS does, sort of, though its UX could be improved) will add leverage to the F#-style proposal over the Hack-style.
It may be useful data that the TC-29 proposal champions can use to fight for the F# style.
Hi I'm Aldwin: A functional programming expert, full stack developer, and software architect. I have over 13 years of full-time professional (plus years of hobby and open source coding) experience. My website has all the details: https://altshift.win/
I can design and/or build you a system, offer consultancy and code reviews, or coach your development team to improve development processes and code quality.
Functional programming expert looking for freelance opportunities. Over 13 years of full-time experience plus years of hobby and open source coding. My website has all the details.
My name is Aldwin. I'm a back-end-leaning full-stack (web-) developer with over 13 years of full time professional experience at various software development agencies. Besides that, I have years of hobby-programming and open-source experience, with Fluture[1] being my most well-received open source library.
I've been leading small teams for the last eight years, focusing on developer enabling work such as process management, devops, software architecture, and coaching.
I'm very passionate in particular about functional programming, and I'm hoping to coach teams when it comes to the cross-over between functional programming and software architecture - something a lot of developers who are new to FP struggle with.
Although I have been involved in a huge variety of software types, I'm particularly well-experienced when it comes to real-time, offline-first web-applications and real-time data processing.
I'm looking for (ideally) part-time (up to 28h) freelancing opportunities.
> I envisioned a plot, with a steep curve: x is time, but what’s on y?
This question really got me thinking, because I've always envisioned a plot as well, but the phrase always made sense to me.
I realized that I think of x being "mastery" and y being "knowledge required". On such a plot, you'd see a steep curve if one needs a relatively large amount of knowledge to progress to the next level of mastery.
I've never thought of it differently, and so never realized that the phrase is ambiguous until reading the article. Upon reflection, it makes much more sense plotting time on x and mastery on y when talking about learning.
The way I see it, if you would use Copilot to completely (or largely) reproduce an existing work (software), then you would be infringing copyright. This is similar to using an AI to largely replicate a piece of music.
If you are using it to mix a snippet of code (from a sufficiently large code base) into a large code base of your own, then you are just remixing. That is not infringement. In music, there are entire genres based on remixing. You could even take it a step further and ask yourself: what is not a remix?
Yeah, I've heard about some of those cases. It's surprising how far copyright can be stretched sometimes.
What's more surprising is to see copyleft advocates positioned so strongly in favour of giving copyright that kind of reach. I think that in a different context, some of the cases you refer to would be used by these same copyleft supporters as examples of why copyright needs to be more weakly enforced, not more strongly.
At the very least it should be consistent. If Microsoft can sue me for something trivial that probably shouldn't be illegal but is, then I can sue them for something trivial that probably shouldn't be illegal but is.
Is Google that organization? Because they themselves have decided that they are. I think what people are worried about is that Google is positioning itself to be the judge, jury, and executioner within such a licensing framework, not necessarily the licensing itself.
> This is just to address malicious code.
Yes, and if Google had shown that it's capable of identifying and rejecting malicious code distributed via its own app store, then maybe their proposed expansion of that security program to the entirety of the Android app ecosystem would carry some weight. But as it stands, their Play Store is full of user-hostile and often malicious apps[1].
> If you publish software for a private group of people, there should be no restrictions. If you're publishing it on a platform that would expose your software to billions of people, get a license after id verification
But that's exactly the opposite of what Google is doing, here, and why people are mad. Google isn't adding a new policy to their app distribution platform (the play store that grants exposure to billions of users), but rather they are forcing ID verification on any form of app distribution: If you want any regular user to be able to install your code, no matter how small the audience, you'll need to first give your identity to Google, and obtain a (paid[1]?) license. So the restrictions do apply to "a private group of people" too.
The crux, and what has people up in arms I think, is the overreach of Google's peoposed licensing policy to cover not only their own app distribution ecosystem, but all others targeting Android.
Many technical users of Android consider it to be a general purpose computing platform, and they want to retain the freedom to install and run whatever software they trust.
Google should focus their supposed concerns about regular user's safety on the user-hostile apps that they allow to exist in their own app store, rather than grasping for broader control that they'll "probably use at some point but only for good things like user security".
1: https://f-droid.org/en/2025/09/29/google-developer-registrat...