HHVM will stick around simply because Facebook has the resources to maintain it by themselves for only themselves indefinitely if they need to. Agree about the "vibrant communities" part though.
As a heavy React Native and Flow user for years, the disadvantage of projects such as those is that they actually are pure and true open source Github projects in the original meaning: The owner produces something for themselves and then shares it.
What is the disadvantage then? Well, it is not a product, meaning the external users are not the main target of the project.
The project owners have no incentive to implement anything they don't need themselves, or to fix any bugs that don't impact their own developers. It works fine if your own needs happen to be as close as possible to the ones of the project owner, if you patch stuff you need yourself, and if you don't expect anything from the owner in general.
Especially when I compare Flow and TypeScript (I use the first quite heavily, the second occasionally, filed lots of bug reports for both) the difference between them is quite substantial. For TS Anders Hejlsberg himself answers bug reports, and they listen to what the community wants. In the Flow issues you'll find Facebook employees - but not the actual owners (or if there is one they remain hidden). If the Flow team implements something Github users ask for it's almost always only because the need for it happened to also developed inside Facebook.
I have learned the hard way that "open source" is not sufficient, it should actually also be a product (meaning the owner cares a lot about external opinions). That's most important for things like core libraries and tools like those add-on Javascript type systems, not so important for "leaf node" dependencies in your project, like a library that does something specialized.
> I have learned the hard way that "open source" is not sufficient, it should actually also be a product (meaning the owner cares a lot about external opinions).
There are open source projects that succeed because, aside from being good enough, they also have big corps behind them: TypeScript, Dart, Go, Flow, Kotlin, etc.
But there are also open source (often free software) projects that succeed because they're great and are community-focused and community-supported: Python, Haxe, Julia, etc.
Ah. Ok. Thank you. I see my reply was sloppy --- sorry. It seemed to me that you were suggesting that being open source plus being productized was required for project success, and my thought was:
1. wait, there are more axes than just license and productization, and
2. there are other values on those axes that can lead to success (not just open source + productized)
Here are some separate axes I see:
* open source (Apache2, BSD, MIT) vs free software (copyleft (GPL, LGPL))
* corp-backed vs not-corp-backed
* community-driven vs closed-style-development
* core devs have a very solid vision of project direction, vs being more open to change and/or direction taken from contributors
* amount of productization: are the main target users the core devs themselves or external users
* overall quality of the language
Some armchair comments:
+ you risk lock-in by going with corp-backed languages
+ you may see more community involvement with free software projects, whereas more corp involvement with open source
+ high productization often means a very low contributor to user ratio
+ although quality doesn't necessarily win, it sure is nice.
> (meaning the owner cares a lot about external opinions).
I actually like this about FBOS. I’ve found that I appreciate their vision and direction on the projects I use (React particularly, I love their stewardship there, but also Relay, where yeah issues and suggestions are ignored but that’s fine because I like what the team does and the slow pace). I appreciate that they’re not pulled this way and that way by the community and its whims. That’s why I don’t dig Apollo for example, which seems to be one of these community projects that almost exists more for the community than for the product and tries to be everything to everyone and in the end is not something I appreciate technically or even as a community. Of course Relay docs suck but hey it’s open source! I’d rather use a really strong product like Relay than a weaker product like Apollo, even if it means having to learn some internals.
But they recently got better as I found out a few days ago! Yes those docs often miss some critical ideas/apis/etc. and everyone on the issues seems to already know about somehow and how they're supposed to be used.
I think the core document is the Runtime Architecture[0]. After that, it really helps to know ES7 Observables, which I learned by studying the little implementation that's included in Relay[1], but apparently is also at the core of Angular. Then you can either use the runtime architecture directly, or the pre-built React components that are included in Relay. If you use the pre-built components, you need to understand the division of labor between the QueryRenderer[2], which fetches data from your server and puts it in the store, and FragmentContainer[3] which lets you render data from the store with React.
IMO the only company that has been able to successfully "productize" a language/programming environment is Microsoft, and that is because companies were paying a LOT of money for these tools a decade or two ago.
You're overlooking Borland, Metrowerks, Micro Focus, etc.
If you're thinking of companies that are still making shit-tons of money productizing programming languages/environments today, Microsoft is the major player, but it's a battle even they are losing. They just open-sourced .NET, their programming bread and butter.
So it will either die off quickly or be extremely popular and stick around for 20+ years?
VBScript is just as old as PHP and was the primary scripting language on Microsoft products for a solid decade. It was in everything from Office to IIS and still ships with every copy of Windows.
Silverlight is just a framework and was only in active development for 5 or 6 years before being killed off.
You can write a single piece of code that's valid C, C++, C#, and Java but that doesn't make them the same language or subsets of one another.
VBScript started out using the same conventions as VB and a subset of the syntax but it was never really related to it beyond that. There are different flavors of VBScript as well. CScript is a console variant, WScript for window environments, and ASP for IIS Web Development. They're mostly compatible but not entirely. When classes were introduced, they weren't immediately available across all the variations and still aren't IIRC.
It's all very confusing though ultimately I don't think that it contributed to the negative connotations about it. Being associated with VB was ultimately what tainted it.
Those are two different things. VBScript was the Macro language used in Office Products. There is also an SDK for VB/VB.NET for developing plug-ins and other tools that's completely different.
Visual Basic for Applications (VBA) was what is used in Office Products and that is modeled after Visual Basic 6, not VBScript. VBScript was used mostly for Classic ASP development (both front end and backend).
You could use vbscript for, well, scripting. Essentially taking the same position / purpose as batch files on windows. Pretty sure that still works. I wouldn't do it anymore, personally, but I'm almost positive it's still functional.
The thing is that the enterprises seem to be okay with them being the only user of their open source projects. Don't ask me why they then decide to do open source projects in the first place, but that's what I'm seeing.
I had a client with a proprietary programming language for data warehouse management, they had a very hard time hiring people who wanted to work on that stack from a career progression perspective.
I imagine, at that scale, that opensourcing is a big win because you can have a proprietary stack, but still hire people that already know it, or won't be reluctant to invest a few years of their life into working on it. You also don't have to pay as much for educating new hires as you would for a totally closed proprietary stack, and new people faster become productive. Hiring contractors that work with that stack on a short notice also becomes easier. For a large co, these kinds of benefits might be more than enough to justify cleaning up the code enough to opensource it.
On the flipside as I've seen from Google if you're already an attractive enough target for potential employees to pay the price of ramp-up the privacy of your stack serves to lock those employees that prove worthwhile into experience that's non-transferrable were they to explore other options. Granted G is special as anyone hiring knows but I don't imagine they're the only ones aware of and playing that game.
Open sourcing their projects is good from a PR standpoint in this climate, and if anything it's a good way to share knowledge that would otherwise be kept within the company walls with those who need it (e.g. implementors of PHP/other VMs).
Creating and maintaining a community around an open source project is a lot of work, and it's understandable if Facebook doesn't want to pour many resources into this particular project, even if they keep it open source.
> Don't ask me why they then decide to do open source projects in the first place, but that's what I'm seeing.
Because they sometimes get lucky, and people use it. Apple would probably have been just fine with everyone shrugging their shoulders at clang and continuing to use gcc, but clang adoption by others has been of benefit to them anyway, say.
And worst case, there's no major downside to open sourcing language tools.
This is unlikely at large corporations. Projects from bigcorp that get opensourced are the ones that don't contain private information and would be difficult to monetize (or are strategically open-sourced).
An interesting comment I saw today on twitter[0] points out that open source development is more of a development style than a business model. Still, styles can impact the bottom line. Enterprises can gain some efficiency in process (and hiring, as others point out -- working in NIH land without amazing tooling and products to keep you there sucks if you have an inkling of what's widely done and used outside in the open source worlds) by using the model even if they are the only consumers of the final project. You also open yourself up to including other useful open source software, depending on licenses.
I don't know about Hack specifically, but sometimes it's a dependency of some other open source project. There's little point in open sourcing code written in Hack if the underlying tools aren't available for everyone to use.
Don't underestimate the value a company puts on pleasing it workers. From what I've seen, it's often them who push for open source (for various reasons).
Afaik Etsy and Wikipedia only used HHVM for the performance win and not the Hack language on top. Since Wikipedias tech stack "MediaWIki" is heavily used by PHP companies it can't be using Hack features.
Slack came out with a blog post a few month ago, writing that they use the Hack features on top of HHVM. That is the only one besides Facebook that I know of (there are probably more)
Hack is going to be deprecated when it comes to MediaWiki, they're recommending PHP7.
"MediaWiki 1.31 requires PHP 7.0.0 or later. Although HHVM 3.18.5 or later is supported, it is generally advised to use PHP 7.0.0 or later for long term support. "
I seriously can't remember any (incredibly) widespread use of Silverlight – could you elaborate? The only instance I noticed it was with a video streaming platform.
I don't think Silverlight had a mass amount of public use (Flash and Applets were still available at the time - so there was no pressing need).
But MS really did earn a lot of bad will from their dev community who had been pushed to learn yet another framework which ended up dead.
I rarely even use my PC anymore. I basically then it on once a month to download the gigs of updates. It's interesting that Silverlight still listed at the top of optional updates.
There must be a few businesses and schools who bought into the hype and built their internal app on SL.
My previous employer sells a legal review & production solution with a Silverlight UI. I left half a year ago, but if all is well they have just finished reimplementing it in Angular.
Unless Facebook's prepared to invest a lot in community-building, Hack and similar FB projects will go the way of VBScript and Silverlight.