Stop Building on Corporate-Controlled Languages
blog.deckc.hair
blog.deckc.hair
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.
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.
Most of the corporations were built on free languages and ecosystems which existed before they did.
Too big to fail is not the hacker ideology I grew up with. Maybe that's gone now.
That kind of polished integration often costs money. In contrast, in the open source world we limped along with gcc + gdb for decades until Clang was able to force the issue (which was funded by Apple, Google, Microsoft, ARM, Sony, Intel, and AMD).
To directly counter your "npm + TypeScript + VSCode", I counter with "Hex + Elixir + NeoVim".
I recently worked on a project involving a couple Docker containers, one of which wraps a Postgres DB and the other extends it.
Some of the features of the extension are broken because the Postgres maintainers changed something key in their Docker image (they disabled the DB listening on localhost) and the scripts the extension generates assume localhost is accessible.
In the (volunteer, free) open source ecosystem, nobody is paid to have that be their problem to solve and so problems like that, to my observation, rarely get solved because these two groups are unrelated to each other and it's nobody's job to make sure "the whole offering" is easy to use.
(And as an ardent and frequent user of Emacs, I simply must see the config file someone claims to have put together that competes with VSCode for managing TypeScript projects. That's a hard claim to swallow without evidence; I've tried, and it's extremely non-trivial. Emacs just pulled in eglot for LSP support... Not that one couldn't self-install it earlier, but every time you have to mutate a system to one-off your own solution you increase the maintenance burden of that system.)
... I'll have to carve out some time to look at Elixir. In my world, of course, "Doesn't have a tool to compile to JavaScript that has made it to v1.0 yet" is a major strike against it, but my problem domain is specific. ;)
I’m not trying to set the wrong tone here but… how hard is it to modify a docker image that is used as a fundamental part of a production system? There isn’t someone who’s job it is to wrangle these things?
Key thing is: these two teams maintaining two separate Dockers aren't part of the same org, so there's no incentives to align either image to not break the other. If they were commercial entities driven by maximizing userbase or revenue, there would be reason for them to minimize breaking each other (especially if they were the same company; then someone's in charge and can tell one team or the other "Fix it or you're fired").
I mean, GIMP exists, but any one of a half-dozen commercial products built by fewer people in less time are easier to use and have better feature lists. It's not that it's not possible for GIMP to be best-in-class, it's that it isn't best-in-class. (And sure, dear reader, GIMP works perfectly well for you. Great!)
Given more time, I'd love to explore the idea that "most of the corporations were built on free languages and ecosystems" given how many of the companies we're talking about today seem to have some roots in C, developed under corporate control. But definitions are everything in a statement like that, so it probably would take a lot of time to sift through and ultimately convince nobody either way.
It's probably my love affair with Lisp speaking, but I really think there is space for PLs to implement 80% of production-level features with 20% effort and improve slowly as they turn out to be blockers. There's also a branding thing: users who are put off by lack of corporate funding won't be working on the ground floor of building a PL anyway. That's fine.
LLVM/JVM/WASM give leverage to both indie and corporate langs. More of those types of tools are great.
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).
Think this is a good point. Languages like Vlang, Dlang, Nim, etc... Use their interop with C to their advantage. They are not starting out in the wilderness, but can build off of the already strong C ecosystem, then add unique advantages that their userbases want or prefer.
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.
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.
A C programmer during the same time period saw almost no changes to their language or job opportunities.
Except that didn't happen at all. Visual Basic still exists.
From Microsoft (2020):
> One of the major benefits of using Visual Basic is that the language has been stable for a very long time.
(Source: Microsoft, on Visual Basic support in .NET 5: https://devblogs.microsoft.com/vbteam/visual-basic-support-p...)
As of January 2023, the latest version of Visual Studio (2022) still offers to scaffold me a new Visual Basic project!
And VB exists in other forms, too. The other day, I was coding VBA macros for an Excel spreadsheet for my business. Worked great and saved me a bunch of time.
But for most "Microsoft shops", VB6 was a dead end, and that left a lot of VB developers out in the cold. They had to reskill with the .NET stuff (significant, especially in the early 2000s), or starve.
... What?! Amazing they still have running tooling to build it, and I don't even want to know what bad surprises hide in the redistributable runtime.
There are differences, but the similarities are more than superficial. Some of my first apps were in 6, and then I transitioned to VB.NET in the early 2000s. At the very least, it pretty familiar and intuitive.
Even VBA is pretty similar to the VB.NET apps I developed in terms of OOP, syntax, autocompletion in the editor, event handlers, and so on.
Again, there are definitely differences, but there was no "[relearning] software development and getting intern like opportunities" like the comment I was replying to said, and my knowledge and experience was definitely not "worth exactly zero." It was just an evolution.
This always baffles me. It doesn't surprise me, but it baffles me. Why are so many professional developers having to "reskill" to adapt to a new language? We're not necessarily talking about new domains (that would be different, there's a lot I don't know about server administration and automation, for instance, given my background primarily with embedded and desktop systems). But a language? And a procedural/imperative language? VB, C, C++, Pascal, Delphi, C#, Java, JavaScript, Ada, Python, Rust, Go, Fortran, etc. are all, fundamentally, procedural/imperative languages with varying degrees of OO, functional, and metaprogramming capabilities distinguishing between them. Some are bigger jumps (I'd point to Rust as the biggest in that group) than others, but what "reskilling" does a programmer or developer need when switching between languages in roughly the same language family? It's not like they had to jump to Haskell or Prolog or something that was majorly different.
> Some VB apps had almost no code at all that wasn't auto generated by the platform and bound to UI elements to handle button clicks and so on.
Then they weren't programmers, so I could see them having to "reskill" (actually become programmers). But if they transferred to another wysiwyg toolkit then there is still no reskilling, just relearning (as I mentioned in my cousin comment to this one). Knowledge isn't skill, it's just knowledge. If your knowledge ends at "I know how to use this particular toolkit" and your skill is "I can do it quickly, make it functional, and make it pretty" then the skill should be transferable while the specific knowledge may not be and you may have to learn new knowledge. But the skill remains.
I not only used VB 6, I used version 3 when VBX was the only option for 3rd party components.
In many cases it was as different as using BASIC vs Pascal or even C to write CLI tools (a hurdle I jumped in high school in the mid-90s, and despite doing alot of stuff with PEEK and POKE in basic, understanding pointers took me longer than I care to admit :P)
Maybe libraries they had written to solve problems in their domain have to be recreated.
It seems like switching from Delphi to Java or Go and changing the entire ecosystem would take a bit of time to get back to making the same productivity as with the toolset one has been using for a decade?
Those are all knowledge differences, not skill differences. Programming is a combination of knowledge and skill, the skill part transfers between languages and environments very well. The knowledge, not always. But learning a new (to you) suite of libraries is not "reskilling". You're not developing a new skill by learning Java's API versus C#'s API.
A lot of professionals who work on Microsoft platforms are not like us. They're not even like Mark Russinovich or Raymond Chen, real smart people associated with Microsoft systems. They're filing clerks or middle managers or sales people for traditional companies. White collar working stiffs who aren't programmers by trade, they learned a bit of programming to automate their real job or add value because computing and the internet were becoming critical to their business, and they sort of fell into a developer role from something else. In Microsoft developer persona terms, they're Morts. And there are a lot of them, hidden in companies and organizations around the world. This was probably even more true in the 90s than today. And it was especially true of VB, which was explicitly designed for the Morts of the world.
And a Mort would be absolutely flummoxed by the changes between VB and VB.NET. VB is VB, drag some controls around, double click and add code. Its syntax and semantics are borrowed from QBasic. VB.NET is basically C# with a more Pascal-like syntax. You now have to worry about, like, classes and encapsulation and stuff. Any significant VB6 code will require considerable changes to run in VB.NET. If VB is what you're used to, VB.NET seems like intolerable change for change's sake. People toward the Elvis and Einstein side of the developer spectrum don't mind the differences; they're only as bad as, say, those between Java and JavaScript, but to someone for whom programming is a job, not a calling, those differences can be death by a thousand papercuts.
Microsoft actually caught a lot of heat for this back in the day, and people started calling VB.NET "Visual Fred" because it was so different from classic VB -- and difficult for classic VB programmers to get accustomed to.
Then they hadn't been writing batch files before PowerShell existed, either. They probably weren't programmers. Windows admin at least used to be very UI-/wizard-driven.
These admins learned just enough to be competent at the job that was in front of them. Many (not all) VB and VBA programmers are the same way.
stretch your thinking a little, it's really not baffling.
you have people who teach themselves to code as teens or younger, then major in computer science then take jobs as professional developers by which time they've been experienced in a variety of programming paradigms, and where the nature of computer science is natively appealing to them.
In some large companies they might find themselves working alongside some people who were English majors/barristas and recently took a coding bootcamp to earn a better living writing some VB. Yes it's going to be harder for the latter group to drop what they know to pick up languages with more complex CS constructs and semantics. It's entirely reasonable for a not-so-experienced VB programmer to consider themselves a professional developer, even if it's a profession that they just took up, or even if they've been at it awhile but all their knowledge is within the VB ecosystem.
I personally know developers who switched careers after Microsoft transitioned to .Net. I worked with them around 2001.
They didn't understand OOP concepts and were not interested in having to relearn everything. It felt totally unfamiliar and strange to them. Microsoft tried to make the syntax somewhat familiar, but at the end of the day .Net is an object-oriented programming language and VB6, try as it might, was not. And that was too steep of a hill to climb for them.
As if COM as used in VB6 isn't OOP.
And yes, I hopped off the .net train after 15 years of using c# and took a job writing python, and some JavaScript. I had done JavaScript before, using jQuery. Now I had to learn react. And they used MongiDB as the primary data platform. I had spent the last decade working with SQL.
And it was fine, because my skill isn't tied to a single tool.
Sure, you can write-in-C in all languages, as the saying goes. But to be a professional, and to paid as a professional, requires a lot more.
Not to mention with a community that built an alternative implementation so strong that MS ended up buying the company the emerged from it. And this was before .Net Core was fully open sourced.
I’m not worried about C# or .Net getting nuked.
I don't correct people to be pedantic or argumentative. I love being corrected and learning from others, but I suppose not everyone does.
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.
As far as I know currently the only real paid full time contributors are from the relatively newly formed PHP foundation.
Lisp - IBM, Xerox, MIT, Apple
Python - CWI, NIST, CNRI, afterwards Guido joined Google in 2000
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.
> Any open source language could do the same without massive investment (many have). What I meant by this was wrapping other open source libraries like libsodium etc. rather than implementing crypto libraries from scratch. I, wrongly, assumed golang might also be doing that.
It is true I have no experience implementing cryptographic libraries.
"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."
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...
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.
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.
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?
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...
Show me any non-corporate sponsored language that is not a toy, and is seeing serious traction. (hint - I enjoy Nim, but it's not a valid answer).
Unlike the original post implies - most of the languages in his list are corporate sponsored...
D was created at Digital Mars
Open Pascal is... an open implementation of pascal, which was created by IFIP, but most variants are dead and Borland poured a fuck load of money into turbo pascal. So both gov + corporate sponsors
Nim... is arguably not corporate sponsored, but it comes right out of open Pascal (which was) and it has trivial use at large (I still enjoy the language - I'm not about to suggest we use it at work).
Same as Zig - which is probably the closest to being a true open project in the list (IMO) but which still builds heavily on c++ tooling. (Honestly - I'm most excited about Zig, it's nice and is very close to self-hosting)
Steel bank comes right out of Carnegie Mellon (and if you don't think colleges are corporations... boy I've got news for you)
Vale... well I actually don't really know anything about this. Honestly one of the first time's I've seen it referenced at all, I'll have to look it up some time.
---
So again - WTF is the author talking about?
If he just wants a free compiler (Free as in free, not as in beer) they exist for basically any large language out there.
If he wants to control language direction and goals... well - he's welcome to write his own language but otherwise I find no compelling difference between a guiding committee/creators on what he considers a "good" language, and the company making decisions for "corporate controlled" languages. If anything - at least I can usually predict what the corporate controlled languages will do, even if it's not always what I'd like...
"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.
The lawsuit and request to take the Lion's commentary out of print came after AT&T got allowed again to take profit from their research.
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.
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.
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.
We could have C# 30 years before we did if it weren't for microsoft.
His focus is TypeScript.
Mads Torgersen has been leading C# design since version 7, more or less.
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...
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's a more difficult case of course. But I believe enterprise support and custom enterprise features/addons could help in the case of languages.
> corporation controlling at least the proprietary components?
WP plugins are still GPL. But the users can buy, download them from the original source, install them on their site, and update them from their site with one click. Coupled with premium support, this works well. Its a bigger risk and hassle to 'pirate' the plugins from 3rd parties rather than just getting everything directly from the source. (though such 'piracy' does have impact).
In any case, one organization controlling at least the proprietary, custom enterprise components is much better than the alternative.
Look at tailwinds, open source lib with saas opportunities that netted the creator millions of dollars
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.
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.
Browser plug-in author gets bored and sells out customer base is a well tread story.
Takeovers of well known packages are another.
Most of these ecosystems do not offer proper sandboxing for the things we take from them, so it’s easy for things to grow an appendage that abuses our prior assumptions.
Apache’s Java ecosystem is full of consultant abandonware and tripwires.
Not even just "get bored" but, just a plain matter of incentive. Salaries are a strong incentive against undermining your employer's work. Now, of course, there are people who are incentivized because they are altruistic and good at heart, but that's very difficult to measure. It's much easier to demonstrate aligned interests monetarily.
And in more sensitive agencies, if the government purchases software, they generally have the name and contact information of who they can arrest if the purchased item becomes or is found to be malware.
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.
Advice for choosing a text editor:
• Avoid Electron.
• Avoid custom-looking GUI toolkits.
• Avoid IDEs, unless they're highly-modular with a rock-solid, simple base.
• Avoid complicated build toolchains.
I'm using Geany at the moment, which… almost meets the third criterion, and does meet the fourth. If Geany support stops, I'd vaguely be able to make changes to it; the code's written in C, licensed GPLv2+, and it's well-documented. (If GTK2+ or Scintilla support stop, of course, no dice; I don't understand any of that area of my software stack well enough.)
Of course, there are things I want it to do that it doesn't; Geany isn't perfect for my workflow. Better than trying to write my own, though!
I really don’t think this is the critique you think it is.
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.
Corporateness is also not entirely irrelevant, since the incentives are different, and 'corporate' is highly correlated with proprietary, spyware-ridden software. Also, the author talks about corporate languages (and then throws in the tools too), which have their own different set of problems.
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.
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”?
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.
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
I don’t know about you. But I can’t seem to kick my addiction to food and shelter.
The best method based on my experience and talents that I know how to adequately feed my addiction is by exchanging my labor doing software development for money.
Which is why it's all the more important for those of us who can afford to be principled to do so.
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.
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.
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.
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.
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...
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.
Looks like that was 2010: https://en.wikipedia.org/wiki/File_Allocation_Table#Challeng...
Nadella started in 2014.
https://news.ycombinator.com/item?id=31727293
The truth is the culture at MS hasn't changed much even as the world around it has.
There are still lots of reasons to dislike Microsoft, but their interaction with open source has dramatically improved in the last 10-20 years.
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.
That is the target market, developers that want a POSIX CLI experience and don't care about GNU/Linux to start with.
Isn’t the fact that Linux is still more of a headache an argument for using a product from a company that has a profit motive to provide a good user experience?
If you dealt with an OEM that ships a computer with Linux they would iron out these issues for you. If you choose to be your own OEM you must do so. Most people complaining about Linux hardware support have decided that good support means working without issue on whatever they throw at it including the laptop they bought for $200 7 years ago from walmart and that any difficulty in installing or operating it is an indication that volunteers haven't donated enough infinite free labor on the off chance that someone wants to install linux on one of the 7 units of that model still in existence.
A more realistic expectation is that there are good range of products supporting Linux not that absolutely every machine be supported. Good support has been available including devices that ship with Linux installed for years.
But you know who has thrown labor at getting that $200 laptop to work? Microsoft and Google (Chrome OS).
It’s amazing how many more people who are willing to work for money than to work for free.
I mean, Linux was never significant on the desktop, but had and still has significant market share for developers. In University I was basically tought how to use Linux and despise Windows. Microsoft does not want that obviously.
edit: but according to this chart, linux is actually still gaining market share
https://gs.statcounter.com/os-market-share/desktop/worldwide...
Still, I don't think they are happy about SteamOS for example. I mean the absolute numbers are still very low, but if gamers start to see linux as a alternative, Windows might get a problem. And there is still a significant portion of linux only developers and not all of them are FOSS fanatics, but pragmatic, but still don't like the walled garden of OSX.
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.
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.
So what’s the problem? There doesn’t appear to be any risk here.
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.
- 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.
(Or so I suspect - I haven't ever been in that position.)
Perfect example: There are 2 Plex alternatives I know of that sort of fit this mold. One is called Emby that started as open source and turned into a closed source commercial product. The other Jellyfin which is (from what I can tell) an open source fork of Emby from before it went closed. Both seem to have picked up some amount of traction.
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.
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.
Manual memory management is possible in Rust, but is not typically something developers need to interact with. There is typically no need to manually free objects when you are done with them. You just let the system destroy the objects automatically when they go out of scope.
By deciding where to scope the variable with the destructor/drop function, you've already made a manual decision about memory management. The compiler implicitly inserting a call to the destructor does not automate the decision of when/where to allocate or free memory - its just syntax sugar over the decision that you already made. This is just as true of Rust in 2023 as it was of C++ 40 years ago.
With true automatic memory management like tracing GC or reference counting, you have no idea where the or when the memory will be freed as you write the code, and the answer will usually be different over different invocations of the same code.
> The ownership and borrowing system is a type of automatic memory management
No, it isn't. The borrowing system is completely orthogonal to memory management. You can write a function that takes a borrow, do all sorts of things with that borrow, including forwarding it along to other functions further down the call chain, and the memory backing that borrow could be statically allocated, dynamically allocated with the default rust allocator, or allocated by some custom solution like a slab or pool allocator. The code reads the same regardless of the memory management scheme because you make the decision on how you will allocate (and eventually free) the memory before you ever create a borrow. The borrow checker can help keep you from making use-after-free errors, but it doesn't dictate when, where, or how memory is freed. That's still up to the programmer.
That's not really what's meant by manual memory management. MMM almost always means things like malloc/free, arenas, buffers with pointers, etc. I would not call stack allocation "manual", and IMO Rust's system is closer to stack allocation than it is to either manual or automatic memory.
In terms of DX, bugs and ergonomics, you only really have two schemes: ones which requre some kind of free() call and thus permit use-after-free bugs (manual) and those that make it impossible (ignoring weakref and friends). Rust is not manual by virtue of no free() instruction. In the same breath, "automatic memory management" is not an exact antonym of manual.
For instance, you can still have a memory leak in Java if you maintain a reference to an object that you never intend to use again. It’s still up to the programmer to prevent this.
> With true automatic memory management like tracing GC or reference counting, you have no idea where the or when the memory will be freed as you write the code, and the answer will usually be different over different invocations of the same code.
This just isn’t true, and it would be anarchy. You know that the object will be freed sometime after the last reference to it dies. This is the whole reason to use automatic memory management.
Reference counting approaches typically go even further and free the memory immediately when the last reference is eliminated.
And this is basically what Rust does with ownership. When the object goes out of scope and ownership is not transferred, the memory is freed. It’s just that it doesn’t always need the reference counting part. But you can rest assured that it will be freed.
With manual memory management, the programmer must manually free the object, and there is no automatic method to do this once there are no references. That is what makes it manual. The programmer might forget to free the memory or they might free memory too soon and try to use an object after it’s already been freed. This is not the case in Rust.
That's manual memory management. Like I said, the fact that you didn't explicitly write the call to free doesn’t make it automatic - that's just syntax sugar. Explicitly transferring ownership involves the programmer manually telling the compiler "keep this alive." If you're the one doing the bookkeeping, that's manual. Rust helps you with the bookkeeping, but it doesn't eliminate altogether.
As opposed to a tracing GC, where you don't need decide on the scope of the value itself (just the scope of the reference), leave lifetime annotations, use std::move or the like to transfer explixitly ownership, or write out destructor/drop procedures to tell the compiler exactly how to free memory. The runtime does all the bookkeeping on its own.
> The programmer might forget to free the memory or free memory too soon and use an object after it’s already been freed. This is not the case in Rust.
Yes, it's possible to run into pathologic cases in any algorithm for automatic memory management where memory isn't freed - that's the nature of Turing completeness. No scheme for automatic memory management claims to be 100% foolproof. That doesn’t mean that tracing GC is actually manual memory management.
> This just isn’t true, and it would be anarchy. You know that the object will be freed sometime after the last reference to it dies. This is the whole reason to use automatic memory management.
That's a surprisingly literal interpretation of what I said. What I mean by "you have no idea" is that if you read a function that uses reference counting or tracing GC, you cannot say for sure if there are going to be deallocation when that function is called, even for a pure function where you know the particular input values to that function. That's because the decision to deallocate depends on the whole program state, including references to the same value that may be held by some third party library that you linked in. As opposed to Rust, where (unless you are using Rc or Arc) you could annotate that function with comments about where things will be deallocated and if you understand the semantics of the language you will be right every time. Not because you are a genius who can divine the machinatioms of the compiler/optimizer running through algorithms to automatically insert frees, but because you actually made those decisions yourself, whether implicitly or explicitly, by leveraging the semantics of the language. Like I said, this is not a new concept. You could write C++ code without any instance of new, delete, malloc, or free all the way back in the 80s.
Can we at least agree that Rust’s model prevents the following errors that manual memory management is prone to?
- Using an object that has already been freed.
- Failing to free an object that can no longer be accessed.
To me, preventing those problems is the main benefit of automatic memory management. C++ will happily let you make either one of these mistakes, and that’s how Rust is different.
I agree that Rust imposes a cost in the code to accomplish this compared to garbage collection. It’s up to the individual programmer to decide whether they think it is worth the benefits.
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.
What sort of OOP does Zig do, exactly?
https://ziglang.org/learn/samples/
`try int_queue.enqueue(25);`
Go has a pretty sane approach to OOP, with methods forming the basis for interfaces (one of Go's most powerful concepts) very nicely. But Go is not really a C replacement. I know Rob Pike said they "started with C", but realistically Go replaced Java in its niche. It's not a C replacement in the way that Zig and Odin are.
Besides the JengaFX people, who else is using this language?
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 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.
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.
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.
wut?
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
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.
"I am sure it will be phoning home about all sorts of things." is 100% true in case of Android.
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?
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.
Great title, very poorly-articulated article.
tl;dr: It wants you to use Nim for $reasons.
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
Of course Google could dismiss the law but then they have to pay massive fees.
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.
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.
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.
https://www.nuget.org/packages
... they all show download statistics of their packages.
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!)
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.
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.