This worked for me on Chrome: https://news.ycombinator.com/item?id=25305835

As with any new technology, I'd start using it in new non-critical projects as risk is low and it makes it easy to convince the stakeholders.

To clarify, Pulumi can coexist with Terraform and other tools in the same stack, see https://www.pulumi.com/docs/guides/adopting/#coexistence

Watch out, the email address seems to have a typo.

Thanks for the heads up :)

The mail in the post is working though, I was victim of a poor copy paste! But we've setup a new one to make sure there's no room for doubt: portostartup2020@gmail.com

I do something similar but, because I'm faster at multiplying, I do "its double plus its half". E.g. 7 inches = 14 + 3.5 = 17.5 cm

From my experience, there's no such a heavy price as long as you don't rebase what you already shared with others.

Or why bother with those webpack features if the tools you use already do the job?

How this applies if I want to share my branch to accept changes from other developers (think pair programming, handovers of half-done features, ...)?

I've being using this trick for years instead of the ugly

    isset($array['key']) ? $array['key'] : null;

thinking I was simply ignoring those stupid "Undefined index" notices.

Now I figure out I was also hiding "Undefined variable" notices when $array was not defined and a ton of potential errors when $array is an object implementing ArrayAccess.

Shame on me.

Finally, an explanation for why it's a bad idea, after all these people just going "it's a misuse", "impressively awful", "really horrible"...

Thanks.

Note to self: grep the code at work for @. Purge.

Yes, the main issue with using @ is that it conceals side effects and sweeps all errors under the rug -- including the ones that you may actually want to handle.

Although there may be some scenarios where it's permissible, such as @unlinking temporary files when upload validation fails. It only happens in exceptional cases, the outcome is not immediately crucial, and you don't have any dependent operations.

All of this is moot when you do the following though:

- Set error_reporting to -1 (report ALL errors)

- Register a custom error handler that converts all errors to exceptions

This renders the @ operator useless (it'll throw an exception regardless). I personally prefer this since it enforces error handling discipline early on.

That's an interesting idea on the custom error handler, I wasn't aware that those trigger regardless of @s.

I guess a lot of the trouble with @ is that it affects everything that happens temporally-within the expression, but people often use it as if it only affects everything syntactically-within it... for instance, recently I came across something like:

    // suppress warning for <2 results
    @list ($foo, $bar) = returns_a_list(...);

... which would also hide any warnings that occur in the body of returns_a_list(), despite that being neither intended nor wanted.

It's a shame the only @-free solutions to many popular uses of @ (like that one) are so hideously ugly. Also that I suspect that changing @ so it only affected syntactically-contained errors would be... impractical for the PHP team, for a number of reasons.

I agree keyword arguments are a better solution (but probably harder to implement).

Right now this is how I do this:

    function salute($user, array $options = null) {
        $options = (array) $options + array('shout' => false);
        $salutation = "Hi $user!";
        if ($options['shout']) $salutation = strtoupper($salutation);
        return $salutation;
    }

It is significantly harder to implement, especially if you think about what happens with existing functions, especially internal ones.

It's just the opposite but you may find it interesting:

http://plusfeed.frosas.net/