I want production quality toolchain and runtimes. That's hard. Go has a high quality library of cryptographic functions. Hard. Go has a fast usermode thread scheduler with preemption on many platforms. Hard. Go has an incredibly low latency GC that doesn't need much tuning for most workloads. Very hard. Some of those hard solutions are self-inflicted by the choices made in the language, but the fact that they are solved so well is what makes it valuable. A mediocre implementation of Go would have less value. A mediocre implementation of a random language with a tiny ecosystem by comparison would be even harder of a sell.
I am by no means trying to say that Nim is low quality or not interesting for anyone. In fact, I actually think Nim is cool. It is not the only other smaller programming language I like. I have a strong affection for Zig as well. There are unique properties that make these languages desirable. Zig comptime is really cool for example. I like stuff like this.
But: I also think Go is a great piece of production-quality software. I know many people hate the language now, especially now that the honeymoon has thoroughly ended. But I still like it. I feel highly productive in it, the ecosystem is good, and at the end of the day, I know I can make reliable and fast software in it.
Corporate control is a shame, but the truth is that corporate control is not the problem at all. The problem is funding. Because anyone can fork Go, but can you pay maintainers? Can you run the CI, the website and playground, host the CDN with the downloads? Etc. Sometimes the answer is yes, especially with how much GitHub subsidizes a lot of those things, but in general the answer is no.
"Corporate control" is not the problem itself. Governance is just an outwardly visible consequence. The true control comes from maintainership and stewardship. Because if nobody is stepping up to the plate to take that role, then whoever is doing it today effectively has control over the project.
This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything.
The more developers who give me grief on some principled basis that "<megacorp> bad, so everything related is bad", the more I double-down on my position. These non-technical arguments are read as desperation and incompetence from my perspective in 2023.
I've got a toy language I've built at home for my own reasons. Lots of developers do.
The difference (especially in these modern times) between my toy and Rob Pike's toy is that Rob is paid by Google to develop it, hammer out the details, work out the bugs, and support it. As are the whole team Google dedicated to it.
Some languages get supported by volunteer armies (Lua comes to mind, last I checked), but TypeScript, Go, and Rust are supported / maintained by corporate money and it's hard to compete with that because a corporation can throw money at a language that isn't done yet while it's harder to get volunteers excited about a broken toolset.
The JVM showed that a runtime can host a multitude of languages, compile to multiplatform bytecode that require only a "small" runtime (the core of the JVM is pretty simple, the complexity is on the stuff on the edges, like the stdlib) to run on anything and can be ported easily to any architecture. WASM is the new incarnation of the idea and if the people behind its specification stop worrying about politics and start getting stuff done, I am almost sure it will become the new "universal" runtime.
Usually, new programming languages have a huge mountain to climb in terms of libraries that are required for everything these days (encryption, multiple data formas like YAML, JSON, XML, TOML and even the old ones that are still widely used in niches, like ASN.1... HTTP, Database Drivers, logging, monitoring, graphics, mathematics, the list goes on and on... we don't really want to rewrite all the stuff that exists... but interop between languages is very hard and sometimes very inefficient unless it's based on a common set of primitives (like Java bytecode... WASM still needs a lot of features like GC and interface types to be a real alternative).
Zig and other languages that have very good and easy interop with C work around this problem. But I think that the future will be a universal runtime, maybe WASM, maybe something else that doesn't exist yet (or that's not yet known to most of us).
GraalVM has Truffle, which is an API for creating languages. If you use it, you get a lot of features for "free". All you have to do is write an AST interpreter. I wrote about it a long time ago here:
https://blog.plan99.net/graal-truffle-134d8f28fb69
Misc things you get:
• Advanced JIT compiler with support for static and dynamic typing, multiple CPU archs.
• Advanced multi-threaded portable runtime.
• Several cutting edge garbage collectors (you don't have to use them).
• Native standalone single binary for your language's interpreter/jit.
• Interop with other languages! (call into js, python, ruby, java, kotlin etc).
• Can also call into WebAssembly and native code compiled with LLVM, your JIT will optimize across the boundary.
• Can implement your language stdlib in any other language (see interop) meaning programs written in your language run on every major OS out of the box.
• Profiling support.
• Debugger support (chrome devtools).
• Sandboxing.
• Heap snapshotting.
• Code coverage support.
• Some Language Server Protocol support.
Probably more I forgot about already. It's really a pretty amazing generalization of the JVM and drops the cost of creating competitive new languages through the floor. IDE integration is the weakest part, but as you're writing your AST interp in Java, making a converter to the IntelliJ PSI AST API isn't much more work so an IntelliJ plugin would be easy. And IntelliJ is itself open source so you can fork it to make a dedicated language IDE if you want.
Here's an example (1) of a compile time object to key value layer I did without macros. It's a basic wrapper to split an object's fields into separate key-value pairs for storage. The problem is that the storage system only has 16bit ints for keys which makes collision a large possibility. So this wrapper checks at compile time that there aren't duplicate keys.
1: https://github.com/EmbeddedNim/nephyr/blob/main/src/nephyr/e...
Maybe we overestimate how much corporate backing is required to make a language a success. After all we had successful languages and ecosystems long before any corporations became interested in funding such things.
You mention golang's crypto. Is it true that all that code is native to the go project or are they mostly just wrapping other open source libraries which have been created by 3rd parties? Any open source language could do the same without massive investment (many have).
I would take the go TLS implementation over, say, openssl (which is what many/most other languages end up using) any day of the week.
C was corporate, AT&T.
C++ was corporate, AT&T.
Java was corporate, Sun.
Maybe Perl wasn't corporate. Had a great run but faded.
Python? Maybe, but Guido van Rossum worked at Google and Dropbox for many years.
Ruby? Is popular because Rails, corporate.
JavaScript? Mozilla.
It depends on what "success" means but I can tell you for a fact even marginal languages, in the grand scheme of things, it is very very expensive to run infrastructure that is well oiled and usable for the modern programmer that they can rely on, unless you are careful. You may not have many of the same luxuries others have. The demands are generally high, even if users of smaller languages are more forgiving.
I used to help run Haskell.org. I think people would hardly call it a top 5 language or anything with a gazillion programmers. We didn't have the luxury of designing our systems around infinite free GitHub bandwidth by exploiting Git repositories or anything like that, back when they were designed; so we had to stick with what we had, which was "A server running a daemon we wrote that stored files on the filesystem." Hardly "corporate" in any sense. It still used many dozens of terabytes a month on bandwidth for the package system. The only reason we were able to handle that is because CDNs like Fastly can eat the cost for us, for free, and because we got major free tiers from hosting providers (RIP Rackspace) to provide the servers. It can easily run into thousands of dollars a month for things like this, and that's before you get into assholes who try to ruin things by making it even harder. Oh, and I'm not even counting the actual money spent on the engineers, in terms of hourly wages, spent on this. I worked for "free."
The rise of integrated CI systems in particular, in most software projects, has had a tremendously positive effect, but one of the externalities associated with this is that they demand tremendous resources from upstream systems like this.
> After all we had successful languages and ecosystems long before any corporations became interested in funding such things.
People really need to understand that "the passage of time" is a real thing and has many consequences. It turns out the world is not the same as it was 20 years ago or 40 years ago. No amount of denialism will change that. The CI system demands are a good example of this.
> Is it true that all that code is native to the go project
Yes, the cryptography libraries for Go are written by experts on the Go team. Anyone can write a cryptography library and even have it work. Not everyone can write a library high quality enough to ship to billions of people as the default in a language with a good API, rigorous quality control, and active security review. That is what Go offers, it's not just a simple piece of code.
> Any open source language could do the same without massive investment (many have).
Sorry, but you're wrong, and it frankly indicates to me you have no experience in this, unless you simply believe that people's time and engineering effort isn't valuable or worth money. Can I ask what programming languages you have helped design and run the infrastructure and developed community libraries for? Because I dislike Go as a language for many reasons but you can't get away from this. The native crypto stacks for e.g. Haskell took years to reach relative maturity, same with Rust. Those projects weren't marginal, many people believe them to be very important, and people worked actively on them. Unless you simply believe "multiple talented people working for years on something of critical importance" isn't equivalent to "a massive investment", in which case I simply don't know what to tell you. It's a hard project. There is no way around it.
Those "high quality library of cryptographic functions" you mentioned?
Well, thanks to one Google employee, it is impossible in those "high quality" cryptographic functions to, say, disable in any way specific algorithms...except by modifying Go's source and recompiling it.
This is (and I wish I were making this up) because said employee has decreed that TLS/1.3 and all the algorithms in it are the best thing since sliced bread (guess who was on the committee working on the TLS 1.3 spec!) and it couldn't possibly be insecure. Because, you know, history is not rife with examples of cryptographic functions (and perhaps more frequently, their implementations) being discovered to be vulnerable (in some cases, purposefully so thanks to NSA subterfuge.)
Further, they stated that even if it were discovered to be insecure? Well, Google will just either fix it or disable the insecure part, and release an update, and if you can't apply that update in a timely fashion, you have "bigger problems":
> Finally, about (removed) third point: if a security issue were to be found, we would publish a small security patch for all supported releases, like any other security vulnerability. A deployment that can't apply those timely has a bigger problem and won't be saved by TLS cipher suite configurability.
Because when you wake up in the morning to a TLS/1.3 vulnerability reported in The Reg and go "oh shit", it's clearly not faster to push a configuration file change or change a bit of your own code to immediately disable the affected algorithm...than it is to wait for the mitigation to make its way through Golang's release process, get picked up by the distro you use and wind its way through that release process...all the while you're vulerable, and have been for weeks or months because Google bribes people to keep their mouths shut via the bug bounty program and/or 'responsible disclosure' policies.
Because production environments always have the ability to push out new versions of a core package.
Because it's never easier to push out a configuration or code change, both technically and administratively (ie change control.)
Because it's not often easier to validate and if necessary roll back a configuration or code change versus a package change.
Because clearly every organization that uses Golang as part of its infrastructure has the technical know-how and infrastructure to grab Go source code, modify it to disable a crypto algorithm, compile it, and package/distribute it.
Because there's never a delay between when a vulnerability is discovered by blackhats, discovered by whitehats, reported to the project, mitigation makes it to release, the distro's package maintainer gets around to creating/modifying/applying the patch to whatever version they're actually still distributing, testing that / getting it signed off on, and pushed to update channels.
So, there you have it. One ivory-tower asshole who has probably rarely worked on an infrastructure team, who does not seem aware of, much less care, about the potential consequences caused by his decision...for people who are not part of the same organization that maintains the programming language.
I'm sure that if you work at Google and a problem with TLS/1.3 or Golang's implementation of it are discovered and reported to Google, you can count on that fix being made and deployed across Google's infrastructure almost instantaneously.
The rest of us, it seems, can get fucked and be vulnerable for days or longer.
"My response to the plea in this article is simply "No thanks." If Internet Explorer gets that bad, I'd be happy to use "works best on internet explorer" banners, or migrate to another browser, or whatever needs to happen. But until then, I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen. I want production quality websites and animations. That's hard. Internet Explorer has a high quality library of windows-specific functions. Hard. Internet Explorer has a fast browser which leverages windows-specific optimisations great. Hard. Internet Explorer has an incredibly liberal interpretation of web standards, making other browsers break 99% of the time, affecting most of my target users. Very hard. Some of those hard solutions are self-inflicted by the choices made in the browser, but the fact that they are so ubiquitous and integrated with the microsoft ecosystem so well is what makes it valuable. If the web standards are missing the many lovely MS-specific extensions of Internet Explorer, a more standards compliant browser would have less value. A standards compliant browser with a tiny user base by comparison would be even harder of a sell.
I am by no means trying to say that Netscape is low quality or not interesting for anyone. In fact, I actually think Netscape is cool. It is not the only other smaller browser I like. I have a strong affection for Opera as well. There are unique properties that make these browsers desirable. Netscape addons are really cool for example. I like stuff like this.
But: I also think Internet Explorer is a great piece of production-quality software. I know many people hate the browser now, especially now that the honeymoon has thoroughly ended. But I still like it. I feel highly creative in it, the ecosystem is good, and at the end of the day, I know I can make reliable, flashy websites in it.
Corporate control is a shame, but the truth is that corporate control is not the problem at all. The problem is funding. Because anyone can try to deviate from web standards and implement windows-specific extension hacks in other browsers, but can you pay maintainers? Can you run the CI, the website and playground, host the CDN with the downloads? Etc. Sometimes the answer is yes, especially with how much SourceForge supports a lot of those things, but in general the answer is no.
"Corporate control" is not the problem itself. Governance is just an outwardly visible consequence. The true control comes from maintainership and stewardship. Because if nobody is stepping up to the plate to take that role of introducing microsoft hacks in browsers, then whoever is doing it today effectively has control over the internet."
When your compiler/editor didn't call back to some corporation every time you compiled code?
When our package managers weren't linked to data aggregators watching our every move?
When we used free tools to build free software.
Yes, now. I also remember when they were not free.
> When your compiler/editor didn't call back to some corporation every time you compiled code?
Yes, now. Just do not use Visual Code.
> When our package managers weren't linked to data aggregators watching our every move?
Yes, now.
> When we used free tools to build free software.
Yes, now. Just do not use Visual Code or Github.
Post 1990 or so the FSF came out with gcc, gcl, etc. Since then there are free languages like Python and PHP. However, many open source projects are "corporate dominated" for better or worse. LLVM would not be the quality framework it is if Apple hadn't invested in it. Linux got SMP scalability thanks to IBM. No Google, No V8, No node.js. A language like Nim might have no corporate sponsor now but if it catches on it may very well get one.
I certainly do remember the main options being: buy commercial software, download an inferior freeware, or go through a huge effort setting up emacs to be a low quality version of one of the first 2.
Oh, and now it's ok/expected you don't have to use windows for everything, because that was the case for a while.
IMO, it's never been easier to use excellent software while avoiding corporate bullshit, so I'm glad we're not back then anymore.
Edit: FWIW I'm early 30's programming for about 15-20 years of those (arguably!)
If you use compilers/IDEs from megacorps when there are so many great alternatives, you only have yourself to blame.
I haven't heard of this before (other than TFA's bare question-raising). Do you have an example?
I'd imagine having the data lets you detect/fix issues faster and flag malicious packages much easier.
The economics for corporate controlled open source are quite clear. It's a cost saver for corporations to open source solutions to common problems. This gets others to buy in, which spreads maintenance costs and ensures that no one is seriously winning in the domain of the project. Essentially de-risking cost/benefits in the domain of the project.
Another problem, which the author didn't discuss, is that corporate controlled software is often designed by a committee, or designed by those with political capital within the corporation. There is not usually a strong selection mechanism for good system designers, or good open source leaders. Go is a happy and rare exception. Projects coming out of corporations are often not as well designed as projects which rose to prominence organically through differential amplification by the community.
Look at through a lens of scarcity. What Google sells that is 'scarce' is not the Go runtime - it's ads and other things.
But an independent open source project doesn't really have a source of 'scarcity' that it can sell.
https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
Of course, in an alternate timeline where the government successfully funds public/"open source" software, this post would be titled "Stop Building on Government-Controlled Languages".
Look at what happened to NSFNet and how it's no longer a network that's open but now a part of a large, billion/trillion dollar oligopoly with no obligation to serve anyone who won't make them a profit.
Freemium format. It floats the WordPress plugin ecosystem. That ecosystem has $1 bn size. Likely larger now since that statistic was made 1-2 years ago.
You give the base software and most if it free. You provide paid addons for niche, corporate, business use cases etc. Everyone is happy - the userbase gets their software free, advanced & business users have advanced features that could not have made it into the main software in addition to having paid support. And most important for everyone - the project & its organization can sustain itself and it can keep maintaining its software.
That said, I see its value. We use it at my company.
TypeScript is open-source but created and (I think) pseudo-owned by Microsoft, which has had terrible ethics over the years, including the 3 E's [1]
[1]
""Embrace, extend, and extinguish" (EEE),[1] also known as "embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] that was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors."
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
I am open to the possibility, that Microsoft changed, but this example is a classic "Embrace, extend, and extinguish" tactic by my understanding.
Linux is strong with developers and certain tech, but by incorporating Linux, Microsoft makes devs have many good sides of linux, but with all the nice proprietary windows extensions. So they stay on windows.
And that means less devs switching fully to linux to struggle with drivers and co. meaning less solutions there, so even more devs stay on windows and just use the Linux goodies.
Effect extingushing remaining linux users on the desktop.
But of course, they offset that very effectivly, by making me fight their system to not show me advertisement, track me or update at a very inconvinient time for example. Which is why I still love linux, aside from bugs, it does exactly what I want and when I want. I am in control. With windows I feel like I am renting something, where the contract and services can (and sometimes will) change any moment.
Before or after they were shaking down Android OEMs over FAT? Microsoft didn't change, they're just operating in a market where they can't get away with as much.
It's like the mob boss deciding there is money to be made working together so he stops trying to have you whacked. It's certainly a better position to be in but not one that engenders trust nor should it.
This article is pretty much expresses the answer I give.
I'm happy to use languages funded by corporations - the incentives for them are clear, they fund development and work on the tooling and spec for their own use-case - they garner additional support, momentum, and goodwill by releasing the language under an open definition (and sometimes also release an open version of the tooling around the language).
I don't really know what the author wants from a package management tool. At least personally - I fully expect it to communicate with the package host provider, and for them to track information about what I'm downloading... It's a network based tool that fetches remote resources someone else is hosting (usually for free).
Decent package managers will also support self-hosted repositories, and allow configuration for 3rd party repositories.
I also don't find this sort of tracking particularly malicious... not any more than I would find it both reasonable and sane for a store to be tracking how many customers they get a day, and to pay attention to what their hot-selling items are.
Further - GCC is absolutely and example of a corporate provided language being adopted and tooling developed outside that corporation's control. Not sure what the author is smoking... but C was developed under corporate control at Bell labs of AT&T. Further - there's still a wild amount of closed source tooling around C that comes out of Microsoft, and is absolutely high quality (and not cheap).
Mono is an example of this for C# - Corporate language, open implementation. Javascript was developed by Netscape (another corporation) and now has dozens of different runtimes. Some open, some less open.
----
Basically - What the fuck is the author talking about?
"Admittedly C also came from a corporation but it came free with every unix install and soon after I started using it, Richard Stallman et al. gave us GCC, a free C compiler."
But at the time AT&T couldn't spy on its CC users though so the risk was lower I guess.
Sure they could... What do you think there were doing when they were selling System III & System V?
They compiled customer lists, and sales contacts, contract agreements and everything else you'd expect from an org selling commercial software. Was it "automated" in the same way that tracking use from a package manager is? No. Was it tracking? Fuck yes.
Unix wasn't free until the FSF began the GNU project...
Hell, even the BSD variants of unix were sold - they weren't free software. Are there free implementations that exist today? Yes. They exist because the item being sold and maintained by the corporation is NOT the spec for the language/os (the recipe) it's their implementation of it.
This is substantially less than what code running on your machine can do, which is basically unlimited its spying capabilities. Yes, this is a problem in itself that needs to be fixed.
Otherwise you appear to willfully misunderstand. These may not be your priorities, but taking offense and framing them as "crazy" does a disservice.
So make your own Go compiler & package manager and stop complaining? The language spec is open.
Or if putting your money where your mouth is feels too hard...
Use an implementation of a corporate sponsored language that has free and open tooling around it... ex: GNU C/G++
Or fuck it - use the GCCGO compiler... https://go.dev/doc/install/gccgo
Because it turns out if this really is your priority - there are active ways to handle it because, despite being corporate sponsored, the language definition is still open...
I believe the cause of Mono's death was a combination of MS buying out the company where many Mono devs worked (Xamarin), and the huge rearchitecting MS did for .NET Core. The latter being something that on paper sounds great for openness and cross-platform support—but in practice, it hasn't turned out that way. The .NET team is mostly MS and they still play favourites with Windows (and increasingly Android, which is fair) and Visual Studio.
I would also draw a pretty clear distinction between C# the language, and something like WinForms.
And that's really the whole point - implementations differ in functionality exposed and features worked on (hell - just the compatibility issues and differences between clang/GCC/MSVC is a great example). The corporate implementation is usually the most feature full because it has the most resources poured into it.
That's not a problem. That's the community being able to take advantage of those resources. If/when the company stops being a useful partner, they're free to ditch them and fork (and this is historically how things like Linux/OpenBSD/Gnu tooling exist...)
So again - if you have a real problem with using the corporate release, use the open versions. Contribute to them.
But I don't find it a compelling argument to say that just because a language is sponsored by a company we should avoid it. Doubly so if the corporate version is licensed well.
Golang and Android Studio are both open source, and you could compile them yourself. Telemetry can be turned off in Android Studio, and you can use stuff like flatpaks to isolate the software from your system, and completely turn off networking permissions if you don't trust the settings.
Reproducible builds help, but once you are going down this path of verifying instead of trusting, then it doesn't really matter who built the software.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
I think this argument is better had for frameworks and JavaScript libs. Have caution about who you trust, especially in this new phase of everyone pivoting around AI/BI applications
Maybe I’m just bitter, but I’m on my third “open source” text editor because of machinations inside megacorps suddenly deciding shutdown perfectly fine projects.
So it basically goes back to what the OP argued, right?
Also, similar concerns would exist for non-corporate software, so the corporateness is irrelevant to whether to use a free tool which you have full ability to inspect and compile yourself.
So what’s the problem? There doesn’t appear to be any risk here.
- The corp still doesn't need to take direction, nor input, nor patches from the community.
- The corp can steer the language and frameworks wherever they want. Sure, you may be able to then fork it, but is that fork going to gain any traction? Probably not.
And it definitely will not work on that corp's Official Operating System platform.
>The corp can steer the language and frameworks wherever they want. Sure, you may be able to then fork it, but is that fork going to gain any traction? Probably not.
These both apply to not-corporate projects as well.
When I started in software development in the late 90's, avoiding proprietary software was a best practice. SQL - great, open, use freely. TSQL and PL/SQL - avoid because of MS and Oracle.
If I’m concerned about spyware, then my language and compiler are low down on my list. My OS, my phone, and my network are far higher on the list.
To me, the most promising newer languages all attempt to make automatic memory management faster, more predictable, and more scalable. That’s what I think is so compelling about Rust. Koka is a promising upcoming language as well, and there are many others in this space.
Besides the JengaFX people, who else is using this language?
Odin has a sophisticated PP system, which supports something like dependent types last I checked.
Odin's context system is excellent. It is similar to implicits in Scala, but Odin's is by far the best implementation of the idea that I have come across. If Go wanted to make context part of the language, they would do well to understand Odin's context.
Odin doesn't do OOP. Zig does. I don't know why a C replacement would try to.
As far as leadership, Andrew (Zig) is the better open-source leader. He's better at engaging with the community, attracting people to his cause etc. But as far as a language designer, GingerBill (Odin) really "gets" it. If you listen to him talk about language design, it's very clear he's given it much more consideration than pretty much anyone.
Simply because ownership is power. Power in the hands of individuals is harmless as it is mostly Brownian motion; on the other hand, power in the hands of huge corporations (or governments) can turn nasty very quickly.
This is the reason I stopped using VSCode even if the tool is very good.
Ownership is too important, with heavy long-term political consequences to be ignored or traded for short-term convenience.
Basically, anything running "in the cloud" or slowly converging to run there should be a red flag.
Without being paranoid or a luddite, you can do everything with mostly local-tech or at least diversified enough to avoid giving too much power to a single actor.
So you’re not going to use the tools that you think are the best and most productive and instead depend on the kindness of strangers volunteering in their free time?
And before you cite “Linux”, look at who the top contributors are - all corporations.
Yes and how deep down are you willing to do everything on your own and does it give you a competitive advantage - ie “does it make the beer taste better”?
If you think this is insane or don't understand the viewpoint, I refer you to the fable of the wolf and the dog. https://fablesofaesop.com/the-dog-and-the-wolf.html
That is true but no single corporation has control of Linux. Linux (the kernel) has managed to harness corporations to fund developers so they can work full time on it without giving said corporations "editorial control" over Linux.
Individual corporations that pay Linux developers have some influence over the type of things that are worked on (by paying people that specialise in some parts of the kernel over others) but they don't get to decide what actually goes into the mainline kernel.
Unfortunately the same isn't true of most languages where there is often a single corporation behind it.
The answer is not always open source, even if I think that the contribution of open source to the overall ecosystem is both positive and invaluable, as it clearly empowers individuals.
The dangerous trend is concentration of everything. We don't have to use every services from Google or Apple etc.
I only use Google Maps from Google, nothing else. I use iOS from Apple, but I barely use my phone these days.
We need more diversity to have less corporate control, increase healthy competition and mitigate the political risks.
Definitely one area we don't have to compromise principles.
It's also important how its distributed, if in a main distribution at least a pair of eyes or two have looked at the source.
Is there an implied "I don't trust the phone-home features of package management systems supported by corporations" that doesn't apply to non-corporate-supported development ecosystems? Why is that?
The problem is not only that the tool connects to the networks, but who is behind the tool. Google is a company whose business is collecting all the information on people it can. I don't think those in control of python/pip have the same incentives.
D is the most open language you will find. It is Boost licensed, which has the least restrictions of any language you'll find:
https://www.boost.org/users/license.html
The compiler is 100% Boost licensed.
Nobody pays me a dime for D.
Terribly sorry about that. I've moved you into the list. It's been a long time now but I really did like D and its meta-programming features.
Certainly not the Oracle Language (Java)
I like the Google Language (Go) and it's BSD so maybe safe-ish?
I'm not in that ecosystem, but I'd use the Apple language (Swift) if I had to.
Maybe the JetBrains language (Kotlin) is okay?
I hear lots of buzz about the Mozilla language (Rust), maybe they have a good history of open source stewardship.
The Guido language is pretty friendly (Python) ;-)
But I'm pretty done with the Larry language (perl)
Outside of Android app development, AWS uses Kotlin for its backend systems: http://web.archive.org/web/20200706214913/https://talkingkot...
This is actually the golden age of free programming languages.
Previously, if you wanted a high quality compiler, you had to either get it from the vendor of your operating system or license one for a lot of money. Now, you have access to multiple high-quality compilers.
In addition, even if you had a free compiler, you would have to pay for floppy disks or a cd-rom. Now you can download it for free.
There is also a lot more information for learning about new programming languages thanks to the Internet.
Finally, you also have access to libraries/frameworks like LLVM that make it much easier to build your own compiled languages. For example, Rust probably would have taken much longer to get where it has, if it was not able to leverage the LLVM infrastructure early on for things such as optimizations and cross-platform compilation.
Now with regard to corporate control/backing of languages, if you look at computing history, you will see that most successful programming languages have been backed by some corporation (there are exceptions, though).
Fortran was backed by IBM. C and C++ was backed by AT&T and later Microsoft (especially for Windows). Pascal was backed by Borland. Java was backed by Sun. Rust was backed by Mozilla.
The question is not so much if a corporation backs a language but rather how it goes about building a community around the language. IMO, I think Mozilla did a very good job of building a very broad community around Rust so it became more than just a Mozilla language.
Had Borland not gotten greedy, Delphi would still be widely used.
All the tooling we get nowadays for granted was insanely expensive.
The other concern is:
> Using java for free software was the first misstep. We were warned against it but ignored those warnings. Much later the oracle/google battle showed how precarious it is to build on languages controlled by corporations.
There's certainly an argument there, but it also happens with non-corporate open source. To give an example:
- Scala (programming language) was released in 2004, as a non-corporate open-source project
- Play (web app framework for Scala and Java) was released in 2007, as a non-corporate open-source project
- Akka (actor system lib for Scala and Java) was released in 2010, as a non-corporate open-source project
- Key people in these projects form Typesafe (now Lightbend) in 2011. A company that provides premium support and tools around open-source projects, largely centred around Scala/Play/Akka
- A few months ago, in 2022, Lightbend changed the Akka licence, made it proprietary ("Business Source Licence") and very expensive at large scale
Software that starts out as more "pure", non-corporate open-source can still turn the tables on you and charge large licensing fees later. But at least if it's open source from the start, it can be forked, e.g. for Akka, there's this Apache fork that was started after Akka changed its licence: https://github.com/apache/incubator-pekko . This is the key open source protection, and it's true for both corporate and non-corporate projects - if the maintainers start doing things people disagree with, anyone can just fork it.
Not so applicable to Go - ppl mostly use it for writing servers running on Linux.
Java used to be backed by Sun Microsystems, but now it's really open source. Nowadays (iirc) Oracle and Red Hat are the main contributors.
I disagree that Java is an Open language. Experience says otherwise.
The proxy has a clear privacy policy: https://proxy.golang.org/privacy It collects anonymized usage metrics like other package registries (rubygems.org, nuget.org, crates.io) do.
Exactly, there seems to be a high level of paranoia with some developers about any software that "phones home".
I can see possible fears stuff being sent in crash reports if you are working on highly sensitive software or really worried about IP theft, but other than that I don't think telemetry in products like VS Code is sending the contents of your hard drive to Microsoft. They use that limited information to improve the tooling, which benefits everyone.
Maybe I'm just getting old and tired, but I leave it on and am not overly concerned with it. I used to be a lot more critical of things like this, but everything is so interconnected these days it's not worth the battle. Besides, I'm sure every megacorporation already knows my entire life story by this point with all the really invasive tracking that goes on on the web and on my phone.
I totally agree with this. This "phone home" scenarios aren't rummaging through your file system or reporting back what websites you are visiting.
It almost seems like there is an underlying level of paranoia, or people are working on extremely sensitive stuff that they are concerned will be reported back or caught up in some poorly anonymized telemetry reports. I personally leave telemetry on and am not concerned with it. If it helps improve the tools I am using on a daily basis, go for it.
This is different than the analytics on the web which know everything from what food I like to what music I listen to and a lot more. We're talking performance metrics and stability issues, not what I may want to purchase today.
wut?
"I am sure it will be phoning home about all sorts of things." is 100% true in case of Android.
https://tsdr.uspto.gov/#caseNumber=75026640&caseType=SERIAL_...
The standard: ECMA
https://www.ecma-international.org/publications-and-standard...
The implementations: browser vendors, Npm, and many others
Cheap maybe. Turbo Pascal was 49.99. Linux was at 0.01 and very few people had access to hardware that could run gcc.
I thought it will be a rant against corporate controlled languages because you can't rely on them long term. Instead it's that the ide or package manager phones home.
Well so does apt or macports?
Edit: actually Turbo Pascal predates Linux 0.02 by 8 years.
As for the concrete languages mentioned, Java is probably the safest bet out of managed languages, not only does it have a proper specification (both the language and the JVM), it can be carried forward by multiple companies single-handedly, it is that critical piece of infrastructure. Also, even from an incentives point it doesn’t make sense to put backdoors or whatever, as they themselves use it very heavily, so each big company in effect “checking” the others.
There are quite a few open-source projects and packages that I would love to be corporate controlled so that I could get some help and support that I would gladly pay for.
I agree with the main premise, having independence from large corporations, in the same way I like individual countries to be autonomous and not beholden to other countries (and one world order/government agencies like World Economic Forum can go to hell…)
I would add Python, Common Lisp, and several Scheme implementations to the list at the bottom of the article.
Nim looks like a very nice language but as a niche language it probably lacks broad classes of libraries that I would like to have available.
GCC will build from source on NetBSD, even on low resource computers. It has been quite reliable for me over the years.
Until Sun decided to create user and developer SKUs for UNIX and everyone else in the UNIX space followed, along. Only thereafter did GCC start to get really used, until then it was largely ignored.
This also ignores that WG14 participation isn't free beer and for GCC/clang to be compliant with ISO someone has to actually buy the standard documents, the free draft and final versions aren't 1:1 the same.
> GCC, in turn, allowed the development of new languages like Perl and python. No corporations in sight! We got a lot done with these languages. It's not like we are incapable of creating ecosystems without corporate "help". We have proved that, with countless projects in the past.
Perl and Python came to be didn't had anything to do with GCC, and both were at one time or another sponsored by corporations.
Nim … relies heavily on exception handling as opposed to golang's explicit rejection of exceptions
https://github.com/status-im/nim-stew/blob/master/stew/resul...
https://github.com/status-im/questionable#readme
Re: std/db_sqlite, you’re probably better off using sqlite3_abi:
As long as you're fine with whitespace-based syntax, Nim will bend to anything as well as C at least, add on top of that compilation to JS (not WASM, just plain old JavaScript), you _could_ develop everything with Nim.
Alas, I don't do that either. I still love Golang, and the extensive support and familiarity of JS on the web keeps it as my main language. Someday I'll need a program again, that'd be as easy in Python as in Nim, and where the development wouldn't benefit from the effortless concurrency of Go.
This is why there's pressure from within the Swift community to improve cross-platform support and the number of use cases Swift is viable for rather than rallying around some other more open language, and I'd assume the same is true for the communities surrounding any corporate-founded language. People flock to these languages because they're filling needs that other languages don't.
I really agree!
Elixir is my main workhouse language, I love it and the Phoenix platform as well. I also really enjoy using Nim. It's _fast_ and looks great, easy to write too.
Nim is one killer web framework away from the main stage. It will capture a lot of attention once it has a batteries included web framework. Think Rails, not Sinatra.
I wonder what the OP use to build Android apps. Perhaps simply gradle?
BTW, I use Go ocassionally for building API stuff at work, and Nim for personal projects. Since my main responsibility is building Android apps, I don't see myself leaving Android Studio, unfortunately.
<3 CL is compiled and SBCL gets us many type warnings and errors, and Coalton can get you as much compile-time type checking as you wish (Haskell-like on top of CL).
Syntax
https://github.com/vlang/v/wiki/V-for-Go-developers
Features
1) Forget how members of hacker community earn a living.
2) Tell hacker community about your favorite programming language, tell them to use it and not CorpoLang™.
3) Forget how members of hacker community earn a living.
The author does not bother to understand history about Bell Labs and why that organization is probably most true in the sense of “free in spirit “ even it is nominally part of the AT&T.
I am an ops automation person quarter-time, and I use Python for all my work.
I wish Python did not make whitespace significant.
I won't pretend I was going to learn Nim tomorrow, but knowing it is whitespace-aware takes my interest to zero.
---
Now on-topic, having RTFA, the complaint is "I don't want a corporation having analytics about my usage".
>Something I read recently and my own experiences with the golang package proxy reminded my how much I trust the golang tools on my machine, and yet how little I should trust them.
Why not? Why not trust them? What pictures of your vacation, what personal source code are they leaking?
Great title, very poorly-articulated article.
tl;dr: It wants you to use Nim for $reasons.
Of course Google could dismiss the law but then they have to pay massive fees.
Currently working for <small but influential company A> doing real time surveillance on an enormous amount of data. Using a proprietary language owned by <a competitor company B>
Technically, theres no conflict of interest because we, as a regulatory body, are a seperate business entity from the company A- but honestly what interest does company B have in addressing our concerns with their software? They arent incentivized to fuck us over nut they have no incentive to help us out either.
We are running into so many problems. And I know for sure that we could, with about a million dollars worth of billable hours in total, create a product vastly superior to cokpany Bs product. But progress marches on and were already bought in. So we just deal with the problems.