I think there's a difference between people who study lightly and score high, and people who grind it out and then score high. I'd guess that the majority of high scorers fall into the latter, while he falls into the former.
It doesn't matter, really. Its a black box from a business perspective. Some users have lost faith, and some people will migrate to other solutions. Regardless of how fair or unfair the incident was, it is a fact that it was poor up-time especially for such an important cloud provider for code.
Making decisions based on a single event is risky. One could even argue that an event of this magnitude is likely to cause significant improvements in reliability. And you just paid the price for that as a user, so unless they keep failing repeatedly, you may be better off sticking with them.
Going forward, I see that the sensible solution for all small companies relying on cloud-hosted git is to always have a secondary cloud provider at all times.
> Which brings into question... what is so special about the "front-end" features that Git provides? ... bare bones skeleton that we can swap in/out at will
Your comment disappeared. I think you had a good point. And itd be cool if it could be a real thing, but...
I dont disagree. But our team realized that we rely almost too much on github; we just decided to put up with it. Is there a solution that doesnt depend on running your own "github"? My infra lead and I had the usual, fun tongue and cheek chat that began with... them: "maybe its time we switch to gitlab", me: "can we be up tomorrow?" Weve had that same discussion many times before.
In the end, it comes down to process. If you buy into the features, PRs, CI hooks, etc, then its really hard to just say "well we can maintain and replicate the alternative for the .1% edge-case". Otherwise, you might as well just use that and not github, gitlab, etc. Its hard to decouple from github. They do that by nature -- dev still continues; they are a piece of the process puzzle. I think abstracting them away just complicates things unnecessarily.
Ah yeah, it disappeared because I thought I would get more reads If I moved it up in the post chain lol.
May I ask what makes your company feel secure about using cloud hosted solutions. I mean, can’t a disgruntled employee easily clone the git repo to his own GitHub account ? I suppose they could do that anyways, just by copying the repo somewhere, but having an entire company’s secret code on the cloud just seems to remove too many barriers of entry for protecting the code.
Quoted:
"Try adding a remote called "github" instead:
$ git remote add github
https://github.com/Company_Name/repository_name.git
# push master to github
$ git push github master
# Push my-branch to github and set it to track github/my-branch
$ git push -u github my-branch
# Make some existing branch track github instead of origin
$ git branch --set-upstream other-branch github/other-branch"
Actually, I don't know why I pay for Github private repo's.. I might as well set-up two origins, one at Gitlab and one at Bitbucket, for all my privates. Then keep Github as a public front-facing portal.
Every company at some point has some kind of incidents. It just happens. GitHub is most of the time rock solid and doesn’t deserve to be judged based on one major incident like this. On the contrary they need our support. Bitbucket and GitLab both have had problems of the same magnitude.
But a multiple origin solution seems the most sensical. We have failover for everything infra and services.. it seems we now need failover for cloud-based code. It just seems logical, especially if all 3 of the big cloud providers have big incidents.
> this disastrous calamity by Github really made me try out Gitlab and in the process
Every company faces problems like this. GitLab infamously lost their entire production database [0] -- and I think we can agree that's more serious. Knee-jerk reactions to incidents will leave you without any "trusted" services, because mistakes happen to everybody at some point. BitBucket has certainly had its own fair share of downtime.
> GitLab infamously lost their entire production database
What?? The link you posted says
> Database data such as projects, issues, snippets, etc. created between January 31st 17:20 UTC and 23:30 UTC has been lost. Git repositories and Wikis were not removed as they are stored separately.
> It's hard to estimate how much data has been lost exactly, but we estimate we have lost at least 5000 projects, 5000 comments, and roughly 700 users. This only affected users of GitLab.com, self-hosted instances or GitHost instances were not affected.
How is that "their entire production database"? You make it sound so much worse than it was. While it was a horrible incident, they did not lose their whole production database.
> Actually, I don't know why I pay for Github private repo's.. I might as well set-up two origins, one at Gitlab and one at Bitbucket, for all my privates. Then keep Github as a public front-facing portal.
You do realize that every cloned tree can be a git "repo", regardless of the machine it's on, right? GH and GL surround the repo with some other things (bug reports etc) to rope you in but if you are cloning from one to the other you already aren't migrating that stuff as well, so it's not really clear what additional value that provides.
Which brings into question... what is so special about the "front-end" features that Git provides? Why not use another third-party service that integrates into your Github/Gitlab/Bitbucket repo, storing the meta data of all the pull requests, code reviews, discussions, etc, inside a "meta repo" itself? I see this incident as an important note in taking steps to decouple important "meta" features from the cloud-host itself.
It will be better to keep the cloud hosts as a bare bones skeleton that we can swap in/out at will (Github, Gitlab, etc), and then use another layer on top to provide all the nice fancy features.
This has been super frustrating, as people have deadlines and are working to finish projects before Monday morning.
What are the (good) alternatives to Github? Gitlab supposedly is Google-backed, so I don't want to have my private code there. Is Bitbucket the only one left?
I don't mind paying monthly, which I already do for GitHub.
> Gitlab supposedly is Google-backed, so I don't want to have my private code there.
This strikes me as odd. May I ask why usage of GCP is a deal-breaker for you? While I can understand not wanting to use Google products directly as a consumer, I believe it would be - for lack of a better term - platform suicide for Google to intercept and perform its usual analytical shenanigans on the data content of transmissions to/from their platform.
Either way, Phacility's Phabricator[1] is $20/user/mo.
You're saying that you trust that contract today, or are you saying that you have always trusted that contract?
Its only recently that gmail's contract involved keeping out of your data. I think they also only say they abstain from using your data for targeted advertising, not that they don't use it for other purposes. I haven't read the terms in quite a while though and I could be mistaken.
Great products though. I really do wish I could pay for them in exchange for a real, trustworthy, comprehensive privacy promise.
Perl 5 is a great language and does not deserve any of the hate it gets. Unfortunately the dev community is always on the look for bandwagons to jump into. It's a well thought out language with a comprehensive list of features nicely integrated together, a vast ecosystem of packages, very good documentation (has the best offline docs among all of the popular languages out there, after C stdlib), and has stood the test of time.
Perl 6 is a nice experiment and may hold some ground in the future, but is not a practical tool or something in the same space as Perl 5 today. It's very unfortunate naming IMO.
Perl 6 is as realistic an option as several other new languages. It is new(ish), and still has some performance issues compared to Perl 5 (though this is becoming less a thing, and there are now several areas where 6 is faster than 5), but it has had regular stable releases for nearly three years. You can deploy it today and expect the code to keep running in the future without major modifications.
I'm not using it in production, but I think one reasonably could. I suspect we'll be able to start shipping Perl 6 code in a couple of years (my company builds installable applications, and we don't want to maintain Perl 6 packages ourselves, so we need our target platforms to have good packages for Perl 6 available before we can ship it).
It might be amazing (to some degree, it already is), but unfortunately I don't think I'll be using it for much. TIMTOWTDI is great, but like most things, too little or too much are both problematic. This wasn't always my point of view, I came to after many years of following Perl 6 development (from all the way back in the Parrot days). As the language implementations started maturing and people implementing things to show off (often for Advent calendars), I started realizing that I was having a really hard time following how each thing was implemented, because there were far too many ways it could be implemented, but in a fundamentally different way than Perl 5.
Perl 5 gives you a good set of primitives, a lot of flexibility, and then tasks you with using this mix of core types, context, and namespaces to do what you want, how you want. The actual things you need to know to reason about most code you encounter is fairly simple though, and if not immediately known to the average Perl programmer, they'll have a good idea to figure out what it is, and what the usual suspects are for really weird stuff (I'm looking at you, indirect object notation).
Perl 6 has so many core, fundamental things to know, that in any piece of code I might encounter, the number of things that could be in use is staggering. I've read the Perl 6 Synopses, end-to-end, years ago. I remember a lot of what's in there. Hell, I was really excited about those features when reading about them. When I saw them start to be put into practice, that's when it crystallized for me. Specifically, I started having real doubts when I saw Larry implement a solution for Rosetta code in Perl 6 using a sigilless[1] style. What's the point of these? Just to represent special characters, as in the example? But they're also constants, because they have no containers? And there's also defined constants, but those have sigils?[2]
Don't get me wrong. Perl 6 has some (a lot!) of good ideas. I mean, it sort of has to, since it actually has all the ideas. That's the problem. Not all ideas area good, and even if you only selectively implement all the good ideas, they aren't always still good when they are forced to coexist with each other.
At this point I see Perl 6 as a really interesting experiment to see how some of the more interesting ideas work in practice when used in a less opinionated language. I'll probably do some simple stuff in it eventually (I mean, I'm still fairly familiar with it just from following it for almost 15 years), but I don't have high hopes for using it for any professional projects, or for using it on a project with many other contributors. That's okay, I never stopped writing Perl 5, it's what I do for my day job, so I'm not missing it too much.
That said, I still have a very soft spot in my heart for Perl 6. It's an extremely quirky and wonderful language when viewed purely as a language and a thing to play with. That I think it won't ever see professional success is fine. There's lots of things in life that are great without that, and there's lots of types of success other than that to aim for. And that's totally okay.
I started using Perl again. It is a well-defined language with a good library system that's also been around long enough to have stabilized. The fact that it is so integrated into many system things help ensure that it remains stable. It's flexible, but you can still write readable code with it.
The only thing I couldn't find at first was a good editor for it. I would up with ... IntelliJ. The only minor thing that Community Edition doesn't have is editing CSS, and I can live without it. There's a Perl plugin that does good completion and navigation (Find Uses / Find Definition, semi-intelligent completion).
I tried the IntelliJ plugin and unfortunately just couldn't make it work. Past a certain point of metaprogramming (e.g. using complicated-but-not-objectively-that-weird Moose constructions with multiple levels of subclassing and mixin-based inheritance), it just couldn't keep up and started providing autocomplete suggestions that were completely off-base.
There's lots of discussion on HN of languages that see less use than Perl. Often the reason people invest in them is that they think learning the lesser-known/used language might offer them a novel view of development or provide extra capabilities in some niche. It isn't particularly different with Perl, although there is the difference that many devs think they already know what they need to know about Perl even if they've never done anything serious with recent 5.x or 6 (or at all).
> Imho they should just fork Perl 6 and continue developing Perl 5.
That ship already sailed way over a decade ago (or longer) and changing it now would just massively add to the confusion between what Perl 5 and 6 are. You can't retroactively rewrite every webpage and reference in history, and it's not a particularly hard to explain that they're essentially separate languages. Perl 5 will continue to be maintained and evolve in a compatible way, and Perl 6 is a much different language altogether. They quite literally "forked perl 6, and continued developing perl 5".
Forking an existing, newer language just so you can do what amounts to a meaningless, useless major version bump of an existing, established language, is pretty much the exact definition of a breaking change for frivolous reasons.
> and changing it now would just massively add to the confusion ...
There are two types folks who care about Perl - both are in dwindling numbers. The old-timers -- they never have and will never be confused and clearly understand that there is urgency for that "ship", now more than ever. The new-comers and those have deserted the ship and looking for an opportunity to come back -- they are massively confused as hell right here right now.
There is only one real reason for not launching that ship -- Larry Wall has taken that sailed ship long ago and will not come back (admit his mistake).
> There is only one real reason for not launching that ship -- Larry Wall has taken that sailed ship long ago and will not come back (admit his mistake).
To my understanding, he's admitted his mistake. That doesn't mean that after this much time, going back is the best solution. There are major positives and negatives to all options, so at this point people are just letting it stay as it is rather than force it into something that could be even worse. People have had well over a decades to come to terms with the naming, and coming out with Perl 7 (or taking the name Perl 6 back) aren't really going to help with anyone that's already confused.
Perl 5 and Perl 6 are still both advancing on their own paths, it's not like either one was actually stopped because of this.
No, but launching a new ship is a bad idea if your reasons are frivolous. It's a waste of resources. Most people seem to think that resources like labor and trust are magical and grow on trees in community-driven projects (especially when it comes to executing on their pet-projects or desired features), and I can tell you they don't.
> The new-comers and those have deserted the ship and looking for an opportunity to come back -- they are massively confused as hell right here right now.
What exactly is so confusing about "Perl 5 is a stable language that has been in use for decades, and will remain developed, and Perl 6 is a backwards incompatible evolution that is independent". You're saying things like you're "confused as hell" but it's not really hard to figure out, and it's not even clear how hard you actually tried. The Perl.org webpage even literally states "Perl 6 is a sister language, a member of the Perl family, that is not intended to replace Perl 5".
Frankly when people say things like this, I'm often convinced it's not actually out of genuine confusion, but often feigning ignorance to make a point, to the level of being child-like. Computer programmers _love_ making everything complicated (especially over small trivialities that "could" be "fixed" if we "cared enough") -- but "Two similar things share a common family name" is not very complicated, to pretty much anybody.
And here's a counterpoint: I haven't written Perl in nearly 10 years with any regularity, and I recently started a new project because I wanted to write a small web app. Here's what I did: I searched "Popular Perl Web Frameworks" and came across Mojolicious. I then saw it was a Perl 5 framework. Then I followed the tutorial and wrote a web application and I was done. There was no "massive confusion" about it.
> Larry Wall has taken that sailed ship long ago and will not come back (admit his mistake).
People in the Perl community have admitted for a very long time that there were many mistakes made in the development of Perl 6, including the poor naming convention that maybe ties the languages too closely, when they are quite different. I'd say the mistakes are well known, even 10 years ago when things were far different.
Your mind is shrouded by your zealous emotion that you are handicapped in your perception.
> What exactly is so confusing ...
I can see you how you don't understand; unfortunately, you are having trouble understand the other way.
> Frankly when people ...I'm often convinced it's not actually out of genuine confusion ...
It doesn't take you a few sentences away to getting close to name-calling. It is very difficult to listen at this stage.
---------------
> it's not even clear how hard you actually tried.
You are putting me in the wrong camp. I love Perl and I have been using Perl for over 10 years. I am not confused. Perl is Perl5; Perl6 is an experiment that hasn't succeeded yet, And Perl6 is irrelevant to Perl5 from a language point of view (although, not vice versa).
I have students that I want to show Perl to. They, being young and natural, will not put their heart to Perl 5 if Perl 6 is out there -- different alright, but Perl 6 surely is newer and must be the future, right? Then they find the state that Perl 6 is slower than Perl 5 and obviously less mature, so they wait -- by moving on.
I have colleagues and old admins who are looking back but all their current thought are: Perl is dead, how is Perl 6 doing.
> People in the Perl community have admitted for a very long time that there were many mistakes ...
Acknowledged mistakes that have no action/effort of correcting them are not admitted. Sunk-boat fallacy is just a n excuse for not admitting mistakes.
Amen. I’d love to see a rebrand to Rakudo and Pumpkin, where the latter is Perl5 plus some long-overdue backwards incompatible changes, but also 99% compatible.
I'm not really sure what you want in terms of backcompat breaking changes. I feel like if you do enough to make Perl 5 modern, you end up with Perl 6, but different. Once you add real Unicode support and a MOP and concurrency, you've reinvented more than half of Rakudo. It should be called Perl 7, so we can have yet another version.
I think there is this idea that you could graft the Perl 6 object model onto Perl 5 but keep the things people like about 5 (that it's implemented in C and installs more like a normal Unix/Linux tool that we are all familiar with). This would open the door for CPAN modules that exploit the cleaner and more modern object model like we have with Python and Ruby. Which would in turn allow Perl to be more in line with what people expect from a modern tool, combining the best of the old and best of the new.
I think if you start with the state of CPAN and work the problem in reverse you might see what people are wanting.
"Mega language popularity"[1] is largely driven by boom-and-bust fads, my friend, as well as cultural artifacts like word-of-mouth -- and the number of people who generally make any language decisions about them based on minute details like you're implying is a vanishingly small one, in my experience.
I'd even go further and say that, in my experience, your mind is likely already decided, as well as the minds of many others, when it comes to choices like this. Whether or not they renamed Perl 5 to Perl 7 or whatever is not really going to make a difference in the long run and no perceptible marketing changes will change that to you... People on places like this website already like to talk about other examples such as how "Ruby and Rails are dead" despite them still being immensely popular and widely used today still... Their mind is decided well before any actual facts of the matter come up, even if Rails has more open bug-reports than they have users. No amount of new marketing will change it meaningfully, because much of the decision is driven by cultural aesthetics, and aesthetically, it's just not cool anymore. We're all prone to it, and unfortunately, it is not always a fully rational or predictable path, either.
Some amount of marketing matters for software projects, a lot of it in fact. But at some point you have to call a spade a spade, and decide when you're just chasing meaningless fads for something that won't happen, based on technical marketing alone.
[1] Which is almost exclusively what everyone 'means' when they talk about this sort of branding/marketing stuff, if you asked me as a FOSS developer. Nobody can ever conceptualize "successful, accomplished, and with a healthy life", because by every measure Perl is a wild success in all these metrics, beyond what most software could ever dream of -- they can only conceptualize "total failure" AKA "dead language" and "wildly successful beyond all measure in all circumstances, forever".
I don't really think most people think like that (or even necessarily initially have the information to be able to). To me, it seems like most language adoption is driven by fads, what people are hiring for, and random interesting projects.
Have you ever actually been interested in a language and looked to see whether it was able to have a major version number bump or not prior to deciding whether or not to pursue it?
That't what I am doing with cperl. perl5 is unfortunately not developed anymore, just "maintained", with more and more destruction being added every year.
People seem to be ok with Java and JavaScript having pretty much nothing to do with each other. The couple of people trying to retcon the name to ECMAScript have not succeeded.
Perl5 and Perl6 are the same situation: on first glance they seem closely related, but they're not, end of story. It's been clear for a long time that Perl6 is not a replacement for Perl5, it's a different language from the same creator. It would have been great if it were named something else, but changing its name is something its community would need to do, and won't erase the years of history that already exist.
Which argument? The mug-throwing incident that initiated Perl6 development happened 2000-07-18, and it took a couple of years after that for the language to take shape...
A different perspective: there’s probably a few command line perl scripts out there that could be nice web services or perform some task in a browser. This way you don’t have to rewrite those scripts.
First time I heard about this thing. I don’t get it either. It just seems to be somewhat witty but ultimately trite artistic “punnery” - somewhat akin to those Reddit meme gifs with the witty but stupid captions.. just done more artistically.
This is a great anecdotal argument -- I just want to note that it also applies very well, pretty much verbatim, to some other graduate school educations too, such as engineering or comp sci.
Pretty much. At my last company, I managed a data and analytics team. The vast majority of applicants were over-credentialed individuals trying to break into data science (even though we didn't brand the positions as such). While I applaud their achievements in and of themselves[1], very few were able to articulate why their advanced degree would apply or be beneficial for the roles I was attempting to fill or justify the salary requirements they'd request.
My two best performing and best paid employees on that team were exact opposites - one had just finished a masters in math and the other had an incomplete bachelors. But both were able to articulate why they had made the choices they made and demonstrated the ability to make deliberate, pragmatic, and calculated decisions. Which is an invaluable skill to have on your team.
[1] I'm a terrible academic. I focused more on working and making money while in school, and gave the bare minimum amount of attention to my classes to get by. So I do truly have appreciation for people that can dedicate themselves to school enough to achieve an advanced degree. But that appreciation is separate from them being able to derive work value from that degree.
It’s very common for PhDs in technical fields to pivot to data science once they hit a wall in their career from the oversupply problem. I’ve had a couple of friends make this jump - but they either came from a computational background or devoted at least a year to learning the necessary programming skills and math. Out of curiosity, did the overcredentialed people you interviewed have any actual experience applying analytic techniques, or were they just people with advanced degrees blindly trying to move into a hot field?
Yeah I go to Target first now -- I like the hassle-free returns (same as Amazon) but with the guarantee that items are verified authentic.
I've noticed that Target has, however, slowly begun to list inventory that I am guessing it doesn't have stock for, since there's literally pages and pages worth -- let's hope that Target does NOT pull the marketplace-sourced inventory scheme, because then there would be no difference between Target and Amazon anymore.
