Is Perl 6 Being Renamed? - <AUTHOR> http://blogs.perl.org/users/ovid/2019/08/is-perl-6-being-renamed.html <comment><USER2> To my mind, the blockers for Perl 6 adoption in order of importance have been:

1\. The name, saddling it with the legacy of Perl. (I say this as someone who really liked working with Perl back in the waning years of the old millennium, and believes that Perl was visionary in pointing the way to the state of modern programming... but also that it had some limitations that have only become more glaring over the years.)

2\. The coyness around whether it's "done" or not. Right now today, as someone who has paid attention to Perl 6 and even written some toy code with it, I do not understand its release status at all. That's absurd.

3\. The insistence on branding sub-components of it and exposing that branding. Yes, it has a VM. Yes, it has a compiler. But why do people talk about ParrotVM and Rakudo as if they're different things? Java has a compiler and a VM, they're called "javac" and "jvm." This wifty "no, Perl 6 is the standard, the software you're running is Rakudo and Parrot" distinction is totally irrelevant to anyone actually wanting to write code, and weirdly confusing.

4\. In a distant, distant last place: any actual functional stuff about the language.

<comment><USER3> > But why do people talk about ParrotVM and Rakudo as if they're different > things? Java has a compiler and a VM, they're called "javac" and "jvm."

Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible.

Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others.

When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.

<comment><USER2> Sure, but most people don't know or care. They just type "python" and Python happens. If they need to find another implementation, it's possible, but there's no question about what the default implementation is.

<comment><USER3> > Sure, but most people don't know or care.

A lot of people care. It costs $3500 per server to run Zing Java. Every user of Zing cares enough to pay $3500. Everyone who has written an Android app cares about the distinction too. Dalvik has different quirks than regular Java. (EDIT: Oh boy, that shows how out of date I am. Apparently Android is now using Android Runtime instead of Dalvik....)

> If they need to find another implementation, it's possible, but there's no > question about what the default implementation is.

The implementation can, and does, change without the language changing. That's the unfortunate truth about real world deployments. As such, you need a unique name for the interpreter.

<comment><USER4> >> Sure, but most people don't know or care.

> A lot of people care.

Both of these claims are true, but yours is missing the point.

You grow a userbase by appealing to people who _don 't_ use or understand your product. People who are already invested to the point of spending $3500 for a custom VM aren't the ones you're trying to clarify things for by using consistent branding.

</comment></comment></comment></comment></comment><comment><USER5> _Routinely I see in numerous online discussions that people refuse to even consider Perl 6 because they hate Perl. Or there are younger people who think of Perl as "their grandfather's language" (in much the same way people in my generation view COBOL)._

I am not a fan of Perl, but this feels tragic to me. Perl was so radically different. I remember being on Perlmonks way back in the day, and someone would post a question about why their code didn't work, and there would be dozens of people who could instantly, intuitively post a corrected version of the code, but then the poster would say "oh, shit, what was _my_ code doing? and why does the correct code do something different?" and you'd be lucky if there was a single person ( _cough_ chromatic) who could explain it. And none of the Perl fans cared, because Perl made them extremely powerful and productive, and they could (almost always) confidently produce a line of Perl code that did what they wanted. The analogy to natural language carried further into practice than Larry Wall could have dreamed. Nobody worries that the difficulty of resolving linguistic conundrums impairs their ability to have a conversation, and the Perl ninjas in my company enjoyed a very close and chatty relationship with the systems they worked on.

I'm the opposite kind of person, who got sick to his stomach looking at a line of code like !#$foo->%_[] (note: not real Perl) not knowing why it worked, even if I wrote it and knew that it would work. Even now, I have a nagging fear that if I executed "!#$foo->%_[] (note: not real Perl)" it would print "Yes it is! Ha ha. Love, Larry" to the console. I can't stand that, so Perl was never for me, but I still hope that against all odds this long, drawn-out apparent deathbed scene turns out to be the middle of a successful convalescence.

<comment><USER6> > The analogy to natural language carried further into practice than Larry > Wall could have dreamed.

Over the years I've seen this mantra repeated a million times but I've yet to have anyone actually explain what it means beyond a piece of marketing fluff. What actually is this analogy in concrete terms?

<comment><USER7> A lot of languages — in fact, a lot of software in general — is designed to make things easy for the computer/programmer: "This is how it works and you just have to adapt, deal with it." Larry Wall put a lot of effort into making Perl try to adapt to the way the user already thinks instead, including taking advantage of having studied linguistics to figure out how the "language" part of a computer language fits (or doesn't fit) the way our brains process languages.

The result was a language that has a lot of power and flexibility. People who like Perl tend to love it, because it fits like a tailor-made suit instead of all those off-the-rack languages. People who dislike Perl tend to hate it, because all that power and flexibility can be easily abused (even when you're trying not to — there's a reason so many people buy off the rack instead of making DIY suits).

•[https://bigthink.com/videos/why-perl-is-like-a-human- languag...](https://bigthink.com/videos/why-perl-is-like-a-human-language)

•[https://www.perl.com/pub/1999/03/pm.html/](https://www.perl.com/pub/1999/03/pm.html/)

•[https://www.perl.com/pub/2007/12/06/soto-11.html/](https://www.perl.com/pub/2007/12/06/soto-11.html/)

<comment><USER8> I think there's a greater underlying dichotomy here that's relevant to your tailor-made suit analogy: the people who love Perl tend to be the people who are building and maintaining mostly only their own tooling and (usually small) codebases, and the people who don't love Perl tend to be the ones that are responsible for maintaining large piles of other people's code.

A language that's "tailor-made" for the individual is _fantastic_ when you only have to deal with your own code. You get to write stuff that makes sense to you. It doesn't matter if it's unconventional or doesn't make sense to anyone else -- it fits the way that your brain works.

But when cooperating on larger projects with lots of other people involved, this backfires remarkably. You now need to understand the way that half a dozen or more other brains work.

As software development has gradually shifted away from the published efforts of lone hackers and towards the collaborative efforts of teams of specialized people, Perl's "TMTOWTDI" approach has made it a far more expensive language to develop software in than all of the alternatives.

<comment><USER9> Do you have any data to back up the claim that it's "a far more expensive language to develop software in than all of the alternatives"?

I feel like most scripting languages are pretty similar in terms of productivity based on my own experiences anyway...

<comment><USER8> I was stating a syllogism there: understanding and working with different coding styles is difficult, increased difficulty adds increased expense, and Perl supports many different coding styles.

As far as I know, nobody's done a comprehensive cost analysis of similar software built using different languages, methodologies, or architectures. Certainly nothing recent. I've harped on this before quite loudly and I think it's one of the reasons our industry can't be called "engineering".

People's individual experiences just don't make for good enough data because there are too many confounding variables.

</comment></comment></comment></comment></comment></comment><comment><USER10> Perl 6 is probably a great language, I'm not very interested in it, for the reasons someone might pick it, I'd probably pick a different language; of course not for any logical reasons, but still. Perl 5 on the other hand is still a great language for lots of reasons. I hope Perl 6 is renamed and Perl 5 will become Perl again and it will be reinvigorated and more people will consider it again. Don't get me wrong, I don't use Perl day to day because of the type of work I'm doing at $DAYJOB, but people like to dump on it for all the wrong reasons or outdated reasons, but I still believe in it, and I think a lot of people still do but there just isn't the mindshare and no matter what we think about our industry and how it works, that ultimately means new developers won't use it.

<comment><USER11> > Perl 6 is probably a great language,

Does it also have the unparseability problem[0] of Perl 5? That's a deal breaker for a lot of tooling.

[0] [https://perlmonks.org/?node_id=663393](https://perlmonks.org/?node_id=663393)

<comment><USER12> This specific problem is not a deal breaker in practice. You solve the problem by adding to the readme of the tool "If the arity of a function cannot be established, we assume no arguments and print an warning. Add {foobar} before the function to assume arguments. Sorry for inconvenience."

No language tooling is perfect. We shouldn't expect that from Perl tooling either.

<comment><USER11> > No language tooling is perfect.

Java and C# tools are pretty close. But yeah, it's generally hard for dynamic languages.

</comment></comment></comment></comment><comment><USER13> I'm sorry but Perl 6 isnt relevant IMO. It took too long. I was a Perl developer at etoys.com in 2000 and BBC in 2001. I wrote OneMusic for Radio1 and even convinced the BBCs uptight ops team to run it with modperl so it could handle the high traffic it did. I also created the job search engine WorkZoo in modperl, one of Time Magazines top 50 sites of 2005 and Indeed's main competitor at the time.

Perl6 was promised. Then it never happened. It's now an almost quarter century later. The world has moved on. Taking that long for a single version update in a language is not reasonable. I loved Perl. I still love Perl5. But I've moved on and have 100% blocked Perl6 from my psyche and list of expectations. No one I know uses it. I am not excited by it. I dont need it. And I don't care to hear these discussions about minutia related to it. It's a debacle and a case study in the failure of what was a beautifully ugly practical performant language.

<comment><USER14> If Perl6 is ever performant, I'll be dropping Python for a lot of Scripting uses.

Perl6 is a big language, but has a lot of power and beauty.

<comment><USER15> Yeah too bad it's slow. I write Perl 5 code at work on a daily basis and really wanted to like Perl6. Too late, too slow.

<comment><USER14> Lizormato and some other folks have put in hundreds of performance fixes...I think these things just take time. The language might have been in development and design since the 90's, but it only just got to 1.0 or a "stable release" in 2017 I think. I'm surprised Larry Wall hasn't written a Perl6 book yet. Plenty of other authors have, but I was really looking forward to something from him or Damien Conway.

<comment><USER15> I've installed just about every release since 2017. It's a nice language but still slow and lacking library support. The best thing about it is probably the rational math.

<comment><USER14> Thanks for the information!

Yea... libraries are always good (especially for math and analysis), but I find that powerful languages need far fewer libraries to get things done. APL can do something with a few characters that might commonly be implemented as a lengthy function or library in some languages.

Windows Powershell can surprisingly do a lot of what Perl 6 can do and people mostly understand the limitations. You can automate processes, build your own DSL, have full OO support, full .NET interop, concurrency, you can pipe data around kind of like with FP...etc. It doesn't have some of the more perlish features though.

</comment></comment></comment></comment></comment></comment><comment><USER16> As an outsider who hasn't written perl code in more than a decade this all makes a lot of sense to me.

I think of Perl 5 as something "outdated" because I know that there is a language called Perl 6. When I think of Perl 6 I am not particularly interested in it because I assume it's more or less the same as the "old" Perl, which I don't use and didn't really like back in the day.

Renaming Perl 6 to something else would help with both of these problems.

That said, I wonder how much damage has already been done at this point and whether renaming it now will still be very useful. There are a lot of references to Perl 6 out there already, so convincing people that Perl 5 is the latest version of Perl again will be tough.

<comment><USER17> If Perl 6 is renamed, Perl 5 could skip to Perl 7 in the next version to avoid confusion.

<comment><USER18> Yes for Perl 5->7, but it would be good to have a solid-ish feature change or addition to justify the jump and promote it.

When I see that we still don't have a simple "is item 'in' set" operator, 12 (?) years after the introduction of smartmatch and 5 or 6 years after its half-retraction...

(Well, we still have no sets either :-), let's talk about lists/arrays...)

When I see we still don't have a clean function parameters declaration system (better than the mess with prototypes and signatures)...

When I see that constants, enums, simple structured data (C-like-ish structs) still have to be simulated with functions and/or objects and the weight which comes together...

...On one hand, it gives a set of features that could be used to justify a jump. On the other hand, if these basic features has never been deemed useful by the language leaders until now (that is, during a couple of decades), I have little hope they will change their minds.

<comment><USER19> There is little strain on the "language leaders" (that would be barking up the wrong tree, anyway) as the features you named with one exception are already done and have been available for years.

• "is item 'in' set" operator: [https://metacpan.org/pod/Syntax::Feature::In](https://metacpan.org/pod/Syntax::Feature::In)

• sets: [https://metacpan.org/pod/Set::Object](https://metacpan.org/pod/Set::Object)

• clean function parameters declaration system: [https://metacpan.org/pod/Kavorka::Manual::Signatures](https://metacpan.org/pod/Kavorka::Manual::Signatures)

• constants that are not functions/objects: [https://metacpan.org/pod/Const::Fast](https://metacpan.org/pod/Const::Fast)

• enums that are not functions/objects: ?

• structs that are not functions/objects: pack/unpack, for explanation see [https://metacpan.org/pod/Convert::Binary::C](https://metacpan.org/pod/Convert::Binary::C)

</comment></comment></comment></comment><comment><USER20> > Perl 6 performance has now gotten to the point where it's often comparable > to Perl 5 or surpasses it. It still needs some work in this area, but the > work is clear, the goals are straightforward, and Perl 6 is going to easily > oustrip Perl 5 in terms of performance. If the Perl 6 community wants to > rename, it's perhaps the perfect time to do so. It doesn't look like a bad > choice if performance is a primary concern.

Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that. Plenty of comments are mentioning slow performance. Not having used Perl 6 myself, I can't comment on it, but the fact that this seems to crop up a lot is really worrying. I've heard varying things - regex/grammar are slower than Perl5, startup time is really slow, etc.

And yes - I realize that technically the most popular compiler/VM combination Rakudo+MoarVM hasn't had that full decade of development, and that the spec is "in theory" performant. None of that matters to developers who just want to use the language...

If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done. Otherwise, the empty promises will continue to hurt adoption.

<comment><USER21> > Perl6 has been under development for over a decade at this point, and this > equivocating statement is the best that can be said about performance? If > the "work is clear, the goals are straightforward" and Perl 6 should easily > outstrip Perl 5 on performance, then by gosh they should demonstrate that.

As the other of the post in question, I refer you to this presentation: [https://www.youtube.com/watch?v=QNeu0wK92NE](https://www.youtube.com/watch?v=QNeu0wK92NE)

It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue.

> If performance is a major blocker to adoption and it's as straightforward to > fix as suggested - it should get done.

(Disclaimer: I'm not the one doing the work mentioned below)

It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far.

The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place.

We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: [https://jnthn.net/papers/2019-gpw-ea.pdf](https://jnthn.net/papers/2019-gpw- ea.pdf)

In short, there's a ton of stuff to do and it's being done.

<comment><USER21> "author of the post in question"

God, what a horrible typo :)

</comment></comment></comment><comment><USER22> This makes a lot of sense. Renaming Perl 6 means:

* Perl 5 can continue being "perl" and have a future. People with existing perl codebases won't think they're going to need to upgrade.

* Camilia/Raku/etc can be considered on its own merits.

The C/C++ analogy is a good one: when things are different enough you stop expecting everyone to "upgrade" and instead are making a different language.

<comment><USER23> I don't see any future for Perl5. Through a type of Osborne Effect - [https://en.wikipedia.org/wiki/Osborne_effect](https://en.wikipedia.org/wiki/Osborne_effect) \- the development of Perl 6 has also killed Perl 5. Few or none will reach for Perl5 these days for new development - Python or Node.js have obliterated Perl as contender in the space it used to dominate and I don't see Perl5 ever muscling it's way back. Fairly or unfairly, Perl5 is viewed as a legacy tool these days.

</comment></comment><comment><USER24> Raku is a good name (can be abbreviated to 楽 as a bonus). Camelia is too long and is already the name of the mascot. Ofun is terrible (nothing like a product implying it's "fun" by literally including "fun" in the name).

<comment><USER25> Especially when it can readily be pronounced "Zero Fun"

<comment><USER26> Just like how people readily pronounce your user name "Tzerom Lzerong"?

<comment><USER25> Exactly

</comment></comment></comment></comment><comment><USER27> I learned Perl4 in grad school and it was a life changing tool to automate my analysis workflow. With it I was able to script complex solutions that drove stepper drivers and CCD cameras on a microscope for data and image collection.

I stayed through the Perl5 change over and thought it was good. Then I tried OO programming. And cried. And read that Perl 6 would make it better. But I needed something now, on a windows box, and free. That was 2003.

I tried Python and loved it.

Higher Order Perl made me appreciate what Perl could do, but the state of Perl 6 and lack of progress kept me away, as the features I most wanted were always fixes coming real soon now.

I STILL program python. Perl had me and lost me. Perl might not be dead, but it is dead to me.

<comment><USER28> What I got from mingling with the Perl community: The single most repeated advice (indeed Larry Wall himself has said it repeatedly), is that one should use whatever tool will allow one to carry out the task at hand and generally get things done.

In that sense, Perl never had you because Perl probably isn't interested in "having" anyone. Maybe helping out people carry out their work, but not having them. It is about getting things done, without trying to be the next big thing in CS. At least that's what I'd like to believe.

If Python helps you carry out your work better, you should most assuredly and definitely use Python. Ditto with PHP, Go, and all the rest. And Perl.

</comment></comment><comment><USER29> Serious question: what does Perl 6 bring to the table? What advantage does it provide over Perl 5, Python 2/3 or Ruby?

I could google this (which I will), but give me the HN summary. What do you think is a good reason to use Perl 6?

<comment><USER30> Off the top of my head: Concurrency and parallelism using high level and low level APIs. There is no GIL.

Grammars which are like regular expressions on steroids for parsing. ( admittedly still not optimized for speed)

Gradual typing, you can go from no types at all for short one liners, to using built in types, to defining your own complex types for big programs.

      subset Positive of Int where { $^number > 0; } #create a new type called Positive
      multi factorial(1) { 1 } #multi subroutines that dispatch on type
      multi factorial(Positive \n) { n * factorial(n-1) }

      #say factorial(0); #Error type mismatch
      #say factorial(5.5); #Error type mismatch
      say factorial(5); #120

      hyper for (1 .. 1000) -> $n { #use hyper indicate for loop can be run in parallel on all available CPUs
        say "Factorial of $n is { factorial($n) }"; #Gives correct results by automatically upgrading to big int when needed
      }

</comment></comment><comment><USER31> I don't get all this "Perl 6 is a different language" nonsense. It was created by Larry Wall and retains all the characteristics of Perl 5 whilst adding a lot of great stuff from other languages. Sadly, performance prevents it being taken seriously in production.

<comment><USER32> It's a different language because you can't run Perl5 programs unmodified in Perl6. The same is also true of Python2/Python3, which is why that transition has also taken so long. The difference is they managed to do it without everyone abandoning Python2 for something else.

<comment><USER33> It's pretty easy to upgrade most code from python 2 to 3 and a lot of code just runs as is. The reason the upgrade path was so slow, imo, is that even a reasonably small amount of work is still work, and for a lot of people, the benefits didn't justify spending any time at all rewriting software that already worked.

<comment><USER34> After the initial round of "useful PyPI packages don't support Python 3 though, I can't migrate", that "I know 3.x is different and I'll have to read up on the differences....later" was absolutely the biggest blocker for adoption imo.

I know proficient Python programmers who were starting projects from scratch in 2017 and didn't want to use Python 3.x because they were in a hurry, worried that they didn't know how to write Python 3.x in a timely manner because they hadn't invested the time to learn it. Lots and lots of people just knew it was a known unknown for them, had no idea of the magnitude of the effort required to switch (tiny for new projects! tiiiny) and just put "look into this" somewhere deep on their backlog.

</comment></comment></comment></comment><comment><USER35> I think this is a great idea that is two decades too late. Many people say that python killed perl, and that is true for those who disliked perl. However, I think perl 6 killed perl for those who liked it, or could have liked it if they learned it. The knowledge that there was a new version on the way that would have all power of perl, but fixed many of its problems took the wind out of perl's sail, especially once it became clear how different it was going to be. Why invest time into learning perl 5, when perl 6 was just around the corner? How do I defend my use of perl 5 in production, when its own creators have moved on? Best to just concede the battle, and regroup for the war when perl 6 is ready ... and then it never was.

I really think that both languages would be stronger today if Larry Wall et. al. had "marketed" perl 6 as a research sandbox for new ideas for language design, and then depending on where those ideas led them, pronounced it as either a successor to perl, or a new language when it was closer to ready.

</comment><comment><USER36> I suggest "Perl Nukem Forever"

<comment><USER37> Perhaps something onomatopoeic like "$#_@;\>&%}`[*~!^)"

<comment><USER38> As a non-perl programmer, the mnemonic descriptions in the perlvar manpage crack me up. They probably are useful and make sense to perl programmers, but from the outside, they look like parody.

<comment><USER39> I don't think you should place too much emphasis/concern/whatever on most of the special variables available in Perl 5. I would wager that most Perl programmers never use about 95% of them (that is, the short 2-3 character ones listed on that man page).

At the very least, I would guess, most Perl programmers _almost_ never use 95% of them -- and many would choose (as the perlvar man page says) to 'use English;' \-- and thus use the readable version. An example would be using $LIST_SEPARATOR instead of $" (which is what I would do).

I write Perl 5 code frequently, and that man page is chock full of short variable names I never use.

<comment><USER37> Yet you have to know both versions of them all, and be able to recognize and understand both kinds when reading other people's code.

How does it improve the language to be so top-heavy and chock-full of obscure unreadable arbitrary syntax, 95% of which nobody every uses, but that everyone still needs to memorize and understand in order to read?

That's exactly why Perl's philosophy of TMTOWTDI is intellectually bankrupt, and encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare.

The language isn't any better for having $" as a shortcut for $LIST_SEPARATOR (or $LIST_SEPARATOR as a mnemonic for $", depending on how you look at it), because now you have to learn twice as many things, and all that duplicated effort and mental stress and syntactic surface area doesn't make it any more powerful or easy to use, has absolutely no tangible benefits, only pointless costs, and makes it twice as hard to learn and read and maintain Perl code.

<comment><USER40> > Yet you have to know both versions of them all, and be able to recognize and > understand both kinds when reading other people's code.

You have to be able to understand that if it's a two character variable of all punctuation you may need to look it up to figure out what it is. Typing `!perldoc $"` into duck duck go sent me to [https://perldoc.pl/variables/$%22](https://perldoc.pl/variables/$%22) ... which is roughly equivalent to `!g [docker error]` which I already do all day long.

<comment><USER41>
        $ perldoc '$'
        No documentation found for "$"

I hope perldoc search improved on Perl6, because it only used to match section titles, and none of the line noise vars are there.

(Yes, after a while one should learn yo search for the section that explains all the vars, at least if he's coding Perl all day. But it's a ton of useless trivia to keep in mind anyway.)

<comment><USER42> The correct invocation to search for a variable named $" (not $) is perldoc -v '$"', which the variable search on perldoc.pl was modeled after.

A glance at "man perldoc" (or "perldoc perldoc") will tell you of the very useful other switches, such as -f and -q.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Perl 6 was a huge mistake; it's a different language and should have never had the same name. I support renaming it so we can all forget about it and have Perl 7 be a direct, mostly backwards compatible descendant of Perl 5 with feature enhancements. This whole Perl 6 nonsense was the reason I jumped to Python many years ago.

<comment><USER44> I don't think the language was a mistake, but it looks like the naming was.

</comment></comment><comment><USER45> I think this is a good idea, but there's a decent chance that some people will mishear the change as "Perl 6 is cancelled, Perl is dead".

To be honest, I'm not sure anything can change the decline of Perl. There will continue to be Perl projects and Perl shops for a long time, just as there are COBOL projects, and COBOL shops. There will even be some new projects. But many projects will die, some companies will go out of business or migrate, and the ecosystem will continue to ossify.

</comment><comment><USER46> As a German, I don't like the name "Camelia" very much because it is associated with hygiene products here (brand name).

"Raku" sounds nicer for me.

<comment><USER44> Anecdotally, "Meijer" is one of my favorite retail chains in the US.

</comment></comment><comment><USER47> I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. And this was done without any hint as to whether the module actually worked with the latest versions of those modules. So, you'd end up upgrading a bunch of modules, very likely breaking things that worked. And at the end, it'd "upgrade" the perl interpreter. And by "upgrade" I mean install a new copy, replace all OS references to the new version, but not include any of those modules you just installed. So you had to re-install everything again.

Perl's main use at the time was developing CGI scripts. It had big disadvantages over things like PHP and Netscape Commerce at the time, but people still seemed to like Perl. As complex web side code grew more complex, requiring a lot of 3rd party components to get Perl to do anything, people seemed to abandoned it pretty quickly.

I still use Perl today, version 5. Mostly just to process text files, but I still don't use any 3rd party libs.

<comment><USER48> > But installing one was the big issue, as it would always choose the latest > release of any module in the dependency chain, including the perl > interpreter itself.

You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaration on a module that is shipped with core and is not upgradable separately, e.g. 'strict' or 'POSIX').

<comment><USER49> This is true now, but was not true many years ago.

<comment><USER42> To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in 2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on older Perls).

</comment></comment></comment></comment><comment><USER50> Maybe Perl 5 should be renamed to Perl 7...

<comment><USER29> You say this as a joke, but that might actually be a good idea.

<comment><USER37> Then what's the next version of Perl 6 supposed to be, Perl 8? And the next version of Perl 7 will be Perl 9... From then on their version numbers will leapfrog each other to keep Even Perl and Odd Perl in parity.

<comment><USER51> > Then what's the next version of Perl 6 supposed to be

raku 2? Perl 5 gets the Perl name back and gets a version number leap to show it's not dead yet and raku is off doing its own thing with its own version numbers, probably hitting 1.0 barely before GNU Hurd.

<comment><USER37> Rakuier

PINP: PINP Is Not Perl

</comment></comment></comment></comment></comment><comment><USER52> perl5 needed a single switch to make it loosey-goosey anything goes otherwise have use strict and -w by default.

That one decision cost the language so very much. I miss Perl. Python is what was pushed on me by employers and it's fine, it's perfectly acceptable. As is ruby and many others but I just miss Perl.

I hope the Perl6/Raku folks get things happening in their tech and perception of it the way they might like. I think they deserve a break.

</comment><comment><USER53> I think the name Camelia or Raku is fine, no need to argue over it forever. During this renaissance period of computer languages in history, it will be nice to get this out and iterate. Given there are plethora of choices today like go, rust, Nim, elm, elixir, Scala, julia, crystal, F#, D etc. trying for developer mindshare which is a limited resource speed is of essence.

Indeed with parrot VM besides perl 6 developers can be truly polyglot with same toolchain. So move forward, it's still a great addition. I feel parrot is truly open source, better than Graal no Oracle involvement.

<comment><USER54> parrot (as a multi language vm) has been dead for a long time, the GraalVM is probably the current best bet for a polyglot platform.

<comment><USER53> Yeah that's sad Perl 6 moved to moarvm[1]. I guess necessary evil to have performance which they can't get out of parrot.

Hopefully someone pick up Moar with Rakudo and make it multi-lingual. Given Oracle involvement in GraalVM, it will always be a risk for open source development.

[1] [http://www.moarvm.org/](http://www.moarvm.org/)

</comment></comment></comment><comment><USER55> Perl 6 should definitely be renamed so that Perl 5 can just be Perl.

An easy way to see this is to simply look at the mascot for each language.

Perl_5 => Humphrey the Camel (See [https://www.perl.org/](https://www.perl.org/)) (I am not sure if the camel actually has a name, so Humphrey seems like a good name for a camel mascot.)

Perl_6 => Camelia the Butterfly (See [https://perl6.org/](https://perl6.org/))

They are very different and the languages are too, so why should the languages both be called "Perl X" ?

</comment><comment><USER56> I wish Perl 5 was being renamed. As a language, it's annoying, but as a tool, it's possibly the best programmable tool ever made.

</comment><comment><USER57> Jeremy Howard (co-founder of Fastmail (Perl used for everything), co-founder of fast.ai, etc.) in his Lex Firdman interview this week, made some interesting comments on Perl and Larry Wall no longer taking enough interest in the language. I don't use Perl, but the comments were interesting anyway.

<comment><USER58> Link: [https://lexfridman.com/jeremy-howard/](https://lexfridman.com/jeremy- howard/) to the podcast episode that I guess you're referring to. Thanks for mentioning it, will check it out.

</comment></comment><comment><USER59> I rarely see Perl in the wild today. Only companies that are too big too fail and too cheap to move on still clings on to Perl, the big "index" sites of the late 90'ies that somehow haven't been completely run into the ground by silicon valley giants like monster, facebook, linkedin etc.

</comment><comment><USER60> They renamed Perl 6 to "Raku" last year!! Am I losing my mind? This is a done deal! [https://marketing.perl6.org/id/1541379592/pdf_digital](https://marketing.perl6.org/id/1541379592/pdf_digital)

<comment><USER42> That announced that it could be used as a second name, but provided no further guidance, so Perl 6 is still used by many thus its problems are still just as present. This proposal would be to actually consistently use Raku as the name of the language.

<comment><USER60> Wouldn't it have made more sense to hold off on the first announcement until there was consensus on a single new name, instead of having two or three inconsistent namesoperating simultaneously for a year? Neither of which might be the final one?

<comment><USER42> A lot of things would have made more sense in hindsight, but it's not where the community was at the time, and ultimately Larry said no to a straight rename. He is taking less of a role now so it can be revisited.

</comment></comment></comment></comment><comment><USER61> I think an interesting question is, if the developers of Perl 6 knew from the beginning that they are essentially designing a new language with a new identity, would their new language be different and to what extent?

<comment><USER62> Developers now want to grab old folks by using old name and new ones by using new name. Politically they can do that because there is a Perl 5 faction existing because of the big differences between 5 and 6.

</comment></comment><comment><USER63> This is a bit like people arguing over the what noise should be made when the "tree falls in the woods and no one hears it".

</comment><comment><USER64> I want to write some scripts that are _slightly_ too complicated for bash. Basically just implementing some simple scripts that have a couple options/args and I want to use another tool.

How good would perl 5/6 be for this?

If not perl, anything similar that's not python? I want to learn something new.

<comment><USER65> As I said elsewhere in this thread, check out my article for the 2018 Perl6 Advent Calendar.

[https://perl6advent.wordpress.com/2018/12/16/day-17-checking...](https://perl6advent.wordpress.com/2018/12/16/day-17-checking- your-list-twice/)

I walk through the development of a utility for auditing Santa's Naughty and Nice lists. Along the way, I introduce literate programming, multiple dispatch, types, type subsets, links to documentation, perl6 collections, and File IO. And, I've been told I managed to do all this without making the reader they've been dragged over rough ground behind a certain festive sleigh.

The key thing to remember when you start learning a Larry Wall Language is that you only need to worry about the parts you need to worry about. It's more like learning a natural language than a programming language. Learn how to say the things that are important to you, and it will serve you well even if you speak with an accent.

</comment></comment><comment><USER66> "Perl 6 is a sister language, part of the Perl family, not intended as a replacement for Perl 5, but as its own thing - libraries exist to allow you to call Perl 5 code from Perl 6 programs and vice versa."

Umm.

<comment><USER65> You can also call Python from both languages. It doesn't mean they are the same.

[https://metacpan.org/pod/distribution/Inline- Python/Python.p...](https://metacpan.org/pod/distribution/Inline- Python/Python.pod)

[https://github.com/niner/Inline-Python](https://github.com/niner/Inline- Python)

</comment></comment><comment><USER67> I love open source drama

</comment><comment><USER68> > _s /Perl/$other_language/g_

I'm somehow not sure Perl6 has anything to do with that.

> _because they 're tired of waiting for Perl 6_

But…for what exactly? It's already stable enough for use.

<comment><USER69> Reasonable performance

<comment><USER68> It is.

Ref: [https://www.youtube.com/watch?v=S5iVBlk7pdg&t=279m33s](https://www.youtube.com/watch?v=S5iVBlk7pdg&t=279m33s) "Perl 6 Performance Update"

<comment><USER69> Do perl5 vs perl6 benchmarks exist somewhere? Google produced nothing recent/relevant.

</comment></comment></comment></comment><comment><USER70> Although the "Perl" name in "Perl 6" is basically wrong and misleading, it's also the only reason Perl 6 is a blip on anyone's radar.

</comment><comment><USER71> Until Perl6 is actually released, it doesn't really matter what they call it.

(yes, I know they have functional snapshot builds, but as long as there's not a final "6.0" (or "1.0") release, expect most devs to steer clear of it. Few people (masochists, mostly) want to use an 'experimental' programming language for important work).

<comment><USER72> > Until Perl6 is actually released, it doesn't really matter what they call > it.

> (yes, I know they have functional snapshot builds, but as long as there's > not a final "6.0" (or "1.0") release, expect most devs to steer clear of it. > Few people (masochists, mostly) want to use an 'experimental' programming > language for important work).

The "1.0" for the Perl 6 spec (6.c, because reasons) was released in 2015; the stable implementation in Rakudo was a little later but years ago. Current Rakudo has a stable, production-ready implementation of last year's 6.d version of the language spec. So we're _well_ past the threshold you suggest.

<comment><USER7> Then it should have been called "1.0". Calling it "DEFINITELY NOT 1.0" while deciding that that is secret P6 code for "really means 1.0" is awfully bad marketing.

(More seriously, slow performance, missing features, bugs, etc. were part of the reason for not calling it "1.0", but I would agree that to be really successful, the language needs a release that is called 1.0 and acts like it.)

<comment><USER72> > Then it should have been called "1.0".

6.c was described, both before and after its release, as being the "1.0" release of the Perl 6 language.

> More seriously, slow performance, missing features, bugs, etc. were part of > the reason for not calling it "1.0"

No, they weren't.

The first "production-ready" release of Rakudo Star release was shortly after the 6.c spec release, in version 2016.01 (Rakudo Star uses date-based versions numbers.) If they were using semver-ish numbering for Star releases rather than dates, this would have been the 1.0 implementation (as opposed to spec) release.

</comment></comment></comment></comment><comment><USER73> I've got to agree Raku is way better than Cameila.

Although I understand why the female developer couple would want a female name. It just doesn't sound like a programming language and shorter the better (nothing beats Ruby).

<comment><USER44> Camelia is the name of the butterfly mascot, hence the suggestion to use it as the name of the language.

rakudo, the language tool, basically translates as "way of the camel" playing on the use of the camel as Perl's O'Reilly book mascot. "Raku" or "raku", would basically be calling the language "camel" and the tool "way of the camel" which has a certain appeal as well. However, the camel has never been really directly associated specifically with the new language except in the names rakudo and raku.

So as I see it, there are good arguments for either side of this. Knowing Liz and Wendy I doubt their suggestion has much more to do with being girly than my feelings on the matter. I think it has more to do with making the clean break really, really clean.

Unfortunately all this furor within the community and even from without has nearly convinced both ladies to leave the community they've been pillars of for two and a half decades. They've suffered personal attacks over this and their participation in anything Perl related is likely to be curtailed if not ended. It's a sad, sad day because Wendy's one of my favorite people at the conferences.

<comment><USER73> Oh apologies I made an assumption there I probably shouldn't have.

To me naming is was mostly how it rolls off the tounge so I'm not a fan of multi syllable words that aren't super common.

I'm also not a fan of 'clever' words that have dual meaning, like tattoos it should mostly be an aesthetic thing.

But I'm not surprised when I hear communities responding to change poorly. Any large community has this problem and it's best to ignore the rancour. Not everyone should have an opinion and there's nothing that attracts more than a name. So it will come down to personal taste.

I'd 100% defer to the primary devs on this one.

</comment></comment></comment><comment><USER74> What did Perl do better than others when it came out?

<comment><USER41> It was shell scripting with reasonable arithmetic and an incredibly good support for text consumption and regular expressions. Everything you'd miss on a normal shell.

But it scales only slightly better than sh into large programs.

<comment><USER74> I see.

Would you consider Bash on-par with Perl?

<comment><USER41> No, I wouldn't. Perl 5 is much more powerful.

But I wouldn't choose either for a moderately large script.

<comment><USER74> Ah okay.

But back in the days? Bash seems to be released a year or so after Perl.

<comment><USER41> Bash is a much better shell, mostly because you don't have to quote shell commands. Perl 5 is a much better scripting language.

If it was not for Python and Ruby, Perl would still be the language to go for scripts. But I don't think anybody ever used it interactively.

</comment></comment></comment></comment></comment></comment><comment><USER75> Raku, Camelia and Rakudo are stupid names.

Perl++ is a good name. C and C++ are different enough and live alongside each other.

<comment><USER76> but this brings up C++, if in name only, which wouldn't always win you fans..

<comment><USER75> The cool part about old 90s Perl5 was ... it was doing its own thing. The best part about everyone hating you ... gives you the freedom to do precisely that.

I don't like the proposed names because they seem to imply a new language. You need Perl in the goddamn name.

I honestly think the biggest mistake that Perl5 made was going the OOP garbage way, which complicated the language as it was implemented as a hack. And everyone just said ... look Perl, ha ha ... can't do OOP!

OOP in all its forms is a mistake. Small talk OOP, CLOS, Java OOP .... sheesh it's just a hash with sub refs. C gives you function pointers and structs. OOP should have been limited to just fucking that.

Encapsulation is a mistake. Inheritance is a mistake. Polymorphism is useless in a dynamic language.

</comment></comment></comment><comment> vincent-toups If I ever wanted to program in Perl, I'd program in J.

</comment><comment><USER77> I haven't worked with Perl in 20 years, but obviously totes:

Perl++

amirite?

 _joking_

</comment><comment><USER78> Rebrand.

</comment><comment><USER79> Suggestion for rename: Pearl 1

</comment><comment><USER80> I'm not surprised that the language is dying. They seem to be spending time on things no one cares about and things that are inconsequential.

<comment><USER81> This is by far the most important thing they could be doing right now. It should have been done 10-15 years ago, and is arguably the dominant remaining reason for why the work done on both Perls since Perl 6 has failed to payoff the way it should have.

There is a certain contingent of developers who _should_ have been all over Perl 6 and very excited about it. We should have been seeing the stream of "$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but with this bit here and there look at how slick the Perl 6 solution is!" every couple of weeks. We should be seeing blog posts about the joys of working in a language with built-in grammar support replacing the old ad-hoc regex support, and how well it integrates with the rest of the features. We should have even eventually seen the contrarian backlash posts about how much of a mess you can make if you overload all your operators and grammar constructs and use all the features at once in an ill-advised manner, followed by comment thread semi- flamewars about whether bad code is the fault of the programmer or the language.

But we didn't.

Bias disclosure: I actually have no interest in Perl 6, so this isn't advocacy. Anything I've ever seen that Perl 6 looks interesting _to me_ (emphasis) for, I'd rather just use Haskell, which I've already learned and actually does quite a lot of what Perl 6 does. But Perl 6 does it without being a immutable functional programming language, making this all a lot more accessible to a lot of programmers. I'm not saying _I 'm_ interested in Perl 6; I'm saying, there is definitely a chunk of programmers who _should have been_ interested in it who are not.

And from what I can see, this naming confusion is one of the major reasons.

(One other one I would point to is the Perl 6 community's multi-year "joke" that Perl 6 would be released "next Christmas", which nobody outside of the Perl 6 community found even slightly funny, instead creating a reputation for the community that overpromises and underdelivers; that a few people would swoop in to those conversations to actually mock people who weren't insiders enough to know it was a joke and not a real promise, which is to say, 99.9999999% of humanity (that is not random nines; that is all but ~700 people; take one off if you like), really didn't help. I put "remaining reason" in my first paragraph because this has been resolved for many years now. But I can tell you that this significantly diminished my own personal interest, and I'm sure I'm not alone.

Finally, I'd point to it just never being done, but, arguably, that alone couldn't have killed it. There's plenty of languages that grow quite substantially over time; the Python of when Python first really got popular and the Python of today are _very_ different, for instance. Had more people been interested and pushing for something usable $TODAY, with more work being done later, this probably wouldn't have been as big a deal.)

<comment><USER37> I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.)

[https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...](https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)

[http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt](http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt)

While I believe Python's continuing success is evidence supporting the truth of its Zen of Python philosophy: "There should be one — and preferably only one — obvious way to do it."

[https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)

<comment><USER81> So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.

<comment><USER7> You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.

</comment></comment></comment></comment></comment><comment><USER82> I haven't looked at Perl in years, having long ago switched to Python/SciPy, but now I see that Perl 6 doesn't have GIL, something that Python has been unable to shed. So now a language that nobody cares about anymore solves the #1 problem that I have with Python. We are truly blessed to have so many shitty implementations of dumb programming languages to choose from these days!

<comment><USER42> I am a Perl user not Raku, and Perl had almost the opposite problem where its threads _are_ concurrent but too badly designed to be useful. But from what I have seen, Raku is second to none in this capability.

<comment><USER82> Being able to do a multi-threaded map() would be divine. In Python, you're creating/destroying a new process and using IPC to seed the state info and return the results for each element in the iterable arg. If the function in question runs quickly, it ends up being faster to do it single threaded.

<comment><USER42> It's not going to be efficiently threaded like in Raku, but this is also possible in Perl 5 with a few modules from CPAN. [https://metacpan.org/pod/IO::Async::Function](https://metacpan.org/pod/IO::Async::Function) will maintain a preforked pool of processes (on Unix) or threads (on Windows), and return Futures, which can be used by fmap_concat from [https://metacpan.org/pod/Future::Utils](https://metacpan.org/pod/Future::Utils) to make a very map-looking iteration. The experimental [https://metacpan.org/pod/Future::AsyncAwait](https://metacpan.org/pod/Future::AsyncAwait) will make this even more natural in the future.

<comment><USER82> I'm continually astounded that threading involves jumping through so many hoops in 2019. If you want a language that provides a REPL and easy threading, your choices are few and far between.

</comment></comment></comment></comment></comment><comment><USER83> whorl

EDIT: no, I'm serious and that's a cool (enough) and available name with the right amount of historical correlation

EDIT 2: plus it already has an emoji icon on most platforms: [https://emojipedia.org/fish-cake-with-swirl- design/](https://emojipedia.org/fish-cake-with-swirl-design/)</comment>


Cloud Code – A new set of plug-ins for IntelliJ and VS Code - <AUTHOR> https://cloud.google.com/blog/products/devops-sre/announcing-cloud-code-accelerating-cloud-native-application-development <comment><USER2> I believe this was said when the Github repository[1] was posted yesterday, but... It's pretty wild that Google's releasing a closed-source plugin for Microsoft's open-source code editor in 2019.

1\. [https://github.com/GoogleCloudPlatform/cloud-code- vscode](https://github.com/GoogleCloudPlatform/cloud-code-vscode)

<comment><USER3> Pretty weird decision overall, considering you can always download the extension package and look at the code in there.

<comment><USER4> Being able to see the source is not the same as open source. Being able to see the source doesn't mean you can fork it, resell it, or even use it without permission.

Plenty of proprietary products are made in languages where the code is not compiled, such as proprietary PHP platforms.

Presumably, since the plugins are free here, if Google isn't open sourcing it, they don't want other companies to lift their work and use them in competing projects. Or, just as likely, the Googler that wrote it has some bureaucratic process they didn't go through yet to open source it, and they intend to change the license later.

<comment><USER5> I'm not too familiar with open source licenses, but does a license exist that allows someone to (enforceably) open source their code with the stipulation that it is for academic/security purposes, but forbids forking/reselling/other usage?

<comment><USER6> Sure there are such licenses, but they aren't Open Source. By definition they are proprietary.

<comment><USER7> That depends on what you mean.

Sometimes "open source" means "you can see the source code".

Sometimes "open source" means "meets the requirements for software licenses under the Open Software Initiative's definitions."

Similarly, sometimes "free software" means "provided at no monetary expense" and sometimes it means "meets the requirements for software licenses under the Free Software Foundation's definitions."

People really, really like to pretend that "free software" and "open source" are extremely simple concepts and synonymous terms. They're not. People like to pretend they're controlled terms and that the plain English meaning isn't valid. That's absurd. Neither one is particularly easy to understand because both are much more deeply nuanced than you see at first glance, and one look at free and open software licensing comparisons [1] will tell you that there is obviously significant complexity going on.

[1]: [https://en.wikipedia.org/wiki/Comparison_of_free_and_open- so...](https://en.wikipedia.org/wiki/Comparison_of_free_and_open- source_software_licenses)

<comment><USER8> This was settled many years ago by coming up with an official definition of "open source" [1] that was then popularized. It's a well-known industry standard. While nobody can prevent you from using the term incorrectly, you're going to get a lot of pushback if you do due to the confusion it causes.

There are a lot of other possible licenses and just because they don't meet the open source definition doesn't mean they are bad. I disagree with the people who say the opposite of "open source" is proprietary.

[1] [https://opensource.org/osd-annotated](https://opensource.org/osd- annotated)

<comment><USER7> That's not really what I'm trying to argue. What I'm trying to argue that you can have OSI open software that is not FSF free software and you can have FSF free software that is not OSI open software, and _either of those types of software are labelled as proprietary by the parties that exclude them_. My point is that just because something doesn't meet the OSI open source defintion doesn't mean it's proprietary.

However, if I do consider your argument, it's not very good. The argument would be that the Open Source Initiative is not the authority for the plain English meaning of terms. If the argument I'm making is that OSI's definition is not authoritative, you can't cite the OSI's definition as an authoritative counter argument. You're begging the question. Yes, people are going to assume "open source" means "OSI open software," but that doesn't meant that everybody is always using it to mean that.

<comment><USER4> Both FSF and OSI fundamentally recognize each other as "not proprietary", even if they have different goals and different preferences on how FOSS ("free/open source software") is licensed.

And the OSI is not the authority for the meaning of English terms, correct. But the developers who use those terms are (much as language is determined by how people use it), and by and large, most everyone understands and agrees that open source software is software that meets the qualifications set by the OSI.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I wish they would at least open-soure the linter. I just quickly compared it to [https://github.com/garethr/kubeval](https://github.com/garethr/kubeval), and it did uncover some valid additional mistakes.

Upd: looks like the plugin is using [https://github.com/mulesoft-labs/yaml- ast-parser](https://github.com/mulesoft-labs/yaml-ast-parser) combined with [https://github.com/Microsoft/vscode-json- languageservice](https://github.com/Microsoft/vscode-json-languageservice)

<comment><USER10> It'd be indeed nice if this was open source. Having a server yourself somewhere using a VPN that you could run some stuff on while working on a slow laptop would be nice.

</comment></comment><comment><USER11> *Google Cloud Code

The Kubernetes bit seems (somewhat) agnostic but it looks like a big part of this is adding integration for GCP APIs.

Which is all fine. Just wish it was branded a bit more specifically.

<comment><USER12> It's annoying that pretty much every single Google project comes with an underlying attempt at vendor lock-in.

<comment><USER13> GCP is arguably doing the most among major cloud providers to prevent vendor lock-in and support multicloud implementations.

It's really their best play to try to get some business when they're so far behind AWS and Azure in market share.

<comment><USER14> Hope they'll allow the same for this tool since it sounds pretty useful.

</comment></comment></comment></comment><comment><USER15> Are people still moving to Docker or is Kubernetes where things are going?

<comment><USER16> Personally I don't really differentiate to much between the two. Customers often don't know the difference, and assume that Docker will magically scale when needed. And if you have a Kubernetes installation available, why not just run all your Docker images there.

Unless you're just using Docker for the encapsulation you'll need something like Kubernetes pretty quickly.

<comment><USER17> _Personally I don 't really differentiate to much between the two._

I differentiate between is so much that as the app developer, Docker is my concern, Kubernetes is the concern of Infra/DevOps.

<comment><USER16> That's actually a pretty good way of looking at it. As an ops guy I don't really care that much about what the developers put into their containers, or at least I can shift a large part of my work with maintenance and patch management to the developers.

</comment></comment></comment></comment><comment><USER18> As someone who uses App Engine, it'd be nice if Google would stop treating their non-java languages as second class citizens. It seems, as per usual, there is only App Engine Java support...

<comment><USER19> I think their new 'cloud run' product is supposed to be a step towards addressing that (and vendor lock-in).

</comment></comment><comment><USER20> Where's the Vim support? According to the most recent SO survey Vim is being used by 43% of the DevOps/SRE market, which corroborates with my experience in DevOps. DevOps is a CLI heavy job, and having an editor that can run in a terminal emulator and has maximum integration is a must.

</comment><comment><USER21> My which-list for G cloud: 1) Enable Websockets for the G cloud shell proxy 2) Break up and untangle the JavaScript client monolith library into small modules that can be self hosted. One module for each G cloud service. Try to limit the complexity while you're at it. 3) Make an API to make it possible to automatically manage G cloud services. For example execute commands on the G cloud shell on behalf of the user. 4) Expand the free tier so people that want to learn can try out _all_ services without a credit card. 5) (bonus) Add a partner program so that channels can get a kickback for each user they bring to the G cloud services.</comment>


Ask HN: What is a good client mgmt tool for IT Consultants? - <AUTHOR>

Hi, my friend and I provide IT consulting (sys admin stuff) and we are looking for a web-app that we enter hours, client documentation, notes on each visit (which could be emailed to clients). If the system could do billing, that would be great! Thanks. <comment><USER2> Corduroy is used by IT consultants, among others. We're very receptive to feature requests and new ideas from our customers on how to make it fit their business better. Give it a try: <http://corduroysite.com/>

(Disclaimer: I'm the author)

<comment><AUTHOR> Hey thx - I'll check it out.</comment></comment>


MCAS: How 737 MAX system gained power and lost safeguards - <AUTHOR> https://www.seattletimes.com/seattle-news/times-watchdog/the-inside-story-of-mcas-how-boeings-737-max-system-gained-power-and-lost-safeguards/ <comment><USER2> The thinking of "we don't want the system to not work if it's needed" thinking demonstrates a failure to understand the prior probabilities involved.

Most of the time the flight conditions will not warrant activation of the MCAS, and apparently the system is sufficiently unreliable/easy to damage that the chances of the system inadvertently triggering is high. But Boeing wanted to be sure that MCAS would always activate if needed, even if that resulted in unintended activations normally.

Boeing essentially optimized around a low probability of a false negative, while ignoring the high probability of a false positive, because they underestimated the consequences and confusion that would result from a false positive - in many cases, multiple alarms/system failures occurring simultaneously as other systems that rely on that sensor begin alarming as well. In that environment, designing around a 3 second response time (on a system that _pilots weren 't trained to know exists_) is probably unreasonable.

<comment><USER3> If it were designed correctly, it shouldn't matter if it were activated or not - it would always be safe. If it were designed correctly there would be at least 3 AoA sensors and the loss or disagreement of one would not affect the functioning of the system other than displaying a warning message to the pilots. If the two remaining disagreed then the system would be disabled.

This is assuming that the system is necessary for certification or safety, if it is not necessary for certification or safety then it shouldn't be there at all.

The fact that Boeing put a secondary autopilot in there with a single point of failure, can only be explained by organisational failures reminiscent of the Challenger disaster.

<comment><USER4> If the MAX was designed correctly then MCAS would not be needed in the first place.

Fixing MCAS is fixing the wrong problem.

<comment><USER3> I agree ideally it would not be needed at all, however I believe that if Boeing decided that a new airframe would be too costly then they could have designed MCAS to be safe, by including a greater degree of hardware redundancy and an appropriately thorough development and testing process.

It seems that they did neither of these things, and still haven't learned their lesson because they are trying to rush to patch the lack of necessary hardware using software.

</comment></comment></comment></comment><comment><USER5> Props to the author or editor that came up with the title of this. To make it more embarrassing:

> MCAS: How 737 MAX system gained power to compete with Airbus and lost > safeguards

It's really tragic. If only they'd seen how much of a blunder this would be before lives were lost. But it's hard to get a big picture view until after the fact, when it involves so many people. I think perhaps Southwest was the closest to having a big picture view, as they ordered additional equipment [1]. I wish they somehow blew the whistle on it.

1: [https://theaircurrent.com/aviation-safety/southwest- airlines...](https://theaircurrent.com/aviation-safety/southwest-airlines-is- adding-new-angle-of-attack-indicators-to-its-737-max-fleet/)

<comment><USER6> _It 's really tragic. If only they'd seen how much of a blunder this would be before lives were lost._

Or, at the very minimum grounded that damn death trap volountarily after the Lion Air crash.

The first crash can be attributed to greed, short cuts, engineering blunders and immense pressure to rush the plane into production.

The second crash is corporate mass murder.

</comment></comment><comment><USER7> So my understanding following this:

* they designed mcas with a g sensor and aoa sensor and a max pitch, to fix a problem in a high speed test. They provide safety assessments based on having two sensors, limited pitch changes, and it only triggering in specific rare situations.

* they provided that to the FAA as justification no training was needed, and that there was no need to acknowledge the existence of the system. FAA agreed.

* After FAA approval they discovered that the aircraft didn't work correctly at low speed either, so they made it activate at low speed as well. Because it activated at low speed a g sensor wasn't possible (?) so it got removed. Now you only have a single (notoriously unreliable) AoA sensor controlling it. To compensate for poor aero they also needed to increase the amount of pitch needed. So the FAA approved MCAS with a 0.6 degree pitch limit, occurring at high speed, triggered by two independent sensors. Boeing then made the system trigger at low speed, off a single sensor, and increase pitch adjustment to 2.6 degrees.

* Boeing _chose_ not to test what happened if the AoA sensor failed.

* Boeing continued to insist that pilots not be made to retrain, because of contract penalties with southwest. That meant they did not want to mention the existence of the system.

* there safety margins also included an assumption that pilots could respond to a problem in 3s. But when mcas triggered incorrectly they were given speed, stall, and altitude warnings. All of which distracted them from the non-functioning led that indicate activation of a system that Boeing did not tell the pilots existed.

* the standard way to recover from the flight control computer triggering to much pitch was to flip a switch on the stick. Boeing made MCAS override that command, so the _standard_ recovery could not work.

* Boeing continued to claim the plane was airworthy and provided a work around for its hellbent desired to crash, which was to use the manual pitch wheel. Except MCAS was designed in such a way that as part of its crash into the ground logic it put so much stress on the system that it was not physically possible for a pilot to perform the workaround.

In all: more than 300 people are dead because Boeing rushed to make a plane to compete with another company, and then hid information about an overriding control system so that they wouldn't have to retrain pilots, and that completely changed the parameters of that system after FAA approval such that none of their approved safety claims were remotely true.

All to make some money so executives could get their bonuses.

Every executive who pushed for those changes should be put in jail.

<comment><USER2> And, Boeing's justification for increasing MCAS capabilities while reducing sensor redundancy needed was that these were changes in _degree_ , not in kind. Nothing about the FAA certification actually depended on the number of sensors required, or the amount of command the system had, the FAA allowed pretty much anything to fly as long as it was only designed to operate when outside of the standard flight envelope.

This is the gotcha in the whole liability for executives thing. The FAA is _extremely_ deferential to what manufacturers think is the best practice. Understandably it would be difficult to get every single little change to the flight systems approved - in broad strokes this kind of regulatory inertia is what makes physical changes so difficult in the first place, which indirectly caused this whole problem in the first place.

This isn't just a Boeing problem - Boeing was callous and indifferent to public safety, _but the FAA let them get away with it_. The takeaway from this crisis is that the FAA regulatory system needs significant reform, because it's obvious that it's got some unintended consequences. The correct answer here is that it should have been viable to design the airplane in an inherently aerodynamically safe fashion while the band-aid patch should have received a huge degree of scrutiny, but that's essentially the opposite of the system that the FAA has created.

<comment><USER8> The FAA situation is a difficult one to resolve - having full understanding of these systems requires a great deal of expertise, and that kind of expertise is found most easily at, obviously, the companies under regulation. More funding / regulators would certainly help, but I'm not sure if that would be sufficient.

> but the FAA let them get away with it

Well, the FAA thought the MCAS had a command limit of 0.6 degrees when it actually became 2.5 degrees after the changes mentioned in this article. From the other Seattle Times article about this:

> If the final safety analysis document was updated in parts, it certainly > still contained the 0.6 limit in some places and the update was not widely > communicated within the FAA technical evaluation team.

> "None of the engineers were aware of a higher limit," said a second current > FAA engineer.

To me it's less of a they "let them get away with it" and more of a "they had limited resources and things slipped through". Unfortunately this difference doesn't really matter when 300+ people are dead

<comment><USER7> I feel that's also by design: Boeing went out of their way to minimize the opportunity that the FAA had to catch what they were doing. Providing the experts no doubt helped, but just omitting changes by lying and saying all the changes were minimal to a system that had already passed safety review was their main tools.

Does the FAA have issues? yes. Will this event reduce the influence of the FAA in the future? Probably - we're already seeing the European equivalent adopting a stance of "the FAA is working for the corporations they're meant to regulate". Honestly the various politicians who gutted the FAA are fairly directly responsible for causing significant long term harm to American influence (for good or bad, depending of who/what/where you are).

Is Boeing entirely responsible? Yes. The FAA is meant to be adversarial to prevent companies from choosing money over safety, but fundamentally it was Boeing executives that made the choice to favour hiding design flaws to preserve profit (and hence bonuses). The fact is that any repercussions are almost certainly going to be entirely financial, and only harm shareholders (dividend and stock price) and lower level employees (e.g non-managers: managers, and especially executives, don't get canned when cash is low).

</comment></comment></comment></comment><comment><USER9> Retrospective ass covering, Boeing installed MCAS to save money, and in the process took control of the airplane away from the pilots. They should be looking at jailtime for this.

<comment><USER10> Boeing still gives the pilots a lot of control over the airplane, compared to Airbus. Airbus has defaulted to fly-by-wire (i.e: the computer has control and the pilot makes suggestions) for planes made since the 1980's.

<comment><USER11> Airbus doesn't try to hide that fact from its pilots.

<comment><USER10> Oh, for sure. The person I replied to made it sound like it was always a bad thing (to have a computer in charge), though, and that's certainly not the case.

<comment><USER12> Having a computer in charge works fine when the computer is designed correctly, with lots of redundancy and the pilots are trained to understand how it works.

This isn't what Boeing did.

</comment></comment></comment></comment></comment><comment><USER13> All of this to help avoid stalls. Such a pity because avoiding a stall seems to be one of the first things a new pilot learns. Every pilot should know how to detect and correct a stall.

Can an actual pilot conform or deny this?

<comment><USER14> It's not about avoiding stalls per se, it's about the uncorrected aerodynamics of the 737 MAX being such that at a certain point it becomes _easier_ to pull into a stall than push away from it.

While pilots learn to avoid stalls, commercial planes are designed _deliberately_ such that at any point short of a stall it always takes less force to avoid one than create one.

Uncorrected, the 737 MAX's behaviour is a dangerous and surprising deviation from norms. It runs counter to pilot training, and it makes the stall recovery they're trained to perform significantly more challenging than it would otherwise be. That's why the FAA rule about column forces exists.

<comment><USER15> The uncorrected behavior also violates a design directive encoded in the CFR's. The plane could not be certified as airworthy without MCAS active due to the non-compliant stick force response curves.

</comment></comment></comment><comment><USER8> Previous Seattle Times article about the certification of the 737MAX: [https://www.seattletimes.com/business/boeing- aerospace/faile...](https://www.seattletimes.com/business/boeing- aerospace/failed-certification-faa-missed-safety-issues-in-the-737-max-system- implicated-in-the-lion-air-crash/)

And HN post: [https://news.ycombinator.com/item?id=19421612](https://news.ycombinator.com/item?id=19421612)</comment>


Systemd Opened Security Hole in Linux, VPNs Could Be Compromised - <AUTHOR> https://linuxreviews.org/Systemd_Opened_Security_Hole_In_Linux,_VPNs_Could_Be_Compromised <comment><USER2> This title is the opposite of reality. The kernel default for rp_filter is 0, which is disabled. For a long while, systemd had been _closing_ this security hole, by setting it by default to 1 (enabled in strict mode). The recent change in systemd was to change it by default to 2 (enabled in loose mode), which is still stricter than the kernel default of "disabled". See [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/ip- sysctl.txt?h=v5.4#n1225) for the official documentation for this parameter.

<comment><USER3> Not to mention the CVE explicitly states that Devuan and the BSDs as well as a number of other non-systemd distros are affected. Looking closer the submitter here is the author of the post, the website it was submitted to is blocked from being submitted to /r/Linux for blogspam and the "Gangnam Style" links on the page appear to go to some shifty video site. The submitter and author is clearly just writing B.S. to drum up backlinks for some black hat SEO.

</comment></comment><comment><USER4> A response to the report [1] noted:

> This attack works regardless of if you have a VPN or not. The attacker just > needs to be able to send packets to the other host. It's not systemd > specific.

[1] [https://seclists.org/oss-sec/2019/q4/123](https://seclists.org/oss- sec/2019/q4/123)

<comment><USER5> > Most of the Linux distributions we tested were vulnerable, especially Linux > distributions that use a version of systemd pulled after November 28th of > last year which turned reverse path filtering off. However, we recently > discovered that the attack also works against IPv6, so turning reverse path > filtering on isn't a reasonable solution, but this was how we discovered > that the attack worked on Linux.

</comment></comment><comment><USER6> The title is a bit hyperbolic, but the discussion on the page is a good one. The threat is more academic than having practical exploits in the wild.

That said, there have been a lot of "academic" exploits turned into full exploits in the recent years.

</comment><comment><USER7> Found 51 CVEs relating to systemd since 2012 in a naive search[0]. All software of systemd's complexity has bugs, but a CVE every ~2 months over 7 years isn't hugely encouraging. Never mind the ever increasing surface area as systemd seems to take on ever increasing amounts responsibility in an average Linux system. I'm absolutely biased and have been unconvinced from day 1, but I've not seen much to dull my scepticism either.

[0] [https://cve.mitre.org/cgi- bin/cvekey.cgi?keyword=systemd](https://cve.mitre.org/cgi- bin/cvekey.cgi?keyword=systemd)

<comment><USER8> If you _want_ to find reasons to dislike systemd, you'll find plenty to pick and choose from. But if you instead _want_ to have systemd, and therefore want to find reasons that it's worth it, you'll likewise find lots of those. Whatever your initial opinion, you'll find plenty of things to support your case.

Meta-reasons for _wanting_ to like systemd in the first place include:

1a. It has plenty of nifty new features using the latest Linux features, most prominently cgroups.

2a. It makes it relatively easy to take advantage of those features for your own services, and/or to alter existing services to your liking.

3a. Probably for reasons 1a and 2a, most Linux distributions have long since changed to use systemd, and getting used to using a standard system is useful in real life.

The only meta-reasons for _not_ liking systemd which I have seen are:

1b. It doesn't work the way Unix always worked, and some people don't like using it, since they don't know all the ins and outs like they might do with the old systems.

2b. It seems to acquire, subsume and supplant lots of previously separate Unix systems like init, cron, syslog, ifconfig, etc. This, combined with 1b, only exacerbates the pain.

All other criticisms that I have seen can be adequately explained as being after-the-fact rationalizations stemming from 1b and 2b.

(Note: Anyone still using ifconfig on Linux should get with the program and start using ip(8) already: [https://manpages.debian.org/testing/iproute2/ip.8.en.html](https://manpages.debian.org/testing/iproute2/ip.8.en.html))

<comment><USER9> Longevity and stability is a big issue for me. Systemd may be the new way to do things, but will it be doing it the same way in 5 years? I'm not confident it will.

iproute has nothing to do with systemd, and I use it a lot (although I prefer the default visibility of "ifconfig" rather than "ip -o a" to see what IPs I have on what interfaces).

<comment><USER10> Systemd does have a wiki page about this:

[https://www.freedesktop.org/wiki/Software/systemd/InterfaceS...](https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/)

</comment></comment></comment></comment><comment><USER11> So this is just a configuration issue and the kernel defaults to even worse security.

</comment><comment><USER5> Here is the source (without memes) [https://seclists.org/oss- sec/2019/q4/122](https://seclists.org/oss-sec/2019/q4/122)

</comment><comment><USER12> I am not quite convinced by the arguments with which the attack is downplayed here. I think this explanation is biased too much towards attackimg short lived HTTP connections. Not all TCP connections are short lived. It might also be possible to spoof DNS replies with some guessing (if the VPN endpoint is associated with a known public provider, the DNS server is likely known as well).

<comment><USER13> Did you perhaps mean to say you're _not_ convinced?

<comment><USER12> Yes, I did a sloppy editing pass over the first sentence. Fixed.

</comment></comment></comment><comment><USER14> Is anyone surprised? Systemd has been steadily increasing its surface area over the years.

<comment><USER15> > Is anyone surprised?

It's hardly suprising that opponents like yourself dont even bother to read up on the issue being discussed.

Turns out (suprise!?) that the linux defaults in this case is even worse than what systemd provides.</comment></comment>


How Sweden's arctic 'millipede town' Kiruna is slowly moving - <AUTHOR> http://edition.cnn.com/style/article/sweden-kiruna-relocation/index.html <comment><USER2> "I had reached the age of six hundred and fifty miles."

The opening sentence of the novel _Inverted World_ , the relationship of which to this story is better off read than googled.

</comment><comment><USER3> I was there a couple of years ago. The people we talked to seemed pretty content with the arrangement. We took a tour of the mine and learn all about it.

Nearby there is also (one of ) the Ice Hotels where you sleep inside a building made of ice with beautifully decorated ice sculptures. Tip: if you go get one if the suites with a bathroom attached.

<comment><USER4> I don't recall there being any options for rooms with en-suites. The one I stayed at most definitely did not - I had to make a run in my pyjamas down the icy hall, out into the open-air courtyard and into the main reception bit where you get changed and stuff. The actual sleep was rubbish, but it was an interesting experience ...

<comment><USER3> "The Deluxe Suite has a private heated bathroom and relaxation directly connected to the bedroom."

[https://www.icehotel.com/hotel/rooms/365-en/deluxe- suite-365...](https://www.icehotel.com/hotel/rooms/365-en/deluxe-suite-365/)

Also... you sleep ok if you've had a few drinks... but yeah, you are basically sleeping on a block of ice.

</comment></comment></comment><comment><USER5> Somewhat related: TV serie "midnattssol".

[https://www.svtplay.se/video/10738923/midnattssol/midnattsso...](https://www.svtplay.se/video/10738923/midnattssol/midnattssol- sasong-1-avsnitt-1)

</comment><comment><USER6> I imagine the renovation business in Kiruna has seen a rough few years.

</comment><comment><USER7> Basically, Kiruna has a massive mine under it and some time ago we figured out that it was more profitable to ask people to move to the other side of town than to stop digging toward it. It's nothing magical or more interesting, it's just that it's safer for people to move a few Km than to live over the mine.

<comment><USER8> The interesting and cool thing is that it is profitable enough to warrant actually digging up houses and move them with a large truck! (well, 21 old heritage houses, so not really all housing)

<comment><USER9> I guess the profitable part comes from the fact that 4000 out of 18,000 people in the town work for the mine. If they closed the mine, the town would die anyway.

<comment><USER10> You're forgetting all the money that Spaceport Sweden brings in: [http://www.spaceportsweden.com/](http://www.spaceportsweden.com/)

<comment><USER11> It must be all that equatorial velocity...

<comment><USER12> Better than the 30% penalty for launching west from Palmachim. [https://en.wikipedia.org/wiki/Israel_Space_Agency#Palmachim_...](https://en.wikipedia.org/wiki/Israel_Space_Agency#Palmachim_Spaceport)</comment></comment></comment></comment></comment></comment>


Finhub: SEC's Strategic Hub for Innovation and Financial Technology - <AUTHOR> https://www.sec.gov/finhub <comment><USER2> It's incredible that the federal government has realized the disruptive nature of blockchain technology to the financial ecosystem before most commenters on HN. In 5 years, I believe most entrepreneurs reading this forum will be raising money and managing their cap table using the blockchain.

<comment><USER3> That's not what they are doing here at all. This is a thinly veiled regulatory body which will pretty much ban/kill all PoW/PoS/or anyother pseudo science blockchain projects.

It will likely shut down once they realize corporate America has pretty much ditched blockchain and has moved on. The people who are writing optimistic comments are grasping at straws.

Blockchain industry had 5 years to go mainstream. All it did was create financial ruin for duped investors while enriching those who bought the pre- sale at restrictive amounts of capital to risk.

Blockchain is a shitty and slow database nobody asked for apart from the people selling it's tokens that is somehow necessary to appreciate and depreciate in value on terms dictated by the very controllers. SEC will blow you out of the water if you've been caught pumping and dumping. I am in the process of reporting/sending slack screenshots of people in Vancouver to the SEC for pumping and dumping.

Justice is coming. In the form of US extradition.</comment></comment>


Mailbox, Evolution of Email and Spark - <AUTHOR> https://medium.com/startup-study-group/mailbox-evolution-of-email-and-spark-21a71bc749d#.mh8o8096a <comment><AUTHOR> I really think it's cool people are trying to innovate email all the time, and that it keeps working.</comment>


Ask HN: - <AUTHOR>

Do any of you not use Microsoft products for your startup based on cost or are there other larger factors? <comment><USER2> I've found linux to be the best environment for doing programming work. The command line is a powerful tool. The key is scripting repetitive tasks, so you only have to ever do them once. Most stuff in windows can't be scripted very easily.

<comment><USER3> _Most stuff in windows can't be scripted very easily_

I agree, though Powershell is quickly becoming the most powerful Windows tool I've ever used.

</comment></comment><comment><USER4> Please expand on the Headline instead of "Ask HN:". Maybe "Ask HN: Use Microsoft products for your startup - Costs Vs Other Factors?"

</comment><comment><USER5> Consider Microsoft Bizspark <http://www.microsoft.com/bizspark/>

A program that grants free software licenses for startups. Fairly easy to join.

</comment><comment><USER6> And once you allow one Business Software Alliance ( <http://en.wikipedia.org/wiki/Business_Software_Alliance> ) product into your business they claim you have agreed to be audited (which can be expensive even if you are innocent).</comment>


Elon Musk Interview with Joe Rogan - <AUTHOR> https://www.youtube.com/watch?v=ycPr5-27vSI&t=1s <comment><USER2> Wow, I knew Musk wasn't good at speaking, but he doesn't look at all like a CEO here. Part of that is probably because it is a long interview where he didn't get the questions ahead of time, but he just doesn't seem very confident in his answers, almost awkwardly answering the questions. Seems pretty stressed.

<comment><USER3> To me it seems the exact opposite than stressed. It seems completely relaxed, him just being honest about nothing and everything at the same time. Taking his time to think before answering, sipping on a drink and enjoying it too.

I agree he doesn't look much like a CEO, but does that need to be something negative? I think I know Musk better as a person after watching this, in contrary to the typical Silicon Valley "CEO" corporate interviews.

EDIT: Should be noted too that this is pretty common for Joe Rogan interviews. Relaxed atmosphere and 2-3 hours of thinking out loud without much structure or agenda.

</comment></comment><comment><USER4> Joe Rogan is disingenuous.

<comment><USER5> Why do you say this?</comment></comment>


Go, robots and refactoring - <AUTHOR> http://matt.aimonetti.net/posts/2014/04/28/refactoring-go-code/ <comment><USER2> I would suggest naming the method "Device" instead of "GetDevice". The word "Get" is almost always redundant.

<comment><AUTHOR> I totally agree, I found myself refactoring my own code and renaming "Get<>()" functions. I wish I had heard someone say that earlier :)

m.FindRobot("bot name").GetDevice("laser") would read better as m.Robot("bot name").Device("laser")

<comment><USER3> Agree, but due to my mild OCD, I still keep using Get to pair with Set :)

<comment><USER4> Another reason I've heard for avoiding getFoo() is that on certain typefaces the lower-case "g" and "s" look similar enough that folks with bad vision can confuse them[1]. Thus foo() and setFoo() are clearer than getFoo() and setFoo().

[1] Given enough time in front of a monitor, we all get bad vision eventually ;-)

<comment><USER5> That's easily solved by just not using typefaces that you can't read in your editor.

</comment></comment></comment></comment></comment><comment><USER6> >Go aka golang is an amazing language

By what standard? I've been very underwhelmed.

The type system is very mediocre. Support for generic programming is awful. What kind of language idiomatically involves casting to the top type? That would be like if Java idiomatically involved casting to Object, or C++ idiomatically involved casting to void*, just to get any sort of genericism. Look at almost any big Go project; the abundance of {}interface typed variables is alarming

And then how about language extensibility? Go relies heavily on built-in keywords, like range and make(). You want to range over a tree or a linked list? Too bad. You can only use built-in types. Or maybe you can wrap your data structure in a chan and range over that. Goodbye performance and simplicity.

Go is not a bad language. I use it on a number of web projects, and it works very well. But Go is not, by any metric I can think of, an "amazing" language. At best, it is a decent language with lots of corporate support, a good standard library, and some good tools like golint, go get, and go fmt.

<comment><USER7> I don't know what your definition of "amazing" language is, then, but a decent language with corporate support, a good standard library and good tools....is...well...pretty darn "amazing" in my book.

It maybe doesn't tickle me on an intellectual level, the way Haskell or Clojure do, sure, but for getting real work done, I'd choose it any day over those two.

Other "exciting" languages that play in the same field as Go are perhaps Rust and D, but neither of those have the same corporate/community support, tools, eco-system, etc.

<comment><USER6> >but a decent language with corporate support, a good standard library and good tools....is...well...pretty darn "amazing" in my book.

This also describes Java in 1997. I wouldn't call that an amazing language either.

>Other "exciting" languages that play in the same field as Go are perhaps Rust and D, but neither of those have the same corporate/community support, tools, eco-system, etc.

I don't know enough about D to speak about it, but at least Rust has a good type system (based on hindley-milner), support for generic programming, pattern matching, extensibility, etc. I'd personally call Rust "well- designed".

<comment><USER8> >This also describes Java in 1997. I wouldn't call that an amazing language either.

You're joking right? I've used Java around 1998 and its standard library wasn't good, "java can't print" was quite true back then..

</comment></comment></comment></comment><comment><USER9> Nice post Matt! I would love to see more of these eyewitness accounts of refactoring in the go community. Maybe a refactoring video should be in the works ;)

<comment><AUTHOR> Thanks Jeremy, let's book a few hours and do that together.

</comment></comment><comment><USER10> This is really helpful. I'm getting started with Go now and common idioms and refactoring are useful when moving past the tour and introduction stage.

</comment><comment><USER11> This is a really helpful article - nice work Matt.

<comment><AUTHOR> Thanks joe, I realized that the best way to learn is to refactor with one or more people. Hopefully, this summary of a quick refactoring will help others too.

</comment></comment><comment><USER12> Go looks interesting. Anyone else not a fan of the single character variable names?

Also, Is there a better way, in terms of clarity, to do this:

<\- c

Even with the comment I would think the developer forgot to fill in the first half of that and assume it was a bug.

<comment><AUTHOR> In the first version of the post I had

_ = <\- c

To show that we don't use the value read from the channel, but someone in my team pointed that, that this isn't very idiomatic and mainly a way to explain what the code does to someone who doesn't know Go.

</comment></comment><comment><USER13> Thanks for sharing this Matt.. really good insight.

</comment><comment><USER14> Great post really enjoyed it.

Also a big fan of golang, loving the posts by people using it in anger.

Thanks</comment>


Will America's universities go the way of its car companies? - <AUTHOR> http://economist.com/node/16941775

<comment><USER2> I think it works well with some majors, definitely. To compete, they will need to offer more than simple lectures. Economic majors will have to have more behavioral experimentation and you can't compete with physics majors who have a freakin' laser beams to play around with.

Though, getting my degree in economics, I now think it would have been smarter to do it at home. The worst thing that hurt my grades was being too lazy to walk to class. Once I did work online, my grades went from Cs to As.

</comment><comment><USER3> Let's be honest. The online classroom is never going to be able to offer keg parties and college co-eds. And that's just what the physical campus might be reduced to if they can't compete with the quality and cost of the online education. That and high end science research institutes.

</comment><comment><USER4> My prediction: Technology ends up making universities more money than ever.

I just don't buy the idea that somehow the people who invented this tech (MIT media lab and others) are going to be obsoleted by their own creation (the internet).

</comment><comment><USER5> Technology in education will create a much needed divide between instructions and interactions. Brick and mortar Universities will preserve the interaction model while tech companies will take over the pure instructional realm.

</comment><comment><USER6> "The supply of papers that apply gender theory to literary criticism remains ample."</comment>