Perl is dying - <AUTHOR> https://thehftguy.com/2019/10/07/perl-is-dying-quick-could-be-extinct-by-2023/ <comment><USER2> > That makes one wonder about who else is still using Perl? if any? Can't > remember the last time I've heard about it.

Perl, like many other languages, has its own bubble. I'm using Perl daily at work. I used Python for a while, but the Perl job market was just too nice to pass. I have a backlog of clients interested in Perl work longer than I can handle, and they don't mind my requirements because they have no one to replace me with.

Is that a sign of a dying language? Probably yes. But to be honest, if it's about to become the next COBOL then I'm looking at a lifetime of profitable work with little to no competition :)

BUT: > Nothing personal with Perl. Just doing stats

Perhaps a little bit of research could help your point as well. The CGI example you mentioned is broken, but is also using a module (CGI.pm) that's been bad and wrong for so long that even Perl, with its eternal love for backwards compatibility has removed it from Perl Core. That's a sign of Perl's marketing problem, yes, but it's hardly a real indication of a language that's too old to care about fixing itself.

<comment><AUTHOR> >>> The CGI example you mentioned is broken, but is also using a module (CGI.pm) that's been bad and wrong for so long that even Perl, with its eternal love for backwards compatibility has removed it from Perl Core.

The CGI example is straight copy/pasted from the official Perl guide, November 2018. [https://www.perl.com/article/perl-and- cgi/](https://www.perl.com/article/perl-and-cgi/)

<comment><USER3> ...which says

> Warning you probably don't want to use CGI for modern web development, see > Why Not to Use CGI.

<comment><AUTHOR> It's just a trivial example to show what the languages look like with variables, loop and print.

CGI is not used to deploy web applications anymore, I am aware of that. That's a far leap from saying the module is "broken, bad and wrong".

Another commenter pointed out that there are typo in the example so it doesn't work.

</comment></comment></comment></comment><comment><USER4> I love Perl. I first used it in 1994, around the time the early versions of Perl 5 were released. It's hard to overstate what a breath of fresh air it was compared to the incumbent languages at the time, which were either very low- level (mainly C, and increasingly C++, at least in the Unix world) or else brittle and limited (various flavours of shell script, sed, awk).

Perl was a joy to use. Things that would have needed dozens of bug-prone lines of C could be done in just a few characters. Regular expressions and associative arrays were first-class language features! And, with the advent of Perl 5, there was enough scope for structuring code in a modular way that it wasn't insane to write pretty large and serious programs.

The culture was delightful too. In those days it was centred on Usenet and mailing lists, and the general attitude was freewheeling and fun. When the first user group was set up in London, where I was living by then, I signed up immediately. That's still the most fun I've ever had hanging out with programmers, and Perl was the glue that bound us together.

At some point I joined the developers' mailing list (perl5-porters), just to see what they were up to. After a while I started to contribute: bug fixes at first, and later language features. That was fun.

So, Perl has been a big part of my programming life. But I haven't really used it in anger for about 15 years. I still write Perl one-liners on the command line for ad hoc data processing, and actually I think Perl is still the best available tool for that, although younger coders tend not to be familiar with it any more.

But as for writing real programs? The world has moved on. There are newer languages that have taken the good ideas from Perl, but without so many confusing idiosyncrasies.

Perl 6 is another story, one that I didn't have much part in. It's a fun bundle of ideas, and maybe some of those ideas will spread and be useful elsewhere, but I doubt it will ever catch on itself.

I'll always _love_ Perl, but I doubt I'll ever write another serious program in it – except maybe out of nostalgia.

</comment><comment><USER5> As somebody heavily invested in Perl (just check my nickname, and I've written books about Perl (though Perl 6, not Perl 5)), my impression is that the size of the Perl community is rather stable.

In an overall growing market of programmers and projects, this means a decline of relative market share.

Sources:

* Every four years I organize a German Perl Workshop, and the attendance is roughly the same each year (80-120 people)

* Take a look at the commit stats of the Perl 5 interpreter at github, looks pretty stable over the past years: [https://github.com/Perl/perl5/graphs/contributors](https://github.com/Perl/perl5/graphs/contributors)

* Just general, unquantified impressions from Perl communities I vaguely follow (twitter, Perl questions on Stack Overflow, some IRC channels etc).

* Work use of Perl and and hiring for Perl positions

<comment><USER6> If you're not growing you're dying off

<comment><USER7> Says the pointy-haired boss type of person

</comment></comment></comment><comment><USER8> Calling Perl (released 1987) "one of the first" programming languages is an extremely revisionist view of history to put it lightly.

<comment><USER9> Saying that Perl was one of the first languages is silly of course. It's nowhere near as old as LISP, FORTRAN, and C.

However, Perl is the first of its kind. Prior to Perl, one would have to hack together in either Bourne or C-shell a series of commands all strung together, poorly. Grep, sed, awk, and a slew of utilities were strung together poorly with any specialized manipulations coded in and compiled from C.

Perl was the first popular language that gave us first class data structures (arrays and hashes) along with the programming structures we were familiar with in C. The inline regex support obviated the need for sed and awk gymnastics to the relief of many.

All of the crazy things in Perl that drive so many people nuts today were derived from the shell scripting that everyone was familiar with at the time. Error codes in "$!", that seems familiar, if you're used to /bin/sh. Perl's syntax which mapped shell script idioms directly into language features made these conversions a breeze.

Perl was the first and best at being able to convert these awful shell scripts into something which was maintainable. This was also Perl's primary downfall. Because it was so easy to use, lots of people who were not first-class programmers were able to write a lot of not-so-nice scripts which made later programmers sad and angry. It was a victim of its own success.

</comment></comment><comment><USER10> What's the alternative to Perl for the sort of file conversion and text processing that can be done with a Perl script of about a hundred characters that I can type in and edit on the command line? Or if I want a 100-line script that will work in 2029 the same as it works today and won't require any stuff to be installed first?

I don't _like_ Perl, but since it's there, it works, it runs quite fast and I'm familiar with it, I'll probably continue using it for my own stuff for as long as I continue to use a computer, which is likely to be at least a couple of decades beyond 2023.

<comment><USER11> An expert Perl user will always be able to show some nifty program that could never be replicated in another language, or would be ten times larger and full of bugs if it were. If you play to its strengths, it is amazing. There is no better language for ingesting text in ad hoc formats and generating formatted reports. Hence the name.

<comment><USER12> The Practical Extraction and Reporting Language thing is not Perl's name, it's just a backronym that Larry Wall came up with. My personal favorite backronym is Pathologically Eclectic Rubbish Lister (I say this as someone who really loves Perl).

<comment><USER11> From `perldoc perl`:

"""Perl officially stands for Practical Extraction and Report Language, except when it doesn't."""

<comment><USER13> It seems like you are arguing that because it is in the official docs, that is where the name 'Perl' came from, but that is not accurate.

autarch is right, "Practical Extraction and Report Language" _is_ a backronym --the language was named 'Perl' first, and that acronym (and others) were devised later ( see [https://en.wikipedia.org/wiki/Perl#Name](https://en.wikipedia.org/wiki/Perl#Name) ).

Larry was originally going to include the 'a' and name the language 'Pearl'. However, at the time there was already a programming language named 'Pearl', so he changed the name to Perl ( again, see [https://en.wikipedia.org/wiki/Perl#Name](https://en.wikipedia.org/wiki/Perl#Name) ).

This can be verified from multiple sources, including the "Learning Perl" book ( see [https://en.wikipedia.org/wiki/Perl#cite_note-57](https://en.wikipedia.org/wiki/Perl#cite_note-57) ).

<comment><USER11> It can be a backronym and the official name at the same time. Your assertions are all true but your logic is faulty.

<comment><USER13> Sorry, just got back to this.

I guess that depends on whether you consider an obviously tongue-in-cheek backronym to be "the official name". We obviously disagree on this point.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Kind of stupid article. Perl will be dead because there are less searches on it and Apple is deprecating all script interpreters (not singling out Perl) and RedHat has announced that _python_ is not setup out-of-the-box. Bold predication - in 2024 there will still be plenty of Perl running.

<comment><USER15> Although not AWK! Apple has to keep it to still adhere to POSIX (which is still a relevant classification to many big buyers in government and enterprise). Maybe this will cause an AWK renaissance...

<comment><AUTHOR> POSIX is mentioned. Removing it can't be an issue or Apple and RedHat wouldn't be removing perl/python. There's gotta be something we're missing out.

RedHat is specifically targeted to government and enterprise. They would be aware of that.

<comment><USER16> The thing that RHEL is trying to fix is to prevent customers from being tied to the system python/perl and should install a version that works for them and the application they are trying to run. People installing random modules into the same perl/python as is used for system startup/critical software has always been a problem but it is also one of those things that makes having a long term LTS nearly impossible because you can't separate the user needs vs. the distribution needs and trying to fix _anything_ turns into backports to weird ancient versions. This way distros can package and update the things they need independently from everything else and not disturb the user, and also provide a more comprehensive suite of packages that also don't disturb the system space. This is similar to how Amazon Linux is setup a bit.

A better example is a user I should be able to install python 3.7 and use it, even if the system libraries for the core packaging is based on python 2.x. Traditionally most users would just build their system scripts on python 2.x (because it is there), which means that if you upgrade the distro from RHEL X to RHEL Y (which brings a python 3.x) you break a user's environment. This was a constant problem when you were trying to go through the RHEL 5-6-7 upgrade paths among other things.

It hopefully will be resolving the issues of people and packaged software using weird old versions because it is there and breaking when something changes. My favourite example is having to write in ancient bash just to support MacOS which still ships bash 3 something.

In a shorter version, the interpreters are still there and buried, just not on $PATH and given to the user as a what they should use.

(This is opinion based on how I have seen people abuse systems and try to upgrade them over the years).

</comment></comment></comment></comment><comment><USER17> This article immediately reminded me of the classic "BSD is dying" meme. For those who haven't seen it yet, [https://everything2.com/title/BSD+is+dying](https://everything2.com/title/BSD+is+dying) explains it, and several of the points listed there might also apply to this article: "[...] there is always someone who is more than willing to defend it", "easily knocked down facts", etc.

<comment><USER11> I immediately mentally inserted "Netcraft confirms" before the title of this submission. Glad I'm not the only one afflicted with this meme.

</comment></comment><comment><USER18> I really like perl. I started writing it in my university for sys/admin stuff and then went down the rabbit hole and investigated most of the nooks and crannies of the language. I like all the special symbols. I have no issue with reading code that I wrote five months previously. I like that it does not limit what I want to do programmatically.

In fact I recently snuck some perl code into production at my company a month or so ago: we needed an android app to post data to a backend where it could later be analyzed. Super simple. I wanted to get it out the door as fast as possible and due to the fact that it will be retired before the end of this year, I choose to write the backend in perl using MongoDB and Mojolicious. Then I saw that MongoDB is retiring their driver for perl[1]. I still went forward, but it was yet another reminder of the state the language is in.

It saddens me that perl does not get more love. It is a fantastic language but I can not justify teaching others it, or encouraging them to learn about it.

[1]: [https://www.mongodb.com/blog/post/the-mongodb-perl-driver- is...](https://www.mongodb.com/blog/post/the-mongodb-perl-driver-is-being- deprecated)

</comment><comment><USER19> > Nothing personal with Perl. Just doing stats.

Very poor stats if you're extrapolating the time a market participant will be reduced to zero by looking at _relative_ market position without also examining absolute usage.

That is, it's possible for something to have less relative market position but be increasing or static in total usage if the total market is increasing fast enough. That doesn't indicate something is dying, but it looks the same in graphs, and extrapolating from those lines won't show you what you think it is.

Is Perl in that situation? Probably not that much (but somewhat, I would argue), but if you're going to make a case on statistics, don't do a crappy job of it...

</comment><comment><USER20> I understand Perl is still very popular, but I have always hate Perl with a passion. I felt it was just a bunch of arbitrary rules that you had to memorize vs a more naturally intuitive language. For example, if I remember correctly, Perl supported both "&&" and "and", with 2 different precedences. And the line of code that broke me was something similar to

$a = $src[$src]

At first I thought it was a bug, but then I realized that there must be two different variables called src, one was a scalar and the other was an array (I think that's what it's called it's been 15 years since I've used it).

Anyway at that point, I decided I hated Perl and would never use it again.

<comment><USER21> Don't most programming languages have a few idioms that really annoy newcomers?

I've been using Perl since the 1990's so when I see something like your example, my first thought is "oh no, somebody who doesn't know Perl wrote this Perl code!"[0]

I recently learned Python and while I think I'm pretty OK at it, I still have WTF moments from time to time. Like:

> from datetime import datetime # WTF? and yet standard!

I'm often tempted to rant about semantics and documentation culture in Python but then I remember hey, lots of people have similar criticisms of languages I know better, so maybe I should just give it some time.

I'm not saying you should have liked Perl, but in the programming landscape of 15 years ago you were passing up one of the most important things powering the Web.

[0]: never name two variables of different types the same thing; never use $a as a normal variable because it's sometimes Special.

</comment></comment><comment><USER22> > Perl – 1987

> Python – 1989

> Ruby on Rails – 2005

Ruby itself is 1995. In 2005 when Rails was coming out Perl had it's peak according to Tiobe:

> Highest Position (since 2001): #3 in May 2005[1]

> That makes one wonder about who else is still using Perl? if any? Can't > remember the last time I've heard about it.

Duckduckgo? [2]

Sure, Perl is loosing popularity but I don't think it's anywhere near dead or extinct.

[1] - [https://tiobe.com/tiobe-index/perl/](https://tiobe.com/tiobe- index/perl/)

[2] - [https://github.com/duckduckgo?language=perl](https://github.com/duckduckgo?language=perl)

<comment><USER23> Booking.com also still has a ton of Perl I believe.

</comment></comment><comment><USER24> I hate to be this guy, but Ruby on Rails is not a language, and Ruby the language was first release in 1995.

<comment><USER25> Almost nobody was using Ruby in 1995. Perl, however, was everywhere.

<comment><USER26> Almost nobody was using Python in 1989 either. Clearly it's a mistake on the part of the writer and not some deliberate attempt at judging when a language became popular.

<comment><AUTHOR> Author here. I put Rails instead of Ruby deliberately. I'm not sure if Ruby is significant enough to stand on its own, guessed not.

<comment><USER26> Thanks for clarifying. But that seems a bit unfair and arbitrary. Rails definitely boosted its popularity but Ruby itself is quite potent without it. Stripe has its systems written in Ruby without using Rails, for example.

If we apply the same standards for Python, shouldn't we track its popularity by when NumPy(Numeric) came into being? (1995)

This is supremely pedantic though, and I don't really care about arguing it here, so :shrugs:

</comment></comment></comment></comment></comment><comment><USER27> Its not dead, but how much new code is being written in Perl? I generally measure th health of a language by how much contemporary use it gets.

I used to write Perl but I do not take it out of the tool chest anymore and I see very few Perl codebases in the OSS world.

<comment><USER28> The OSS world, all the glitter, is just an iceberg to the ice continent of the software industry as a whole. There is still a lot of new mainframe code written today. And a lot of glue scripts are still written in perl at various software houses

<comment><USER29> The OSS world is all glitter? Huh, I guess all of those ancient Apache installations running mod_perl are more glamorous than we thought.

Ditto the busybox shells on a million embedded systems, but I guess that's a bit beyond most here.

</comment></comment></comment><comment><USER30> I'm not sure using a very outdated CGI example as an illustration of why Perl is dying is all that convincing.

It says in the source article "you probably don't want to use CGI for modern web development", then explains all the reasons why not, pointing you to modern frameworks such as Catalyst, Mojolicious and Dancer.

Not saying Perl doesn't have challenges with its popularity, but this isn't a very good case as to why it's dying.

<comment><AUTHOR> It's just a basic example to show what the language looks like. Same in the 3 languages straight from the textbook and stack overflow.

Basic CGI script to show all GET request parameters. If you were writing an HTTP API, you would probably do something very similar although not running over CGI.

<comment><USER30> Ok but why not choose an example to show what the language looks like today, vs >10 years ago? Perl CGI is deprecated, so if anything using an example this outdated proves the opposite of your point.

Surely a more constructive comparison might be looking at a 1 page app in Mojolicious vs Flask, Express, etc?

<comment><USER31> For example the -signatures example on [https://mojolicious.org/](https://mojolicious.org/)

</comment></comment></comment></comment><comment><USER32> having read the article I agree with only one point that the author makes: once Perl is removed from the default installs, it will lose one of its advantages, being there and working by default. People will likely shy away from installing an additional programming language.

The other topics there have been rehashed many times before and are little more than extrapolations and exaggerations - how could a language ever go extinct ... if anything COBOL demonstrates that languages do not go extinct.

<comment><USER29> > The other topics there have been rehashed many times before and are little > more than extrapolations and exaggerations - how could a language ever go > extinct ...

COMIT, TRAC, JOSS, FOCAL, and a few dozen assembly languages all _would_ wave, but they're a bit dead at the moment.

<comment><AUTHOR> Wikipedia has a list of major programming languages by generation: [https://en.wikipedia.org/wiki/History_of_programming_languag...](https://en.wikipedia.org/wiki/History_of_programming_languages#First_programming_languages)

</comment></comment></comment><comment><USER33> There is no bug with `\r\n`. I checked the provided example, fixed `\N` to be `\n` (this bug causes a compilation error, so it would be noticed during compilation). The hex output is as follows.

        00000000: 436f 6e74 656e 742d 5479 7065 3a20 7465  Content-Type: te
        00000010: 7874 2f70 6c61 696e 3b20 6368 6172 7365  xt/plain; charse
        00000020: 743d 4953 4f2d 3838 3539 2d31 0d0a 0d0a  t=ISO-8859-1....
        00000030: 5041 5241 4d3a 0a                        PARAM:.

Note the 0d0a0d0a sequence following the character set. This is `\r\n\r\n`, as it should be.

<comment><AUTHOR> This was running on Linux?

That's odd. The bug works on Python. Wondering how Perl does the formatting to end up with \r\n.

Either way, still puzzling there is a typo in the official example.

<comment><USER34> You can find similar examples with just \n in the official Apache docs on CGI: [https://httpd.apache.org/docs/2.4/howto/cgi.html](https://httpd.apache.org/docs/2.4/howto/cgi.html)

The solution for this puzzle is that mod_cgi will simply convert LF to CRLF silently.

(more precisely: it parses the headers the script outputs in a relaxed way and lets the server write them in a correct format later)

</comment></comment></comment><comment><USER35> A lot of comments seem to be equating dying with dead. So, let's agree that Perl is _not_ dead.

Is it dying? it isn't as popular as other languages, and it isn't being used for as many new projects. Therefore, you could say it is dying a slow death like a lot of languages before it. It will continue to be used in existing code bases for decades to come, but like Cobol it likely isn't going to be the go-to language for most projects.

Will Perl 6 change the trend? Maybe? I don't think we know enough to rule that out.

If it _is_ dying, I often wonder if it was a self-imposed death. If Perl 6 hadn't been delayed so long, we might be living in a world where Python didn't become the go-to language. But was that ever a real possibility? Could we have gotten to Perl 6 as "easily" as we got to Python 3? Anybody have an opinion on that?

<comment><USER36> what is a dead language exactly. Is COBOL dead, it had a version update just a few years ago.

<comment><USER35> I think there's two types of dead:

1\. Dead as in hasn't received an update in years.

2\. Dead as in very few people use it for new greenfield projects.

</comment></comment></comment><comment><USER37> > For example, it doesn't support functions with arguments,

Well, you can name your arguments if you want to. You can use hashes. Or you could just get a bunch of unnamed values.

I like this flexibity. I also like that you can make the language evolve without having to add syntax (something Java is suffering from).

<comment><USER38> This was mind-bending for me too. It seems like the author is just arguing that since the syntax is different it's worse? The flexibility in Perl is nice, and while references can be a real PitA, a weird assertion to just make.

<comment><USER31> One day my comment on the article might get approved showing that the _syntax_ is also "modern" since like 2008! 2014 was formal support in the core of the language with `use feature 'signatures'` in version 5.20

</comment></comment></comment><comment><USER39> I used to write perl 20 years ago and haven't touched it in 15 years. I thought it already was dead, then alas I got a job where it still exists in massive undisturbed quantities of thousand line functions and scripts with no structure.

It feels the same as the anthropologists must have felt when finding an Amazonian tribe completely untouched by the modern world.

</comment><comment><USER40> Perl was great when it came out, but there's a lot of better alternatives available ("better" in terms of robust language definition and diminished likelihood of a typo leading to a sound-but-incorrect program, which seem to be two things that developers value more over terseness in an era where IDEs assist with editing in verbose languages).

I suspect perl will always have a place (there are a million shell scripts out there handling issues people need solved), but it'll have a place like COBOL does; useful where it already exists, but not something you learn until and unless you need to edit a perl script.

<comment><USER41> I dunno, for certain task I think Perl is unmatched. Anything that would take more than a loop in bash to accomplish, but bash style work.

</comment></comment><comment><USER42> Other than C++ in high school, Perl was one of the first languages that I learned. At the time I was working on Unix systems in a closed off, secured area with no access to the internet. I was doing systems work, and the only tools I really had at my disposal was what was on the servers I had in the space with me. If I was lucky I got a system with a modern Linux OS on it like Red Hat, but sometimes I had to work on a Solaris UNIX system that was pretty bare bones.

The options for scripting were either bash or perl. After some digging around I found some scripts that other engineers wrote in Perl. Mostly using it for text replacement, regex, and basic server functions.

I was intrigued by the weird syntax and very powerful one liners, so I got some books and taught myself basic Perl. I started writing some quick scripts and it made me feel like I had a super power. Most of all, Perl was fun with all the different ways you could do things. It was like a puzzle.

Fast forward to my first "real" software job. Most of the code case was written in Python, so I started learning that. I wrote a couple scripts in Perl to do some basic text stuff that I thought would actually be less elegant in Python. While I thought I was quite clever, the other engineers immediately jumped on me and told me to never write any Perl code again. Something about "hard to maintain", "too many ways to do it", etc.

After that I never wrote any "real" code in Perl, but I kind of want to write some clever, convoluted Perl code just because I can.

</comment><comment><USER43> What does it mean for a programming language to be "dying" or dead?

If the language is being maintained and bugs fixed, is that dying? Can a language be complete? If it's not gaining new feature, does that mean it's dying? Is it the number of users that matters? What if a language has 10,000, 100k or 1 million happy users is that not enough?

If I wrote a custom language for me and a few friends or companies and there's 100 of us using it, no one would declare the language dying. So why do we use number of users? Is it dependent on the number of available jobs? new Books, articles, or library/modules published?

I'm not so sure, but I'll like to know what makes a language a dying or dead language.

<comment><USER44> If we found a planet with 350 billion humanoids, we'd say _Earth is dying_.

Until the last program is written, and the last machine to run that program stops.. can't really say it's dead.

</comment></comment><comment><USER45> Booking.com might keep it alive for a while

<comment><USER46> ...and

        cPanel
        craigslist (https://www.craigslist.org/about/thanks)
        imdb (https://help.imdb.com/article/imdb/general-information/what-software-are-you-using-to-run-imdb/GH25HF4NB3C2KP9E)
        Companies who use Perl within London http://london.pm.org/advocacy/
        2018 sponsors (https://act.yapc.eu/lpw2018/)
        2019 sponsors (https://act.yapc.eu/lpw2019/sponsors.html)

<comment><USER41> Is DuckDuckGo not Perl as well?

<comment><USER46> I thought I added it; good catch +1

</comment></comment></comment></comment><comment><USER44> Perl 5 is like the jQuery of the server-side. Way better than what came before it, and only just a little worse than what came after. (IMHO) I kinda miss em both.

</comment><comment><USER47> Any language put into the same __relative popularity __graph of other languages each with _faster growth_ will always show up as diminishing.

<comment><AUTHOR> Are you implying that COBOL and Delphi are fast growth languages?

</comment></comment><comment><USER48> This article displayed a malware ad to me, unfortunately. Flagging accordingly.

<comment><AUTHOR> Author here. Screenshot?

Wordpress is showing ads automatically on all blogs, I might be able to pay and disable them if they are really as horrific as that.

<comment><USER49> I got this too. It redirected me to a fake Mac "system warning" page twice in a row. Sorry, I don't have anywhere handy to host a screenshot.

<comment><AUTHOR> You mean opening the page got you redirected? Without any user action?

That is shady as f __*. If WordPress is really doing that, the next article will be about wordpress distributing malware.

<comment><USER48> Yes, and with a pop-up designed to look like a Mac modal. You know the kind. :-(

</comment></comment></comment></comment></comment><comment><USER50> Perl is by far the most 'fun' language I've ever programmed. Once you get familiar with a lot of the idioms, it is extremely powerful, and the amount of processing you can do in a line or two of perl would take 10 lines in Java and 20 in C. And 15 years ago, these were the languages it was competing against.

That being said, I rarely use it anymore, and the reason is that once you stop using it daily, you quickly forget all the quirks of its syntax and its powerful idioms, and often I can't even read it without having to Google for help. And that is why it is dying - there are too many ways to do things.

Compare this with Python, which I've never really used as a day to day language, but every few months have to deal with some smaller project written in Python. I can jump in and get work done immediately because there are so few ways to do things. It is mostly just iterating through dictionaries, whereas Perl pushes you to think of everything as a regex or text.

<comment><USER51> > Perl is by far the most 'fun' language I've ever programmed. Once you get > familiar with a lot of the idioms, it is extremely powerful, and the amount > of processing you can do in a line or two of perl would take 10 lines in > Java and 20 in C. And 15 years ago, these were the languages it was > competing against.

On top of that, if you found some exception or special case later that you needed to add support for...it was usually just a quick tweak to the Perl program, but often half a rewrite in Java or C.

This meant (and still means in a lot of cases) that when you need to do processing on data whose format is not well specified and so you expect to not get it right until a few iterations, doing it in Perl can often be a lot faster than most other languages.

</comment></comment><comment><USER52> But Perl does have functions with arguments, by all definitions. [https://metacpan.org/pod/distribution/perl/pod/perlsub.pod#S...](https://metacpan.org/pod/distribution/perl/pod/perlsub.pod#Signatures)

<comment><USER53> Indeed, Perl does have named function parameters, the same as almost all modern languages - and I highly recommend using them.

(I use them throughout my code, except for modules that should stay compatible with very old versions of Perl.)

But folklore is a thing. Many people learned Perl before named parameters, and to be fair they took about 20 years to arrive (and are still called "experimental"!). People don't like to change now.

I think most people writing new Perl code still use the no-named-arguments idiom, just because it's old and familiar. Which makes code look more arcane than it needs to, to outsiders, unfortunately.

</comment></comment><comment><USER54> Perl won't be extinct anytime soon due to its quality. Those who know it treasure it for the unmatched performance. Performance of turning ideas into reality. Ideas way beyond sysadmin and reporting stuff. Perl as a language, ecosystem, and community is well and kickin'. My 2 cents.

</comment><comment><USER55> > "Perl was a popular programming language about 30 years ago"

That's inaccurate. Perl was released 30 years ago. It was quite popular by 2000, or about 20 years ago.

That said, something dies when it is no longer useful. Perl is quite useful and still comes bundled up with any modern Linux system.

<comment><USER56> And if sometime in the future Perl is no longer included by default, it will be installed "by dependency" just when you install packages like rsnapshot, CSF firewall, etc. and probably a big bunch of tools that nobody would guess are written in Perl (or some tools of the package)

</comment></comment><comment><USER57> We're still actively maintaining a whole bunch of TCL code, which is much farther down the list.

I never like Perl I remember it's heyday, just through sheer inertia it'll be around for a while.

</comment><comment><USER58> I stopped using perl in '95 when I tried to make a multidimensional array and the syntax was nearly impossible to figure out. Switched to Python and was happy to see that the Numeric library was released that gave matlab-like array behavior to python.

I know some folks in the bioinformatics community who still write CGIs in perl and I really have to wonder why.

<comment><USER53> The Perl syntax to access a multidimensional array will be familiar to programmers in any other mainstream language:

        my $array = [ [1, 2, 3], [4, 5, 6] ];

        say $array->[1][1]; # Prints 5, as you'd expect.

It's really not that arcane.

</comment></comment><comment><USER59> "For the young readers who may have never heard of it. Perl was a popular programming language about 30 years ago."

1989 would have been the Perl 4 days. Perl 5 is twenty-five years old.

I don't write much Perl these days, unless for something inconvenient to do in Python. I have nothing against Perl, I just find that the young are much more likely to know Python.

</comment><comment><USER60> As long as GNU autotools relies on Automake, Perl has some life left in it.

</comment><comment><USER61> > That makes one wonder about who else is still using Perl? if any? Can't > remember the last time I've heard about it.

I don't even get statements like this. And what does 'heard about it mean' anyway.

Interesting I just pulled up another quick and dirty test compliments of HN Search (Algolia):

Last Year Story Titles:

Perl: 301 Python: 3,360 Java: 3,931 Ruby: 687 Ruby on Rails: 105 HTML: 214,423 Bitcoin: 1,398 Blockchain: 1,622

Adding Bitcoin and Blockchain I was just curious. But imagine if I wanted to prove popularity by using 'last year in Hacker News' in titles. It would appear that Python was 'more popular' than Bitcoin or Blockchain.

No question it's less popular than it was years ago for numerous reasons. Not sure the methodology used (google trends) tells the complete picture.

<comment><USER62> How many of those Perl story titles are some variation on "it's dead/not dead" though?

<comment><USER63> I would guess a bunch were about perl 6 since it was the new shiny.

</comment></comment></comment><comment><USER64> Perl has a well-deserved reputation as a "write-only language".

<comment><USER65> So the story goes. Care to relate some examples that show how it is worse than any other language?

I've seen mind-curdlingly horrible Perl of several varieties (novice, mad genius, and the biggest ugliest balls of mud you've ever seen), yet nothing has yet touched even the hem of the horrors I presented over-architected Java ravioli with acute patternitis.

</comment></comment><comment><USER66> When will it go away?

Simple. It will be dead when the last line of Perl goes out of production. I've just found a comment under a Rust video on YouTube that someone is still stuck with Fortran at work.

<comment><USER67> My sister is retired, but consulted with an old company she used to work for in IT. She found a comment in a header file from the 1980's. Which she wrote.

So yeah, code can hang around.

</comment></comment><comment><USER68> Off topic, but this blog loads an ad that disguises itself as a star-rating and comments indicator, which when clicked on takes you to this Mac security phishing site (at least on Safari).

</comment><comment><USER69> Does Amazon still use Perl/Mason for site template rendering? There was still a surprising amount of Perl there when I interned in '08/09

<comment><USER70> Yes it does, but not for everything, and there's certainly less new work being done with it. It's impressive that much of that code just works and no one has touched it in a long time. A lot of breakage in that space is due to new people with no perl familiarity coming in and making changes--the pool of people that understand how that stuff works is shrinking.

(Source: This morning I worked on some perl/mason at Amazon and my team owns many thousands of lines of it).

</comment></comment><comment><USER71> Never used perl but I've tinkered with (Neo)vim under the cover, which is close I think? If so, it seems like a real nice language.

</comment><comment><USER72> The only big Perl project I know is FHEM, a free smart home server that supports lots of IoT protocols and hardware.

</comment><comment><USER73> I still use it every day!

</comment><comment><USER74> No, it just (code)smells that way.

</comment><comment><USER75> Perl is dead like punk is dead.

</comment><comment><USER76> If only that were true.

</comment><comment><USER53> TL;DR some people say there's demand for work in Perl and it pays well, others say they can't find Perl work, it doesn't seem to be advertised, and they have moved on to other things as a result. A curious bifurcation.

I keep hearing about how there is demand for good Perl programmers, especially ones who know other things too, because there's so much Perl out there which needs maintenance, modernisation, or conversion to something else.

Well, I've read and written more Perl than maybe I should have spent the time doing. I'd describe myself as an expert. (I even have source for the Perl interpreter open in my editor at the moment.) However, I have used many other tools as well, so I haven't stayed in touch with Perl-using companies much.

Yet, when I go searching, I don't see much work around if I search for Perl. When people talk about demand for experienced Perl developers/freelancers etc, I can't convince myself it really exists.

Take a look in the HN "Who's Hiring?" monthly posts. Search for Perl this month: Out of ~800 positions, exactly 1 is for Perl, and Perl is mentioned in passing in only 2 others.

HN is biased towards startups, but still. Elsewhere, on the Perl-specific job sites there are a few jobs shown these days, many are "not currently hiring", and the dates reveal they are keeping old ones in the list, perhaps to hide the fact that there's only a handful in the last month. It's really not much.

On other more generic job/contract sites, searching for Perl yields far fewer options, compared with almost every other listable skill I looked at. It is quite striking.

Perl is mentioned in job descriptions, but not usually as a primary skill.

I have seen other people say the same kinds of thing: One person says there is plenty of work for good Perl developers, another replies that they can't find any and where are these jobs, and nobody answers, or they are referred to a website that has hardly anything on it any more.

Curiously, from speaking with people who work at companies that have large Perl codebases that are still being worked on, and which are hiring, this could be down to job marketing, rather than skills actually required.

Job/contract adverts from those companies either don't mention Perl, or mention it only in passing "DevOps... expert in Kubernetes, AWS, Terraform, etc. ...able to write scripts in Bash, Python or Perl".

Yet talking to people who work in those same companies, reveals Perl is something they need and look for, but they aren't mentioning in their job ads. I wonder why.

In contrast, as far as I can tell, Python is a superstar in the job market right now. It's one of just a few top skills for high day-rate gigs (along with DevOps), and this surprises me in a way, because although Python is perfectly usable, and very well supported, it's not amazing, it's quite slow, and its standard library is messy and inconsistent too.

Yet, about half of the best paid contracts I see have Python as the primary skill. There are easily 20x as many roles listing Python as the main skill, compared with Perl mentioned even in passing.

So I'd say, Perl looks almost dead and buried in the _jobs advertised_ market at the moment.

I've considering removing Perl from my resume because I think it might be starting to be a liability, a "does this make me look old" sort of thing. I use enough other things that it's not that important to me, but it's a bit of a shame. After all, as a freelance/consultant I have a substantial personal library to bring to the table, and it's a shame when I can't use it.

I can't quite decide if there is a hidden Perl-hiring market (that I haven't connected with because I've been doing other things for a few years), or if the people who say Perl developers are in demand are under a bit of an illusion, getting repeat work from the same places and not realising it's inside a small community bubble.

<comment><USER77> I second that, for like ten years on upwork and jobs.perl.org Perl has been barely present and on local job markets in most countries completely dead. I know people who moved on, found work with other languages and other technologies and who didn't, but couldn't find any work and had to do low paying non tech jobs.

</comment></comment><comment><USER78> The current state of Perl 5 for Python fans: \----

Perl 5: I'm not dead!

TIOBE: 'Ere! 'E says 'e's not dead!

Internet: Yes he is.

Perl 5: I'm not!

TIOBE: 'E isn't?

Internet: Well... he will be soon-- he's very ill...

Perl 5: I'm getting better!

Internet: No you're not, you'll be stone dead in a moment.

TIOBE: I can't take 'im off like that! It's against regulations!

Perl 5: I don't want to go off the chart....

Internet: Oh, don't be such a baby.

TIOBE: I can't take 'im off....

Perl 5: I feel fine!

Internet: Well, do us a favor...

TIOBE: I can't!

Internet: Can you hang around a couple of minutes? He won't be long...

TIOBE: No, gotta get to Reddit, they lost nine today.

Internet: Well, when's your next round?

TIOBE: Next year.

Perl 5: I think I'll go for a walk....

Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?

Perl 5: I feel happy! I feel happy!

\----

But seriously, Perl 5.30 just came out in May. It's not dead yet.

<comment><USER79> This seems like a nod to python. :-)

I started using Perl in the late 80s as a replacement to complex sed and awk scripts, but switched to Python in 2010. I still remember the day that mod_perl hit me, boom! Scaling inside Apache.. 1999 was a lifetime ago.

<comment><USER80> That's my primary use case for perl 'when it gets a little to complex for bash, just use perl'. Which is what perl was initially designed for. I never made the switch to python as it seemed to have more aspirations than that. I always thought that people who took perl further than 'great for sysadmin type tasks' were a little nuts.

</comment></comment></comment><comment><USER81> Larry Wall is 65 years old. I'm willing to bet someone is still using Perl in 2024 (just to be polite)

<comment><USER82> Isn't Larry Wall primarily using Raku?

<comment><USER81> I didn't say anything about primarily. I mean I have languages I don't use anymore, except on the odd times when I know they're the best solution.

on edit: anyway I guess my point really is the language will not be extinct until the last human user of it no longer uses it all. I don't think it is gone within 4 years.</comment></comment></comment>


Ask HN: Industrial Internet of Things (IIoT) Companies? - <AUTHOR> Long Time HNer reader posting under a new account.
I'm the PM for an Industrial Internet of Things (IIoT) project at a large US company.  We are currently undertaking a market survey looking for partners and vendors to support our IIoT project.  As a large company, we traditionally do business with other large companies, however, as a HNer, I suspect there are many excellent startup / small / medium IIoT companies flying under our radar.
I'm interested in learning more about IIoT companies and ideally, including them in our market survey.  Please post your company info here or send me a link at "iiothn [at] gmail [dot] com"
Thanks!
Note: As this is an industrial project, consumer focused companies / products are likely a poor fit <comment><USER2> It would help if you scoped your request to the parts of the stack you are looking at help with.

For instance if you are interested in soup to nuts sensors in the field to predictive maintenance software in the cloud, is very different set of companies than if you are just interested in data collection layer, signal transmission layer, storage layer, business logic or analytics layers.

You will find start ups that claim to be "full stack" but you might want to have some caution and understand what they've actually built and where it is in "in production" not in pilot or PoC phases.

The other interesting thing about IIoT start ups is that many are focused on specific verticals/application areas.

Companies involved with tracking trucking fleets versus operating drone fleets versus monitoring oil fields seem unlikely to all be relevant to you.

</comment><comment><USER3> I work in a large company and we've been trialing PTC/Thingworx. They have been painful to work with- I'm pushing that we move to a company that is more open. I'd be keen to hear other experiences and alternatives.

</comment><comment><USER4> Well, we're not solely an IIoT company, but we do have an IIoT solution: [https://inductiveautomation.com/solutions/iiot](https://inductiveautomation.com/solutions/iiot)

I think we're best recognized as an HMI/SCADA company.

</comment><comment><USER5> Spoke with the CTO of [http://www.fybr-tech.com/](http://www.fybr-tech.com/) the other day. They've definitely built some interest tech that could be repurposed for IIoT use cases.</comment>


Does SEO kill great writing? - <AUTHOR> http://blog.silktide.com/2011/10/does-seo-kill-great-writing/

<comment><USER2> I generally find it pretty simple to weave in SEO friendly terms into my writing (I'm a reporter/editor). I really don't think it's that much of a stretch</comment>


Why I've Started Using NoScript - <AUTHOR> https://www.lesswrong.com/posts/AwAA4y698dgbYfgeQ/why-i-ve-started-using-noscript <comment><USER2> >With the advent of CPU-architecture-based side channel attacks (Meltdown and Spectre are the most publicized.

I thought they repaired since 1.5 years when they let it to the public (inside Microsoft some knew about the danger)

Is it still a threat?

</comment><comment><USER3> what are people's experiences with NoScript vs uMatrix? i switched from uBlock Origin to uMatrix, and that works pretty well and can block e.g. iframes, too. but i'd be open to blocking all Javascript, which uMatrix doesn't do by default AFAIK

<comment><USER4> I wrote a super simple global Javascript toggle plugin for Chrome because I was tired of manually toggling it in the preferences. Currently I believe I'm the only user, but I use it every day. It doesn't collect / send any data anywhere, it literally just toggles Javascript and reloads your open tabs. I wrote my own plugin to do this simple thing because I don't trust other people to make simple things and just leave them alone. Feel free to use it if you'd like.

[https://chrome.google.com/webstore/detail/js- toggle/bnhjfamo...](https://chrome.google.com/webstore/detail/js- toggle/bnhjfamolmolljikdopibpabimjfellc?utm_source=chrome-ntp-icon)</comment></comment>


How we spent $30k in Firebase in less than 72 hours - <AUTHOR> https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-less-than-72-hours-307490bd24d <comment><USER2> When you have an unexplained performance problem, your response shouldn't be to "upgrade every single framework and plugin" that you use. The 36 hours that they spent doing this cost them $21,600 dollars on GCP and didn't solve their users' problem.

Understand the services you depend on. Track the number of requests you're making to them, how long they're taking, and how many are failing. Reason through your system and look at the data when you have issues, rather than grasping at straws.

<comment><USER3> I mean this in the nicest possible way: I see this all the time with the JavaScript set and I am absolutely not the least bit surprised. I used to work on a team that was TypeScript top to bottom, with people who didn't really even understand how to debug (they were mostly bootcamp juniors). Whenever something would break, if restating it didn't work, you know what they'd try? Yup, upgrading random dependencies. Refactoring was also pretty popular, although it usually just ended up making things more complicated.

It's silly to suggest that JavaScript itself is somehow responsible for this. It's obvioisly just a tool. But I have to say, the most professional cluelessness I've ever encountered was in the JS ecosystem.

<comment><USER4> So I completely agree, but let me play devil's advocate.

If you do go and track down the problem in your depedency and file a bug, one of two things is likely to happen: they close it and say it's fixed in the latest version or they refuse to accept your bug because it's filed against an old version.

Skipping the track it down part and just jumping into upgrading can be a time saver. It works fairly well if you fit into the 'common' part of the user base with frequent updates. (Incidentally dependencies with frequent updates are kind of a pain)

<comment><USER5> > _If you do go and track down the problem in your depedency_

This is the part the parent's cow-orkers didn't perform. There's nothing wrong in updating a dependency to include the fix for the problem you're experiencing. But the people in question were apparently too lazy/clueless to even track down the problem, opting for randomly upgrading stuff instead.

</comment></comment></comment></comment><comment><USER6> This is why infinitely scaling pay-as-you-go cloud services terrify me.

I refuse to use a service like this unless it gives me the ability to automatically cap costs and alert me when thresholds are met.

All it takes is a rogue line of code in an endless loop or something, and you are bankrupt.

Their site seems pretty basic. I'm struggling to understand why they couldn't just run it with something like Postgres for less than $100 a month on AWS?

<comment><USER7> Product Manager for Cloud Firestore here. It's worth noting we do have the ability to set hard daily caps, as well as budgets that can have alerts tied to them. It's something we also looking at ways to improve it.

<comment><USER8> >Product Manager for Cloud Firestore here. It's worth noting we do have the ability to set hard daily caps, as well as budgets that can have alerts tied to them. It's something we also looking at ways to improve it.

Google Cloud user here. A warning: If you ever happen to get, say, frontpage on reddit or techcrunch or other big boost to publicity, your site could be down until the next billing cycle (i.e. 24 hours) and you will have no way to fix it.

This bit me hard one day with appengine and lost us a ton of converting traffic, even though we tried to get the limit increased within ten minutes of the spike (and well before our limit was hit).

<comment><USER9> So basically we want to have cake and eat it too.

<comment><USER10> This seems like an overly cynical/snarky response.

It's not an unreasonable request that for services which advertise the ability to scale up and down on demand, that the billing and billing limits should also be able to respond similarly.

<comment><USER11> >that the billing and billing limits should also be able to respond similarly

How so? With a pay-as-you-go system, firing off warnings and giving a projection of their future costs (which is hard when startups tend to have spikey traffic) is about as good as you can do.

Edit: I should add that the common solution to controlling your billing in situations like this is having some overflow path built into your beta app ("Sorry, we're not taking new users at the moment" or the like).

<comment><USER12> The problem is that the user gets those alerts, tries to change the limit they set, and it doesn't work. That is definitely not as good as can be done.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I spend a fair amount of time on HN.

Among many, I think this article is probably the most succinct endictment of ADHD-ridden "modern" web programming/ecosystem practices I've read.

It's so sad to me that while the name dropping and churn for frameworks and languages continues, frenzied and unabated -- basic (pun sort of intended) analysis and problem-solving techniques go out the proverbial window.

Why learn to _think critically_ when you can just 'npm update', fix 37 broken dependencies, and write a blog post about it? Right?

<comment><USER14> Critical thinking is a learned skill. For most developers it comes with experience, and many developers in startups are often yet to learn it. Thinking well under pressure is even harder.

This is more a problem about startups using inexperienced developers than anything related to what they're building or which tech they're using.

<comment><USER15> It comes with experience, but also with more senior devs explaining it to you.

Seing someone use firebase to save paiements, then recompute a total from a collection, and as a consequence having its system explodes with less than one session per second, means everybody in the team drank the « let's use this nosql google shiny tech, it's so cool » cool aid.

Even one conversation with any senior dev having some kind of experience with backend development would have asked about expected load, types of queries, data model, etc. And concluded that storing paiements was probably the least interesting scenario for using a tech like firebase.

</comment></comment></comment><comment><USER16> Definitely looks like several "teach-able moments" here: They learned the hard way about:

1\. Developing a fix without understanding root cause (try-something development)

2\. Sufficient testing, including load testing, _prior_ to initial deployment

3\. Better change control after initial deployment

4\. Sufficient testing for changes after initial deployment

5\. Rollback ability (Why wasn't that an option?)

6\. Crisis management (What was the plan if they didn't miraculously find the bad line of code? When would they pull the plug on the site? Was there a contingency plan?)

7\. Perfect being the enemy of good enough

Looks like they were bailed out of the cost but what if that didn't happen?

<comment><USER17> Try-something is very useful as a troubleshooting tool, when you need to change the state of the issue enough to collect further troubleshooting information.

<comment><USER18> I think "try-anything" would be a better characterization in this case. They had smoke pouring out of the engine and tried changing the tire.

<comment><USER17> No disagreement there.

I don't understand how you can build a complex application like that without doing basic performance checks like, are we hitting the file system or database too often, our the image assets correctly sized, etc.

I'm not a software engineer however.

</comment></comment></comment></comment><comment><USER19> Anyone else feel like they'd rather have their dedicated server slow down instead of wrack up a $30k debt?

This is this nightmare I envisioned with cloud services, a client gets hit really hard, and I have to pass the bill on to them.

This reminds me variable rate mortgages.

With dedicated hardware, you may end up with performance issues, but never a ghastly business-ending bill. How does anyone justify this risk? I really don't understand the cloud at all for such high cost resources with literally unlimited/unpredictable pricing.

Can someone explain this risk/reward scenario here?

<comment><USER18> > How does anyone justify this risk?

I'm more concerned about the risk mitigation strategies (capping) I'm seeing advocated.

If your servers being pegged you've only got a few customers missing out while it's pegged, maybe even everyone getting service but sub-optimally. You can ride out the wave and everything goes back to normal.

Putting caps in place is like pulling the plug out of the server after the CPU has been at 100% for 5 minutes and not plugging it in until the next billing cycle.

</comment></comment><comment><USER20> I find ridiculous that their first solution was to go and upgrade to another Angular version, especially a non-beta version upgrade of a framework that is used in thousands of super high traffic websites with no problems. How clueless can you be?

<comment><USER3> > How clueless can you be?

I mean, if you're junior and you've just learned JavaScript, it's not difficult. I've met a lot of monied people who seem to think a junior dev with a few weeks of JavaScript training is equivalent to a senior engineer with a degree. It never works out, at least not for the smart people.

<comment><USER21> Why are you so against junior devs? I've personally never met a junior dev who just starts going ahead and upgrading various dependencies, as you suggest.

If anything, that shows a lack of proper hiring decision on you and your team's part.

I do, however, agree that their practices are horrible (just look at their console, they're console.logging random things, running the dev mode of Firebase, and fetching some USD conversion call 10x on load with no caching) and they're lucky Google bailed them out at the last minute.

<comment><USER3> > If anything, that shows a lack of proper hiring decision on you and your > team's part.

Hey, friend! I had no control over hiring for that gig.

</comment></comment></comment></comment><comment><USER22> I can't say enough good things about Firebase and GCP in general, but I'm always cautious when using Firestore in particular. I usually avoid unbounded queries altogether, and treat it primarily as a key/value store to get by id.

When I do use queries, it's always in places where the results have a well- defined limit (usually limit = 1), e.g. finding the most recent X or the highest X.

With the above two, you get all the greatness of Firestore, but with a well- defined (low) cost that you can calculate ahead of time.

<comment><USER7> We've also been rolling out updates to rules to enable you to enforce these types of things. There is performance implications to limit queries for the real-time update system at scale, but for most use cases this shouldn't be a problem.

Definitely more we can improve here for control, and we're open to feedback.

<comment><USER23> Hey, thanks for listening.

I believe in short time would be nice to have a way to use for the query the create, update and write time of a document. Now, I am doing the creat time manage inside of my document with Date.now(), but when I was running a bunch of promises to create the documents, the createTime between the documents that I was manipulating was in same case the same, so my pagination failed.

Another things, like compound queries inside of subcollections should be nice. A way to export all the database for backup.

A flag to alert the Firestore to return the document when I do an update in this document in the same response (one round trip (dynamoDb has it). I know I can reach this goal witht transaction, but I believe it is simpler than a transaction.

A way to update a array without transaction.

Thanks

</comment></comment></comment><comment><USER24> The saddest thing here is that they seem proud of this "mistake" and how they solved it.

This startup mindset is not always good.

</comment><comment><USER25> I feel depressed about this, on how the industry promotes and even supports extreme technical incompetence. Maybe is a consequence of "everyone should learn to code" campaigns and bootcamps.

<comment><USER26> Cheer up buddy, you were this incompetent at one time too, but now look at you, a full grown narcissistic asshole senior developer. You have come a long way and these kids will too!

</comment></comment><comment><USER27> I increasingly feel that modern pay-as-you-go services are so opaque to consumers that it takes the individual employee's empathy (highly subjective) or the publicity like this (highly subjective _and_ you have to be lucky as well) to fix any significant problem. Every time a post like this with a "happy" ending crawls into the HN front page, there would be hundreds or maybe thousands of "unhappy" endings out there.

</comment><comment><USER28> Simple stress tests should've revealed this. Basic profiling should've revealed this. This article makes it appear that they've went live without ever really testing the infrastructure under any kind of load whatsoever.

The article refers to some mysterious "engineering team". It would appear very little actual engineering took place at that company.

</comment><comment><USER29> Some have mentioned it here already, but I'd like to emphasis how important application logs are. How much trouble you can prevent by reading and understanding them.

I've seen and fixed such bugs as described in the article, and before you start trying to upgrade anything a look in the log followed by a git bisect session is the first step.

My rails apps have great logs, I get to see what views and partials are rendered, what queries are sent to the database and more important how often all that happens. If the log excerpt for a single request doesn't fit on my screen I know I have to do something.

</comment><comment><USER30> "It is very important that tech teams debug every request to servers before release..." No.

You should know your application's profile, you wrote it.

How many resources does you app need? That's something our developers believe is the "operations team"'s responsability. Well, now that you took the 'devops' role you can no longer keep ignoring this. Your new infrastructure provider will be more than happy to keep adding resources, one can only hope the pockets are deep enough.

With attention to the profile this would have been caught at developing time, maybe testing time.

</comment><comment><USER31> >with every visitor to our site, we needed to call every document of payments in order to see the number of supports of a Vaki, or the total collected. On every page of our app!

Oh that will do it.

</comment><comment><USER32> "Besides they understood errors like ours can happen when a startup is growing and some expensive mistakes can jeopardize the future great companies."

Doesn't sound like a future great company to me, especially when their lesson from this was Google will bail them out and "It is very important that tech teams debug every request to servers before release." rather than hiring less cavalier employees and putting in better process.

</comment><comment><USER33> I've been noticing a steady rise of posts from hackernoon by amateur developers who think they'll be the next great tech blogger. I'm not saying I could do any better, but why are these posts suddenly getting so much attention?

<comment><USER18> > but why are these posts suddenly getting so much attention?

The same reason we slow down for car crashes, morbid curiosity. I don't think there is anything "sudden" about it though, we even have sites like thedailywtf dedicated to this level of idiocy.

<comment><USER34> thedailywtf: making fun of other dvelopers' incompetence

hackernoon: author patting themselves on the back while everybody else is laughing at their incompetence

</comment></comment></comment><comment><USER35> Disclosure: I work on Google Cloud (but not Firestore or Firebase).

For those that didn't read the article, it had a happy ending:

> GOOGLE UNDERSTOOD AND POWER US UP!

> After we fixed this code mistake, and stopped the billing, we reached out to > Google to let them know the case and to see if we could apply for the next > grant they have for startups. We told them that we spent the full 25k grant > we had just a few days ago and see the chance to apply for the 100k grant on > Google Cloud Services. We contacted the team of Google Developers Latam, to > tell them what had just happened. They allowed us to apply for the next > grant, which google approved, and after some meetings with them, they let us > pay our bill with the grant.

> Now we could not be more grateful to Google, not only for having an awesome > "Backend As A Service" like Firebase, but also for letting us have 2 million > sessions, 60 supports per minute and billions of requests without letting > our site go down. Besides they understood errors like ours can happen when a > startup is growing and some expensive mistakes can jeopardize the future > great companies.

<comment><USER36> Perhaps somewhat optimistically, I assume most of the commenters read the whole article, but I don't think the happy ending abates the concern. It's great the Google Cloud team was able to bail them out afterwards, but the fact that they were able to rack up a $35,000 cost on a code mistake still highlights one of the major flaws with pay-as-you-go cloud computing.

There's no guarantee if I made the same snafu next week that Google would necessarily be willing to help, but I can absolutely guarantee you that a VM sitting on a Dell PowerEdge I've got lying around would suddenly obligate me to a $35,000 bill, no matter how bad my code.

Ideally, I guess I'd want to see rather than a hard cap, some sort of smart alert that would go "holy crud, this is an unusual spike in the rate of requests" when the delta changed unusually, rather than waiting until I say, hit a high static cost bar or a hard cap that kills the site.

<comment><USER35> Right, I don't deny that (and didn't mean to imply this isn't a problem). At the time of my comment it did seem like most people stopped before the end :).

Budgets and quotas are really tricky as Dan pointed out elsewhere in this thread. App Engine has had default daily budgets (that you can change) forever, but then you run into people saying "What the hell, why did you take down my site?!".

In this case, they even _intentionally_ pressed forward once they saw their bill was going up. If this had been say a static VM running MySQL with a "SELECT *" for every page view, the site would likely have just been effectively down. For some customers, that's the wrong choice, even in the face of a crazy performance bug.

That said, we (all) demonstrably need to do better at defaults as well as education (the monitoring exists!).

<comment><USER37> That, or, as explained in the SRE book, the extra load should've been shed. The binary choice is not always the right one. Though, granted, in this case, it wouldn't have mattered...

<comment><USER36> Yeah, I think "the web server ran out of money at 3 PM today" isn't the right choice, whereas "a lot of people had a hard time getting to the site when it got HN'd around 3 PM, but it was back to normal by 5 PM" is a better result.

For smaller organizations, something being down during extreme load is a recoverable problem, but owing the cloud provider all of their money may not be. (Note that even in the case here where Google got them the grant to cover this bill, this is still probably 35K in grant money that could've gotten them further or been used better elsewhere.)

</comment></comment></comment></comment></comment><comment><USER38> A lot of people here talks about lack of load testing and other "do it the right way" type of advice, but remember this is a startup. In my opinion, solid testing foundation will be such an overkill and the time is better spent on implementing more features.

Also I bet they did some manual testing. They didn't catch it because this latency can only be seen by the account with a lot of followers.

I agree that their first solution to upgrade is a bad idea... You should understand what caused the bug before trying to fix it.

I highly encourage you to monitor the load/pay/request graph on a daily basis. Even better if you hang a screen on the office that displays these. The graphs are already provided by Firebase. That way you can catch these type of anomaly on day one. Also Firebase supports "Progressively roll out new features" [https://firebase.google.com/use-cases/#new- features](https://firebase.google.com/use-cases/#new-features)

<comment><USER20> Lack of testing and poor code quality are completely different things though.

</comment></comment><comment><USER39> The blog authors should state up front that Google covered the costs with an additional startup grant, and that this was entirely due to a quadratically expensive query.

</comment><comment><USER40> _" We contacted the team of Google Developers Latam, to tell them what had just happened. They allowed us to apply for the next grant, which google approved, and after some meetings with them, they let us pay our bill with the grant."_

Makes for an interesting counterpoint to the currently popular "Google is evil" narrative. The truth is probably much more mundane: Google is an awful lot of people trying to work together to achieve a bunch of shared goals and doing an imperfect job of it. This isn't just rose-tinted: I'm quite sure they have their fair share of bad actors, and they certainly make decisions we don't all like (e.g., retiring products), but I don't think it's because the company is fundamentally evil.

<comment><USER41> I agree with your argument, but I don't think that people are calling Google evil because they retired some products. See [0], which was resolved (I think, though I can't find a source for that) due to the fact that Google is comprised of a lot of different people, and [1], which is a fairly recent announcement that has made some people uncomfortable.

[0] [https://news.ycombinator.com/item?id=17202179](https://news.ycombinator.com/item?id=17202179)

[1] [https://news.ycombinator.com/item?id=17660872](https://news.ycombinator.com/item?id=17660872)

<comment><USER42> For me, I find what they're doing with android pretty evil (disallowing manufacturers from also offering phones with alternate distros/os')

</comment></comment></comment><comment><USER43> But did you see the slow down in the request to firebase before going to upgrade frameworks?

</comment><comment> shady-lady Words fail me as to how anybody could put something live without understanding how the application functioned as a whole. Unbelievable.

</comment><comment><USER44> This is another good reason to properly test before going live. If their site wasn't cloud hosted it would have just fallen over, most likely. Which means a failed crowdfunding effort. Maybe take off the cowboy boots, guys?

</comment><comment><USER45> "This means that every session to our site read the same number of documents as we have of number of payments. #UnaVacaPorDeLaCalle received more than 16,000 supporters, so: 2 million sessions x 16,000 documents = more than 40 Billion requests to Firestore on less than 48 hours."

TLDR; Horrible architecture decisions like this can be very costly.

<comment><USER46> I wouldn't call it architecture decision. It's the equivalent of a bad SQL query.

<comment><USER47> A bad sql query wouldn't do that. Look at their site, from the US, it calls cloud functions for a COP to USD conversion, on each place they render a currency (200+ requests just going to their homepage). I think it was built poorly, but that's just my opinion.

<comment><USER20> I agree with you. There are so many ways to make this infinitely more efficient. For starters, why are they re-calculating and re-rendering the value every time they get a new donation? Also, they could store those values in a more cold&cached-storage and just make the reads to update from Firestore. Don't use a freaking database that is charging you for every single read and write, to deal with mundane client-side renderings.

</comment></comment></comment></comment><comment><USER48> > we were using Angular V.4 and we decided to upgrade everything to V.6. It > was a huge risk and we wanted this campaign to be perfect, so we did it! In > just a day and a half, our team had the first release ready in the new > version. After some tests, it looked like the refactor helped the app's > speed, but it was not as fast as we wanted it. Our goal was to load in 3 > seconds and it wasn't working as we expected.

You want it perfect and you cannot afford to put down the site but you're willing to take a "huge risk" based on (wrong) guesses, with clearly not enough time for proper QA. I sincerely suggest you to slow down and reflect on priorities and risk assessment, there's a reason if that firebase code slipped through. By the way I'm happy you avoided the worst case scenario, good luck with your project

<comment><USER49> > I sincerely suggest you to slow down

That runs counter to the great Silicon Valley ethos of moving fast and breaking things

<comment><USER50> The moving fast breaking things guy came from the east coast.

</comment></comment></comment><comment><USER51> The thing I'm wondering about with the seniority of the dev team and what the code commit and code review process is. It seems like with a senior dev reviewing commits, someone would have caught that redundant work was being done.

I worked at a startup in the Mission for a few months and I remember seeing a quadratic query that ran for every customer that was logged into our application. The CEO and team lead wondered why our app worked great in Dev (with only 5 users) but was terrible on premise (250 users). When I tried to explain the issue the two devs before me didn't really understand what I was talking about. It was a quick refactor and caching solution that fixed the problem, but it was clear that the development was still new.

</comment><comment><USER52> The issue with GCP and AWS providing limitless scaleability is that bad code gets a free ride and we all occasionally write bad code. If the OP had tested this on a database with 1 CPU server with 2GB RAM, they would have caught it quickly in early dev testing.

</comment><comment><USER53> The company success is good, but the SELECT ALL query is a shame bigger...

<comment><USER54> It shouldn't be _possible_ to run select all in production.

</comment></comment><comment><USER55> So it's a classic N+1 query?

<comment><USER56> It's more like (in good old RDBMS world) 'SELECT * FROM payments' and calculate sum on client vs 'SELECT SUM(amount) FROM payments WHERE some_id = ?'

though they already had this sum precalculated

<comment><USER57> That would be more forgivable. This is:

      SELECT * FROM payments where paymentID = 1
      SELECT * FROM payments where paymentID = 2
      SELECT * FROM payments where paymentID = 3
      ...
      SELECT * FROM payments where paymentID = 14986

Each of those in its own API request over the wire, then sum them on the client.

</comment></comment></comment><comment><USER58> | How we spent $30k in Firebase in less than 72 hours

By not checking Google Billing after you launch your website. At the very least you should have a billing alert.

<comment><USER59> At the very least Google (and really all cloud services) could have reasonable default billing alerts built in. And automatic spike detection.

I'd rather have default alerts already configured that I can change, rather than none.

</comment></comment><comment><USER60> And that's why people write applications to understand and track your public cloud usage, like [https://github.com/trackit/trackit](https://github.com/trackit/trackit) ... Most people simply can't follow through what's happening in their cloud apps.

</comment><comment><USER61> So what is their product? Can't read spanish, and don't use chrome for translate.

<comment><USER20> A GoFundMe kind of platform, that allows groups of people to put funds towards a common goal (like a party or whatever)...in this case they used it to donate to a politician who had a huge debt after losing an election.

</comment></comment><comment><USER62> Wow, a complete shitshow which could've been avoided by consulting with 1 experienced developer good at debugging. This kind of negligence must be happening more than what we think so there are lots of opportunities out there.

</comment><comment><USER63> Gosh. One for [https://accidentallyquadratic.tumblr.com/](https://accidentallyquadratic.tumblr.com/) with the added spice of being on usage billing...

</comment><comment><USER64> This reads less like a "mistake", and more like just not giving any thought to what your code is doing as you write it. A mistake would be if the programmer meant to implement X but instead implemented Y; this sounds more like the programmer just set out to implement Y without even considering other possibilities.

Same for the framework change. An outdated framework might be a second or so slower, but a >30-second load time was never going to be fixed by updating. This is just bad problem-solving skills. When your app is taking 30 seconds to load, you don't just guess at what might make it faster -- you open your JS console and your log files, and you figure out where that time is being spent. Two minutes in the Performance tab of Chrome's developer tools, and you would have figured out the issue was on the back-end rather than the front-end.

<comment><USER12> They calculated a number the wrong way. That's not a hard mistake to make. And changing frameworks is silly but not really part of the problem.

</comment></comment><comment><USER65> If there's one thing Google App Engine has taught me, over the course of 5+ years using it:

Denormalize your data (or, optimize for read).

<comment><USER15> Just a precision in case a junior dev read this comment : denormalizing has nothing to do with the problem experienced by the OP. They just queried the whole collection of paiements instead of precomputing a total everytime a new paiement arrived.

Denormalizing would have required having a relation between collections. Here there was just one (so there was nothing to denormalize).

Optimizing for reads ( or simply think about read performance) doesn't require denormalizing. It can also be a matter of creating an index, or precomputing values in a cache, like in OP case.

</comment></comment><comment><USER66> My only issue - Where were the metrics around firebase request count? That could have been a simple dashboard.

</comment><comment><USER67> It seems like they:

* didn't have good testing

* did no load testing before

* had no code reviews done

* no design reviews done

* had no or very less (useful) application logs

* had no change control mechanisms defined or followed (upgrade a framework in production in a matter of minutes or hours as a way to wing it out and pray for it to work out?)

* had no or very little automated tests

* didn't have a detailed post mortem or root cause analysis to see what they could do to prevent it (the ending looked quit amateurish, by pointing to only one thing as a potential lesson)

* wasted a lot of money that could've helped in the future (by instead using that to pay for en error)

If I were in such a team, I would've honestly stated in such an article how deeply ashamed I am that we missed all these things, how "cowboy coding" and heroics must never be glorified, how we got very, very lucky in someone else waiving off charges (this is not a luxury that most startups or one person endeavors would have), and ended with asking for advice on what could be done to improve things (since it's obvious there were many more gaps than just how a few lines of code were written).

To the team that wrote this code and this article — get some software development methodology adopted (any, actually) and some people who can help you follow any of those. Also read the rest of the comments here. You got very, very lucky in this instance. It may not be the same case again, and you may see your "life's work" get killed because you didn't really learn.

<comment><USER68> If they had half of the above they wouldn't use Firebase. Don't get me wrong I think it is a great product and I would use it for MVP but the idea of using Firebase is to get something scalable easily and quickly by focusing on the frontend only. You can tell from their screenshots that they were only focusing on GA metrics and didn't check Firebase console

</comment></comment><comment><USER69> Go serverless boys :)

<comment><USER23> It won't resolve the problem

<comment><USER69> AWS Lambda costs about 20 cents per million requests. A billion requests would have put it just a little south of 200-300 dollars. Factor in a few additional read units for DynamoDB, but I don't see it going to total $30,000. The serverless architecture should scale as well.

<comment><USER23> They are using serverless architecture. Firestore is a "Daas". The latency for loading the page wasn't the real problem, it was the side-effect. The real problem resulted in 40bilion request, they were requesting all the collection of payments in each session. It reaches 16K documents downloaded /session, so they were paying 16K reads documents for session. Firestore gives you 50K reads/day for free, and ask $0.06 for 100K reads. So It was a really bad logical approaching from them. If they did in a best way , like update a document that holds the two accumulators : total money accumulated and total payments created, and read just this document in each session request their bill to show this information for 2M session should be less than $2, because you are reading 1 document for session instead of 16K documents. And pay attention that their system wasn't down, probably the 30s latency was a side- effect of downloading 16K document of each payment information in the client side.

</comment></comment></comment></comment><comment><USER70> But wait, the image shows ~$600 million. So $30K is small.

Maybe that ~$600 million isn't in USD?

<comment><USER71> The first sentence in The Fine Article mentions Colombia, whose Peso uses "$" as its symbol, and currently has an exchange rate of ~2900:1 USD.

<comment><USER70> Thanks. And I did miss the "COP" in front of the $ amount :(</comment></comment></comment>


How World of Warcraft led to Glassdoor - <AUTHOR> http://www.businessinsider.com/how-world-of-warcraft-led-to-glassdoor-2015-5 <comment><USER2> It takes about 3-6 months to level up to top level in WoW playing occasionally. I am very skeptical he "played for a year nonstop and then I hit the maximum level in WoW."

He goes on to say that "I was maniacal in chasing this goal and literally the next day I started a company, Glassdoor."

This are ridiculous statements for any WoW player. Leveling up is considered almost a "tutorial" to the "real" game that starts at top level, which is where everyone is at.

I can't see someone that was serious abot WoW making this statement, and it seems that he's either badly misquoted or he is not sincere.

<comment><USER3> I imagine it was to reach Rank 14 in PvP rather than to hit the level cap. Even at the very start of the game, it took only 11-15 days in-game time to reach level 60.

<comment><USER4> I agree that it's likely the PvP rank. I could definitely see that taking a year or longer. Although plain old level 60 is still plausible - while it only took 11-15 days to level 60 if you knew what you were doing, a lot of us took longer than that because we took a roundabout route, whether out of fun or ignorance -- or leveled multiple characters before picking one, or maximized our tradeskills while leveling as seemed logical initially, etc.

</comment></comment></comment><comment><USER5> This is a pretty interesting story, and speaks to the oft-cited leadership and goal-pursuing qualities that playing a major MMO can foster.

On the other hand, like many others, I've also seen brilliant developers seriously stagnate their careers thanks to video game obsessions.

I got a kick out of this tidbit, too:

 _> In fact, Glassdoor wouldn't even be around if it weren't for StarCraft's older, sister game, World of Warcraft, he tells us._

I think the journalist is either confusing WoW and Starcraft 2, or was talking about the Warcraft vs. Starcraft series in general.

<comment><USER6> I think the "confusion" stems from the fact that this article is basically at the same level of quality as any other by Business Insider, i.e. void of content and filled with the traditional hype/BS on "how to be a phenomenal founder", "what entrepreneurs do during their 60hr work day", "how to learn to code", "how to build a startup without learning to code", etc...

<comment><USER7> Generally, there's a good chance that most of these kinds of "Wtf?" logic errors are on the part of the journalist, not the person being interviewed. In the U.S, journalists don't send drafts over for comments, and rarely change published material, so there's little opportunity to get misleading stuff corrected.

</comment></comment></comment><comment><USER8> >To this day he runs his 450-person startup... I guess reporting about non- startups just isn't cool anymore.

<comment><USER9> I think that's just the word for any company that doesn't seem to be sustainable in it's current form. (e.g. VC funding expecting an exit)

</comment></comment><comment><USER10>
        At 22, I went to work at Microsoft. When I tell young people that today, they look as if they are embarrassed for me. And I have to tell them, 'No, no — it was like getting hired at Google back then, or Facebook. This was 1993.

Who on earth is reacting like this?

<comment><USER11> Precisely what it says: young people.

Source: I'm majoring in CS in university right now, and most of my colleagues hold startups/Facebook/Google in high prestige, while older companies such as Amazon and Microsoft are often seen as second tier.

<comment><USER12> Amazon was founded in 1994, Google in 1998. Do those four years really make the difference? I believe the reason for Google being hold in high prestige must lie somewhere else than being a 'young' company.

<comment><USER11> I think Amazon and Microsoft are also known as being bureaucratic-heavy companies, another big factor against being a good place to work as a software engineer (at least this is the impression we have been given).

</comment></comment></comment></comment><comment><USER13> I don't really get how WoW led to Glassdoor, just because he got a call the day after he hit 'max level'. Correlation does not imply causation.

</comment><comment><USER12> > StarCraft's older, sister game, World of Warcraft

That's not the way I remember it (unless you make that StarCraft II).

Small errors like this always make me wonder how thorough the writer was with the rest of the article.

<comment><USER14> Of course it meant StarCraft II. Just the sentence before he says he is currently playing StarCraft with his sons, so it's unlikely to be the original.

</comment></comment><comment><USER15> This is a nice PR piece for a company that looks like its innovating in a business space where a lot of dollars change hands. I'm not going to pile on with the worrying over WoW details. I thought the reporter did a good job. Well done.

Having said that, from a startup business analysis point of view, is it just me or is everybody and their brother trying to get into the technology jobs sector? Don't get me wrong, there's plenty of room for innovation and somebody is going to make a killing here. Godspeed, guys. But geesh. With so many players and so many moving pieces, sure looks like a tough row to hoe.

</comment><comment><USER16> It took him a whole year to hit max level?

<comment><USER17> I started WoW in december 2005, and hit 60 in februari.

Also, when you reach max level, doesn't mean you finished the game. There is tons of instances to do, special loot to earn, and other stuff; even in 2006.

<comment><USER18> I actually hear many many times that the game _starts_ when you reach the top level ^^ I've unfortunately never played the game enough to confirm though

<comment><USER19> It depends on what you do, and what you want from the game.

For me, I like levelling, so, once I have levelled, and got geared up (which is incredibly fast these days), it is onto the next alt.</comment></comment></comment></comment>


Ask HN: What to do if your CV is too bad to get an interview? - <AUTHOR> Hi HN,
I'm in my mid-thirties, and my CV basically contains only two items (plus four foreign languages at different levels): a bachelor degree in CS and a two-year programming job (from which I got fired). The rest of the time I struggled with (mental) health issues (depression, anxiety, injuries from a suicide attempt).
That's not much, considering my age. And it seems to be not attractive to potential employers, because so far I was unable to get invited to any interview. I guess the long period of health issues/unemployment is a big red flag. And there is also the issue of not being up-to-date with current languages/tools/practices, though I don't know how much that matters for entry-level jobs.
I'm not sure what I could do to improve the odds to pass this first hurdle. While I can work on the outdatedness to some degree, I cannot change the past. And of course, the second hurdle, the interview, still awaits. Probably with low odds, too, due to being a listener/observer and not a talker (for the first job I had to interview at more than twenty companies before getting an offer, though getting the interviews was not much of a problem back then).
Any ideas, thoughts? Thanks in advance. <comment><USER2> Try contracting; set up as a limited company and offer your services through that.

</comment><comment><USER3> Work on your side projects.

Go out to hiring events and network.</comment>


RDDs are the new bytecode of Apache Spark - <AUTHOR> https://ogirardot.wordpress.com/2015/05/29/rdds-are-the-new-bytecode-of-apache-spark/

<comment><USER2> The API is great and very useful for Python coders. The Scala version uses strings to identify fields. Haven't run the example code, but it seems to essentially encode a form of run time type checks instead of compile time type checks. Which is an odd API choice for Scala.

<comment><USER3> It is actually not possible to enforce type checks at compile time, due to the dynamic nature of data (e.g. you can generate a DataFrame from JSON files whose schema are automatically inferred by Spark, or generate a DataFrame by loading a table in Hive). There is simply not enough type information available at compile time, unless we rule out all these cool use cases.

There's one past attempt at making it more type safe by using macros. However, there are a lot of caveats for that to be used in practice. [https://github.com/marmbrus/sql-typed](https://github.com/marmbrus/sql-typed)

<comment><USER2> It's software, everything is possible :) It is fairly straightforward to add compile time information via a simple case class definition. There is still a dynamic type check that json matches the case class, but the spec of the structure of the data is done in one place, not spread out arbitrarily over the query code base.

<comment><USER3> That part is actually coming: [https://github.com/apache/spark/pull/5713](https://github.com/apache/spark/pull/5713)</comment></comment></comment></comment>


Adobe Discontinues PhoneGap and PhoneGap Build - <AUTHOR> https://blog.phonegap.com/update-for-customers-using-phonegap-and-phonegap-build-cc701c77502c <comment><USER2> My team has been working on a modern alternative for a few months now. With a couple months of beta under our belts, we're ready to go live tomorrow (Aug 11) at noon EST. Our goal is an easy-to-use standalone service. Visit us at [https://volt.build](https://volt.build) to sign up and start building! New signups are free for 30 days.

PS. I've been a PG user since 2010. Many fond memories of the early days!

<comment><USER2> Here's the Migration Guide:

[https://volt.build/news/2020/08/12/migrating-from- phonegap.h...](https://volt.build/news/2020/08/12/migrating-from- phonegap.html)

</comment></comment><comment><USER3> End of an era, truly. We're ready to help PhoneGap and PhoneGap Build devs migrate to the Ionic platform and avoid any disruption!

Our cloud build service Appflow is a 1-1 alternative for PhoneGap Build but with some awesome additional features like live updating and app store submission. More info: [https://ionicframework.com/blog/phonegap-build-no- longer-mai...](https://ionicframework.com/blog/phonegap-build-no-longer- maintained-by-adobe/)</comment>


Show HN: Directory Tags for Lazy Programmers - <AUTHOR> https://github.com/joowani/dtags <comment><USER2> Looks sweet will use. Some however might be happy with using existing command "pushd" to save there current working directory that is in almost every shell ever including dos! This does have more feachures but sometimes you have enough to work with the defaults (i.e. other people machines) too.

</comment><comment><USER3> This is interesting! Reminds me of something I made for an operating systems course.

Mine was called ctags and allowed you to tag processes. First it was implemented as a lkm, then was reimplemented inside the kernel as an additional field in the process struct (forget what its called).

</comment><comment><USER4> For macos I feel like [https://github.com/jdberry/tag](https://github.com/jdberry/tag) is probably a better solution.</comment>