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.
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").
All of those languages and their ecosystems had major corporate backing before today's megacorps used them to get to where they are.
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.
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.
If things seriously get as bad as you say, I would absolutely lie about the language I worked in / my experience. I won't feel good about it, but it's not too difficult to cram a new language/framework in a month or two and appear competent.
I would hope that people in charge of hiring aren't foolish enough to make that necessary.
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.
> 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.
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.
... 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.
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."
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.
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.