skysight-inc/HackerNews huggingface dataset:
> Now, the new study would seem to suggest that humans may already be engaging in a kind of inadvertent iron fertilization campaign. But whether it’s having any significant effect on marine ecosystems or carbon storage is still unknown.

But, since we know we're increasing atmospheric carbon, we do know that any increased carbon storage stemming from this accidental fertilization effect is dwarfed by our carbon output elsewhere, right? To the degree that carbon and aerosol iron are released from an overlapping set of activities, perhaps this study reveals a modest change in the coefficient relating emitted carbon to atmospheric carbon.
I've been working in industry for 19 years and I don't think I know all of this stuff right now. What I do know is that in these topics there are a myriad of things I don't _really_ know.
Regarding: "It would be nice if the Times article devoted more ink to studies showing 5G to be safe, instead of 95% focusing on how the claims that it is dangerous are shaky, and barely mentioning studies proving its safety."

There have been no studies showing 5G to be safe, because there have been no studies on 5G.
>I suppose it's an example of how much failures are far more visible than successes

This is true of support systems. I think in general, more people remember Apollo 11 than 13.
It works for me to just raise my voice a little and say "wait" or "hang on, let me finish" if someone interrupts me. I also find it rude and irritating and it should be treated as such, but it's also often not intentional and just a result of conversational dynamics getting out of control. The goal should be to rein it in and keep the conversation going.
You can get closer to their nines by using less of their stuff - if you use every service aws offers to power a single app, you'll have markedly less 9's than if you only use a few...

The foundational services (VMs, dns, s3, etc) I've found to be more reliable than others (ebs).
I don't know if it's the same, but KISS launcher has been amazing for me. I have only like 4 or 5 utility stuff on the small favorites bar and everything else is hidden. If I truly need something that isn't in my favorites, I need to actively think about it and search for it by swiping up on the homescreen to open the KISS search bar. I no longer open my phone and see a cluttered mess and procrastinate by opening random stuff that seems appealing at the time.
It depends on their relationship, and the workplace and overall culture they grew up in. For various reasons, not everyone will be comfortable directly pointing out a flaw in their own boss.

I'd say that without knowing more, it's better to advise the safer and more diplomatic approach.
That was my observation as well. And that is why women in the office are often out-yelled.
I don’t see how soft spoken person can solve it, it should be recognized by the leadership as a problem first, and only then solution can be found. Which is - somebody needs to moderate the debate, or maybe some additional training.
Could be. I don't necessarily think it's fluff to identify what fascism looks like. Identification is interesting and you can learn from it. But I guess you could say that simply knowing what fascism is, is insufficient for figuring out if we're on the path towards it.
Of course not, we're talking about market values, not some mythical "real value". Food isn't in short supply and in fact (in historical terms) is unbelievably cheap. Meanwhile, technology and population growth mean that a struggling amateur musician today has an audience dozens of times larger than an average successful bard in the middle ages.
It's not 90% uptime, it's 90% SLA. As in the threshold for "down for more than that, we pay out".
https://en.wikipedia.org/wiki/Umberto_Eco
I wear a rubber band on my wrist and lightly snap it when someone is telling me something and I feel compelled to interrupt. It brings me out of the moment just enough to wait. But, you have to remember that the rubber band exists :-)
> Your 'happy path' must be surrounded by try blocks.

Not if you're doing it right, which means bubbling up (read: adding the exceptions to the "throws" clause) exceptions that you can't handle _then and there_. You leave the "real" exception handling to the code that's closest to the end user and can actually handle the error in a meaningful way.

For example, in this pattern when you implement the business logic in a REST service, generally there's no catching at all, instead the exceptions are declared as rethrown and way up the stack you would have a global catch all that serializes the errors into JSON and sends them to the user. Simple. In Go you're forced to do "if err{}" checks everywhere, particularly in your endpoint's business logic. It's actually _way less_ verbose and burdensome in Java if you do exceptions the right way.
>I knew exactly where and how things could fail and where things were failing just by looking at the code.

Same could be said about assembly language.
A la carte is annoying when everyone starts doing it. Subscription fatigue is already setting in for music and video streaming services. No reason the podcast space would be different.

Still, kudos to Tim for trying.
Yes. They cooperate with the LA police dept in real time passing information to help them catch the suspects or warning them of dangerous situations.

Amazingly, they have a code of conduct. If shots are fired they quickly zoom out so viewers don't get to see people getting shot.

The crazy part is when viewers watching the TV coverage in their homes come out onto the streets to cheer the suspects driving through their neighborhood trying to get away from the cops. In a way, just like the Tour de France!
Judging from the other comments, Wikipedia may be correct in this case. Although, as I noted, the cites are a few years old. So FN could have switched sides again.

Also, given that I don't know Italian, I don't really know what the police report said.
Read up

Read up this: google doesn't work with the US military any more, but continues to collaborate with the Chinese government. Is that enough proof?

https://www.nytimes.com/2018/08/01/technology/china-google-c...
I'm not saying they shouldn't, only that it doesn't follow from the economics of their retail/fulfillment business (to which those employees belong) that they rationally can.
You can pass functions to functions (https://play.golang.org/p/XNMtrDUDS0).

So you can do (sans syntax):

ErrorCheckerFunc(fn myParams -> MyFunc(myParams), "message")

ErrorCheckerFunc(fn myParams2 -> MyFunc2(myParams2), "message2")

etc...

and then the actual function:

ErrorCheckerFunc(fn myFunc, message){
returnVal, returnError = myFunc();
switchError:
case error is foo:
print error
case error is bar:
log error print "error logged"
...
case n+1 etc

// you can handle message in a similar way to get
// cases by function names, and if you have elixir
// style quote unquote metaprogramming in Golang you might just be able to get function names based on passed function - I don't think this is in the language spec though it may be possible to do some other way.

if error not nil do switchError(error)
return RuhRoh
else
return returnVal
}

It's not so bad, it's just a middleware.
i think this is called empathy
Would this be similar to passing argument(s) and return pointers/variables to a C function - or similar with assembler, reserving some registers for return values (aka caller manages memory)?

But with the (d) compiler helping enforce correctness?
The controversy may have died down, but the impact on code written would have been permanent.

There's a lot of value to there being "one way to do things", even when it's not the best way from any particular point of view.

Go holds this principle higher than most other languages and I think that should be either embraced, or one should look elsewhere - and I'm saying that as someone who "looked elsewhere".
I've had a limited exposure to COBOL and I consider it quite elegant for the problems it's trying to solve, particularly for column oriented transactional data processing, I found it interesting that on System Z, all of the IO, is done in the JCL that you use to start the program, not in the program itself.
agreed fully - Cubans seem to do this a lot; at first i would get really frustrated bc i thought i was being interrupted but i think it's buena onda

they also frequently ask if everything's ok, if you understand, etc. at the slightest pause in talking, which is kind of hilarious sometimes
I was greatly skeptical of these types of systems but ipfs proved me wrong. It's fine, when combined with a CDN. I'm interested in what new use cases Sia handles when CDN + IPFS works so well. For instance my blog https://www.wuli.nu (source code https://github.com/posix4e/blog)
Should Smart Contracts Be Non-Turing Complete?
10x programmers can hit a target no one else can see. This is true for 10x persons of all types in all endeavours, not just programmers. In this mode they are more artists than technicians. Compelled by vision from an overflowing sacred gift outpacing its faithful servant. Conventions and norms are not designed for this. Those who push beyond the bounds by definition cannot be bound by them. If you want to maximize their productivity, provide them with supporting infrastructure and surround them with brilliant editors to optimize this process and integrate their vision.
Sia maintains 50 contracts with hosts at all times, and uses 30 of them for each file segment that gets uploaded. We use state channels, so we can use the same contracts each time you upload a new file, minimizing the total amount of on-chain activity.
The OP is talking about bugs not complex system failures. These are not the same thing. It might take multiple bugs to cause a complex system to fail, because complex systems often have enormous amounts of complexity built in, but a single bug is often a fairly unidimensional thing. You can identify the root cause of a bug.
The Need for a FreeDesktop Dark Style Preference
Cloud solutions have plenty of issues, but I'm quite surprised there aren't more replies talking about how many impossible problems have been made tractable and reliable thanks to the cloud (or to be more precise, made much cheaper to solve reliably). The article makes a great point about accountability, in the sense that no one at a cloud-providing corp is immensely worried about transient failures that only affect small user sets heavily (which sucks if you're affected). But for my scientific computing use cases, getting things working reliably at any sort of scale within budget is impossible without the cloud. Research institutions' computing clusters are just smaller, less reliable, less flexible versions of the cloud (good luck getting sysadmins to do anything useful at all).

One of the collaborations I work in, LIGO, recently gave up on private servers and transitioned to AWS for our Gravitational Candidate Database [1] because the cloud is so much better. I made this change to my own low-latency search framework [2] years ago. If you're not "lucky" enough to (be forced to) use a university/collaboration cluster, you'd have to maintain your own server, which is orders of magnitude less reliable and more expensive/difficult. I understand that not all workflows are the same, but for all of my nontrivial applications, cloud providers save so much time and money that I can do something as bold as making a provider-agnostic architecture with more robust failover. I recognize that more complicated workflows might require e.g. 10 separate AWS services with AWS-specific features causing lock-in, but at that level of complexity, I'm guessing the problem must be virtually impossible with a non-cloud solution anyway. If you really can't figure out another way to deal with resiliency, you might just need to accept that your problem space is really hard and that you're lucky to even be able to run it at all. Again, I think the original article is right about the fact that you have to account for this yourself; the cloud is not magic, and your code still has to understand that it is (like all abstractions) going to leak.

Again, the point about responsiveness in the original article is very well-taken; I'm just surprised more people aren't observing that overall the reliability, cost, and flexibility provided by cloud solutions is utterly transformative in terms of reliability.

[1] http://gracedb.ligo.org

[2] http://multimessenger.science
And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics.

Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical portions of a modern browser). But it's not what I want to use as my daily driver.

I'm writing stupid shit that's munging CSV files and transforming json documents. I want a language that mostly gets out of my way, but performs well and can scale beyond a couple thousand lines of code. Go fits that space nicely, even with its (or maybe because of) conceptually imperfect error handling.
Also nice about Niagara is that you can hide apps from the full list of apps, but allow them in the search. This adds another level for burying distractions.
A Neural Turing~Machine for Conditional Transition Graph Modeling
If a tool is going to enforce line length limits, I'd rather have it spit a warning/error than silently try to guess a good place to break the line automatically. Otherwise, an editor tool that soft-wraps long lines at the (often poorly) guessed location without touching the code would be better.
How do you feel about timed exclusives? I gave up on Crimetown when the second season was seemingly a Spotify exclusive. But, then, a year later, they started releasing the episodes on the RSS feed.

Given how many "must-listen" podcasts I've been recommended, I can definitely stand waiting out these exclusives... until a cultural-moment series (a la Serial) comes along and necessitates real-time consumption.
Or TV shows that only work in Netflix?
All the attention is probably net good for Tesla. The media was laser focused on trump and look at the result.
Thank you Go developers! Please keep the language minimal, opinionated, and never subject to the bikeshedding mobs!

It wouldn't have been the end of the world but I'm glad to see Go still has alive the spirit that made it so popular in the first place.
I kind feel that declining try/catch is aligned with the baleful eye cast on Bob. The language designers think Bob is going to use try/catch to foist error handling on someone else or for later which never comes. And so error handling will then end up slightly broken to totally broken. So they'd rather when Bob's writes code with error paths that he to deal with that then and there. Not 'elsewhere' 'later' or make it 'someone else's problem'
And two people to ensure procedure happens.

You know the joke:
Go fishing with a Baptist, and they’ll drink all your beer.

Go fishing with two Baptists, and they’ll watch you drink your own beer.
People buy ridiculously powerful computers to play games at 4k@144fps and to train machine learning models. Then they install software to prevent malicious mind-control-equipped actors like Facebook from taking over their thoughts. Preventing your computer from using popular internet services isn't crippling it, because you do it to be able to use the computer more effectively.

There are are a number of features that are present in higher-end phones which are not available on lower-end ones (though some have started disappearing from high-end models or have become standard, more are always being invented): IR blaster, NFC, wireless charging, AR/VR capability, camera quality, fast charging, battery life, fast wifi, USB-C, OLED display, voice detection coproessor for OK Google / Siri, creating a WiFi hotspot to share WiFi (wireless card can get internet from a network and make its own network - this saved me from a big headache once). And also a fast processor which makes everything faster and improves the user experience.

Blocking usage of certain applications or services from your phone does not reduce the helpfulness those features and does not cripple the device.

Or, to put it another way: most phones these days contain software that exploits weaknesses in your brain to make you do things which do not serve your best interests. This launcher is intended to limit that. Doing so does not cripple your phone; it makes it more useful.

> buying a 500 dollar smartwatch in order to avoid taking out your 1000 dollar smartphone out of your pocket as much

Here you're assuming again that people buy hardware in order to use it. But that's not true; we buy computers because of their capabilities. A good device should add maximum value to the user with minimum time and money investment possible. An ideal device would give you those benefits without you ever having to waste time 'using' it. Smartwatches let you see notifications without having to use your phone, that's the entire point (aside from health/fitness tracking). That makes it an effective device for those who want that, but that doesn't mean it makes the phone any less useful. You may still want an excellent phone for when you do need to do a phone.

Your argument is like saying we buy tablets to not use laptop/desktop computer. Their uses may intersect, but each has areas that it is specialized for.
The technique you refer it is "inpainting", but such sophistication isn't necessary. If the object of interest is moving across a largely static background (pans and rotations are easily compensated for), then the missing background image you need in frame N is available in adjacent frames.

I've used such a filter to remove dirt and dust from 8mm films via avisynth, a program that goes back more than 20 years, though the filter in question is not quite that old -- at least 10 years.

Here is the filter in question:
http://avisynth.nl/index.php/RemoveDirt
The official US employment figures (U3) have very well known flaws when discussing the status of ordinary workers (they don't count people working part-time or casually that wish to work full-time, nor do they count people who have stopped looking for a job). U6 (which includes those factors and thus is a much better indicator of actual unemployment) is sitting around 8%.

More than 70% of Americans live pay-check to pay-check, and 40% cannot afford a $400 out-of-pocket emergency. The rate of people delinquent on their car loans (which is an economic indicator of how ordinary people finances are doing, since car loans are usually the most important credit people have to pay off) is increasing at an alarming rate. Economic problems for US workers didn't end in the 90s.
This is not just a tragedy for Brazil but also for the rest of the world as well. How many priceless artifacts have been lost that cannot be replaced... it boggles the mind. I found myself tearing up just reading about the researchers and students crying. What a nightmare it must be for them...
That isn't fascism though; literal meanings matter. There is no political ideology that chooses poorly administrated prisons as their defining feature.
>There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal.

Object thing1;
try {
thing1 = doStuff();
} catch(SameException e) {
// handle error 1
}

try {
return doOtherStuff(thing1);
} catch(SameException e) {
// handle error 2
}

vs

thing1, err := doStuff()
if err != nil {
// Handle error
}

thing2, err := doOtherStuff(thing1)
if err != nil {
// Handle error
}

return thing2

Happy path is flat. Control flow is obvious and simple. I have not much more to add.

>People say this, but in practice any code search reveals that "if err != nil { return err }" is everywhere. I believe that many Go projects aspire to annotate all errors, but much fewer actually do.

https://github.com/search?l=Go&q=%22errors.Wrap%22&type=Code

>Ironically, the nice thing about exceptions, as well as Rust error chaining crates, is that they do this automatically, so in practice programs written in languages with those features tend to have better error diagnostics than Go programs do.

Rust is a different ball game. Rust does not try to be simple. It comes at its own costs. (I like Rust too.)

>Computers are better at doing things consistently than humans are.

These empty platitudes come up frequently when debating language decisions online. But, it's so meaningless in so many dimensions. I mean, we could also 'use the computer' by adding C macros on top of Go and use them to reduce repetitiveness, but I don't think many people will applaud you for it. Simply applying computer code to solve a problem does not constitute good design.

Go's proof is in the pudding. It's been extremely reliable for me in real world applications.
Same here. Had to get a new battery after a couple years. It has thermal issues especially when the gpu is under load
Language choices like lacking generics make the over-reliance on dependencies less.
Early on the essay makes clear distinctions that not all moves toward fascism are necessarily fascist, in the very first bullet calling out “traditionalism” as being very distinct from “fascism.”

I myself find solace in some of the points of fascism- that part of the meaning of life is struggle, and the cult of heroism (are the Marvel movies fascist?). I certainly don't believe that qualifies me as a fascist, especially because I also strongly believe that tolerance of others is one of core principals of political morality.
LOL, they had to drag Silicon Valley into this, when those doctor salaries seem like minimum wage TC for engineers in the Valley nowadays.
`?` uses the `From` trait which means you often don't need `.map_err`. Ignoring crates like error_chain, even the stdlib comes with a From implementation for `Box<dyn Error>` - as long as your error types implement std::error::Error, you shouldn't need an explicit .map_err to box them:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

EDIT: That said, adding extra context will often require map_err or similar. But merely type erasing / combining error sources shouldn't need it, unless I'm missing something. (Most of my Rust use so far has been on toy codebases...)
I've had that book on my shelf for several years now after receiving it as a gift. I really need to make time to read it.
You give Sia a budget and it does a pay-as-you-go with the budget. You can set how long you want the contracts to last, by default it's 3 months. That means you budget for 3 months of storage, and then you don't need to pay into Sia again for 3 months.

Anything that you paid for but didn't use will be refunded in full at the end of the 3 months.

Right now Sia does not support filesharing of any kind, however that's in the mid-term (6-12 months) roadmap.
It sounds like it's a company wide culture.

It also sounds unhealthy for you.

Not everywhere is like that. I'd leave.
I like this terminology of "high involvement"! My experience with this style is also that if someone doesn't interrupt me I just keep talking, awkwardly, _hoping_ that someone will start talking "with" me (allowing me to pass the conversational baton, and indicating they understand my point), and if no one does I feel like no one must be understanding what I am saying (or worse, that no one is even listening) and eventually feel more and more antsy until I almost have to give up on the whole conversation.
Why would the card not identify your account? We already have cards that can do this. It seems that the only point of using facial ID is if you want to avoid forcing people to use cards (or if you want to collect and sell their biometrics, but lets assume altruism).