It’s usually a massive red flag of extreme tech dysfunction if someone was able to get buy-in to build entirely custom languages / platforms / compilers / etc.
(a) management was not competent enough to realize this is universally a poor investment and refute the project.
(b) tech leads either chose this to solidify job security and leverage for bonuses, or else the choice reflects incompetent tech leads you don’t want to be working with or inheriting code from (especially not in a custom language).
Some notable other examples:
- Danish startup Area 9, which wrote an utterly embarrasingly bad custom language called Flow, which was acquired by McGraw-Hill Education as part of some software that manages student progress in digital materials.
- Goldman Sachs famously with slang
- Standard Chartered with their own custom Haskell compiler and language extensions
- Dropbox (sort of) with Pyston (custom jitted Python implementation) that thankfully is defunct now.
So if Google or Facebook write themselves a new language (or two), I'm guessing you are ok with that? I have worked at Standard Chartered and their compiler was written by a world renown former CS professor, who also wrote the worlds first Haskell compiler. The quant code written in this language is some of the best I have ever seen on the street; certainly better than the python shops (who are using forked hacked-up variants of Python anyway). Goldman Sachs also had a huge advantage for many years thanks to their proprietary technology. Sometimes an in-house language is actually a sign of innovation.
> “So if Google or Facebook write themselves a new language (or two), I'm guessing you are ok with that?”
What gives you that impression? It would be equally (perhaps more) red flag if Google permitted this in-house, much like Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction.
> It would be equally (perhaps more) red flag if Google permitted this in-house
But Google and Facebook have permitted this in-house (Go,Dart,Hack,Reason etc). They have since open-sourced them, but these projects are still run from within. I don't see this as a red flag, these languages all have good reasons to exist.
> Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction
Google probably has the largest repo in the world, no off-the-shelf product is going to work. I fail to understand why building their own tools to accommodate their own special needs is a red flag of dsyfunction?
It’s totally disingenuous to compare general purpose languages like Go or Dart which were designed from the beginning to be general purpose, to the types of limited-purpose languages discussed earlier.
If you look upon an internal business problem and propose that the right starting point for that business problem is to design essentially a single-use language from the ground up, that is a red flag.
If you decide to create a new language as a goal unto itself or as a product, like Go, Swift, Kotlin, etc., then I’d say it’s a silly waste of time but not at all the same sort of red flag as responding to a specific business need by first building a whole language.
As for Google’s monorepo, I’m not getting drawn into more bike shedding about it. There absolutely exist polyrepo off-the-shelf solutions that would performantly handle their use case without the weird limitations of their custom tooling. Happy to agree to disagree with you about it.
Before working at Google I would have agreed with you. After working, not too sure. There's tradeoffs of course but I'm not quite as certain that it's the wrong tradeoff. Considering every similarly-sized company does the same thing it seems like it has real advantages at scale. Notably:
1. Facebook (lot of ex-Googlers, so fair if you want to criticize it as a culture thing)
2. Microsoft - they've driven mono repo on Git & have migrated Windows polyrepo flow to a mono repo one. They also gathered metrics & on the whole & users overall (30% dissatisfaction rate for completely altering the workflow over a weekend doesn't seem terrible).
3. Apple kind of. Everyone has their repo but each project submits into 1 giant repo for build purposes. Even still dependency problems crop up (team submits project A but another team forgets or is unable to submit project B that A relies on) that wouldn't in a single monolithic codebase
I work on polyrepo projects and I found the tooling to be quite lacking. Moreover it's been a giant PITA to communicate how to maintain this system to other people. A mono repo would be much easier.
If you include DSLs in what you say, then I disagree vehemently, at least as to DSLs.
For larger programming languages, it depends. Mainly it's a very long-term commitment. It requires having a strong commitment to funding a team to develop, maintain, and support it. Is that a good idea? I don't know in general. In specific cases it may be an absolutely brilliant idea, though I suspect in most actual cases it's a terrible idea mainly due either to inadequacy of the business case for the proprietary language, or inadequate funding. In order to build and keep proprietary a programming language for decades the value proposition in it has to be enormous -- that makes the business case unlikely, but not impossible.
Dropbox is widely considered a highly desirable place to work; it's odd that you describe it as an example of extreme dysfunction. Likewise, I think GS is generally viewed as the technically strongest IB.
I don’t necessarily disagree about Dropbox, and tellingly I think it means something that they realized Pyston was a bad direction and sunset it.
As for Goldman, hoo boy I have a bridge to sell you. Goldman tech is notoriously dysfunctional. Being the best among investment banks is hardly anything to be proud of whatsoever.
By all accounts, S-Lang and SecDB were massive successes and major instruments in Goldman’s competitive advantage in the industry.
On another note, what about Facebook and Reason ML, and Mozilla and Rust? Or C#, etc etc. There have been dozens of successful languages that originated from companies.
(a) management was not competent enough to realize this is universally a poor investment and refute the project.
(b) tech leads either chose this to solidify job security and leverage for bonuses, or else the choice reflects incompetent tech leads you don’t want to be working with or inheriting code from (especially not in a custom language).
Some notable other examples:
- Danish startup Area 9, which wrote an utterly embarrasingly bad custom language called Flow, which was acquired by McGraw-Hill Education as part of some software that manages student progress in digital materials.
- Goldman Sachs famously with slang
- Standard Chartered with their own custom Haskell compiler and language extensions
- Dropbox (sort of) with Pyston (custom jitted Python implementation) that thankfully is defunct now.
These are bad bad bad signs about a workplace...