This is not related to net neutrality. Typically the way things work is that your end-user ISP is connected to a "Tier 1" or "Tier 2" ISP. Then the website you want to visit is also connected to an ISP in a similar manner. To get packets from the end user to the website, the traffic has to transit over the Tier 1 and Tier 2 ISPs. Those ISPs do not offer this service for free. To lower costs and potentially improve latency, many websites are happy to connect directly to the end-user's ISPs.
Imagine that your Internet service is just an Ethernet cable that goes to a router in a datacenter. This is Apple offering to plug their servers into that router. Now you can get to their servers without going out to "the Internet" via a Tier 2 or Tier 1 ISP. That is where the word "internet" comes from -- interconnected networks. More connections is more internetting.
This is all super common. Many big companies are happy to peer with small ISPs if they're already in the same building.
Edit to add: The edge cache thing that this article is about is similar, but not quite the same as what I'm describing. Instead of connecting you to their network, they just put some of their servers in the same datacenter as your network. Even less latency!
It's not and eventually they will have to find ways to provide POSIX compatibility, it can happen through a separate compatiblity layer or a library. You don't want to break compatibility with millions of lines of already written code if you want widespread adoption. No one is going to rewrite everything from scratch, just because Google says so.
Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code? Or being compatible with Windows for that matter, which is POSIX compliant just in the name?
I think you're hugely overstating the importance of POSIX, not to mention downplaying the fact that POSIX really isn't sufficient requirement to not have to do any code porting.
> Which "millions of lines of code" are compatible with POSIX without having any Linux or macOS specific code?
Those layers would have to be reimplemented to retain compatibility.
> I think you're hugely overstating the importance of POSIX.
People generally understate importance of POSIX, just because it's old. It's impossible to get APIs perfect and you are throwing away decades of work in the name of getting APIs "right". No one is going to rewrite everything from scratch, just because the new APIs look shiny. For reference read about Unix wars[1].
> Rust is developed by a community, and was started by Mozilla. Go development seems to be de facto controlled by Google, who originated the language. I'd rather bet my non-work future on a language that isn't controlled by a huge corporation, especially one of the main players in today's surveillance economy.
Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather than who is behind it. Is there a lesson from history that I am missing ?
"Programming languages should be choosen based on technical merits, rather than who is behind it."
Considering the motivations of the language owner is a valid concern. Many people, for example, jumped on to HHVM as a "faster PHP". Then it started branching away from PHP[1]. Predictable, if you considered Facebook's reasons for having it.
I don’t know anything about HHVM, but plausibly the goal of it is “help Facebook” rather than “be a faster PHP,” and people who came for a faster PHP and are not Facebook are let down by it.
Non-optional strong types is one example where it benefits Facebook, but likely isn't great for those hoping for a "faster PHP". The blog post makes it sound like HHVM will only support hack, and not PHP, sometime in the near future.
In all three cases, Python, Go and Rust, the language and ecosystem may be in the hands of an organization, but you can probably produce code productively in it for years even if the organization went under or chose unacceptable paths.
Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof.
Personally I like Python's philosophy and the way the community is run. I like the trajectory. I understand the trade-offs. And I am sure as hell not going to teach Go or Rust as a first programming language to people who aren't computer science students. And even then...
>Go is quite unique in that it produces very independent binaries. This might make software written in it quite future-proof.
What do you mean by "it produces very independent binaries."? Do you mean that Go implements system calls itself, instead using corresponding wrappers from the OS's underlying C library?
I read something like that recently, but haven't looked into the point yet.
From my perspective, of all the languages that I’ve tried (Java, C, C++, Javascript, Haskell, OCAML, Python, several lisps), PHP, Swift), Rust is the best even without the borrow checker, and the borrow checker is just a nice bonus. Admittedly, there are many languages that I haven’t tried, and I haven’t done significant work with all of those.
>Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather than who is behind it.
Absolutely not. Technical merits are only part of the considerations.
Big companies, for example, where the stakes are higher, never chose languages on their technical merits alone. The also look at the owner/stewardship of the language, and in many case, roll their own languages, to avoid being at their mercy.
I'd say, all things being equal, yes, choose languages on tech merit or suitability to task. But look at what's happening with Java and Oracle's handling of it. I think the Google vs Oracle lawsuit is still going through appeal. Ask Google if they wish in hindsight they'd built Android on something else.
I think it's more accurate to say that not paying Oracle is what got them in court. Either way it shows that the steward of a language can be important.
The original author comes close to contradicting themselves - Python too is developed by a community, but one of the reasons for moving away is that they are "not getting the feeling that the Python community is going in a direction I want to follow". That can happen to communities just as well as it can to corporations.
There's a simple remedy to the problem of becoming dependent on a single entity wrt the programming language you choose: use only languages with "official" specs (by ISO/IEC or another respected org) and multiple implementations. That's C, C++, ECMAScript, shell, and a couple niche languages such as Ada, Fortran, and Prolog.
Probably someone from the unleashed project can give a better answer, but my understanding is mostly unhappiness about the illumos contribution process.
The illumos RTI (request to integrate) process is designed to ensure a certain quality of contributions.
The downside of this is that it sometimes takes a long time to contribute a change.
For illumos there is also pretty high expectation of backwards compatibility.
What unleashed now offers is a place to do more radical changes and quickly iterate on new ideas.
While the small illumos community is already pretty fragmented my personal hope is that in the future work done by both projects keeps getting merged from time to time.
Maybe this also serves as a wakeup call to the illumos project to make some improvements to the contribution process itself.
Google is highly influential in how information is consumed and distributed. People use chrome to browse web, google search for searching information etc. If they have major control over how information is distributed, they have major control over the web. Ofcourse there are other similar services that are not provided by Google, but they are very less influential due to lack of users.
> You should be scared of walled gardens displacing the web.
What if web becomes a walled garden ? Look at what Google did with DRM[1], even Mozilla had to give up their efforts to fight against it[2]. How could that be possible without having a major influence over the web ?
I suspect they will end up in the same situation as they did with Motorola more than a decade ago, until someone reminds them that the people who are serious about software should make their own hardware.
It will teach them a lot of lessons just like that phone stint with Motorola. There is also a rumor that partnership was just to learn phone building for Apple
[1] https://www.youtube.com/watch?v=gLt_yDvdeLQ&ab_channel=TEDxT...