skysight-inc/HackerNews huggingface dataset:
You absolutely can - the basic argument for jobs is essentially "you can't reap the gains of society, if you aren't willing to contribute to it [in the form of doing your job]" - the underpinning argument being that there are jobs you can do. If there aren't any (paid) jobs, then you're stuck in a situation where people are taking away your rights to the gains of society, for their own benefit.

At which point, you need to fix the system - either make it so that jobs aren't necessary to get the gains (i.e. the money), or create "jobs" that aren't strictly necessary, or, if you cannot fix the system, rip it down with violent revolution and make sure the replacement system isn't broken in the same way as the predecessor.

Basically, it's outrage against a double-abstraction suckerpunch - either there's too much work or there's not enough work, you can't have both.
Isn't it this kind of thinking that leads to sql injections in number plate readers?
Why dont improve on IMAP with extensions, I can't see how the "extending IMAP only makes it worse" argument hold. How would adding an addition protocol (JMAP) to a buggy client make the situation any better? I can see how it's easier for fastmail as a company to try to get its changes out by making another protocol, but would we not benefit better by trying to improve on IMAP? it's very unlikely this will ever replace IMAP and SMTPS from history internet always try to iterate and improve not replace standards completely? There is great effort to improve on SMTP and encryption lately, what can we learn from that?
But you can act on it.
What does first principle mean here? Is it a from-scratch engine or is it a redesign of the chrome, or both?
Well if people say "don't use unwrap", they're simply wrong.
These are YARA rules, see https://virustotal.github.io/yara/ for a short description. The 'all of them' in the rule refers to the list of strings above it; it means that all those strings should be present in the binary for the rule to match.
He has something of a point; the Blitz was bad, and rationing and evacuation was bad, but compared to occupation? Compared to the sieges of Stalingrad and Leningrad?

The UK has never experienced occupying armies marching in and arbitrarily executing the public (unless you count, er, either of the "Bloody Sunday" shootings)
I deduce that you don't live in Brazil, where they definitely do not offer the same quality they do in Europe. In fact, they continued offering the T1 here, while they were selling the T5 in Europe.

They big 4 (Fiat, VW, Ford, and GM) spent decades selling trash in Brazil, because they had no competition.
It is a meaningful phrase, and maybe wikipedia doesn't have an entry for it, but it's a fairly common informal emphasis mechanism, not something the author made up.

https://english.stackexchange.com/questions/248861/how-commo...

https://english.stackexchange.com/questions/41078/name-and-o...
New in Debian stable Stretch: nftables
I don't know if people thought Proposition 13 was the best solution but the state legislature hadn't done anything to solve the problem and no one else did the hard work necessary to get an alternative on the ballot. So voters in 1978 had to choose between Proposition 13 or nothing.
How the Trump Tax Cuts May Actually Be Deflationary
Critical analysis is overrated. At least in America, democracy worked just fine for two hundred years before modern methods of conveying information to the public. People vote based on their guts and their values and that works pretty well.

There isn't really any better option. The basic problem is that political science isn't a science. It's cargo cult science. (What passes for "analysis" among the wonktitude drives the engineer in me bonkers). On an issue like Brexit, there is nobody who can predict with anything approaching scientific certainty what the outcomes of the two choices will be. You can dress up your choice however you like, referencing reports of this or that expert (who all have conflicting opinions), but at the end of the day is imagine most Remain voting was also done based on a gut-feeling commitment to Pan-Europism.
I've used both Rust and Go daily for years (before they reached 1.0, respectively) and I'm generally happen with the experience that they give me. Not all languages need to have a type system as sophisticated as Rust's or Haskell's.

> but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C

As someone who also has a decent amount of C experience, I don't see how this is a reasonable conclusion to make. The first point in favor of Go is that it's mostly memory safe (sans data races), which is achieved not just with bounds checks, but with a stronger type system. The second point in favor of Go is that Go does have a limited form of polymorphism that is checked by the compiler. In C, the only way you get polymorphism is by subverting the type system entirely. Both of those points are huge, and there's undoubtedly a much longer list that I could craft of smaller benefits if I were so inclined.

As we march toward complex type systems that move more runtime errors to compile time, we must also be vigilant of the trade offs we're making. Moving things from runtime to compile time isn't necessarily free; there's almost always some new cognitive load that is implied. It's important because if that cognitive load is "too high," then people aren't going to switch to it, and no amount of navel gazing is going to fix that. This entire thread is a perfect demonstration of that trade off in action. On the one hand, we have the "clearly superior" Rust approach to error handling that checks a lot more at compile time than Go does, but on the other hand, Go programmers don't ever need to "learn error handling" at all. They have a simple convention with a reasonably low bug rate (IME, anyway).

We can't just judge programming languages by their theoretical strengths. We must also judge them by their practical strengths. And then we must do the impossible: balance them. Snubbing our collective noses isn't going to do any good. Our only hope is to understand why people are attracted to languages like Go (such as myself) and figure out how to reduce the aforementioned cognitive load without giving up those sweet sweet compile time checks. Rust is clearly pushing that boundary, and I'm happier for it.
>> There’s no way for a user to simply download its entire database. “So we made a web crawler,” says Mizuno. “It’s a tool that goes to their website, searches for a company, and downloads that one company’s business relationship list.

it's not smart IMO to admit this publicly since almost certainly website TOCs would prohibit it and if the counterparty is sufficiently motivated, they could sue successfully (there was a recent Oracle documentation scraping case IIRC). Japan has laws allowing scraping but likely the jurisdiction of the target doesn't.
Streaming JSON - Event-driven JSON Parser in JavaScript
I think the idea has great potential, but the absence of a strong community is killing it :(
Of course, as they say, making prediction is always difficult, specially about the future. But we can make educated guesses.

We know from the past that new jobs are created in activities for what there are not machines able to do it. We are running out of things inside that category. It's not so bad an idea to stop and think about what could happen when we arrive there.

"short of Kurzweil-esque machine consciousness"

I have never received a dime for being conscious, but I have been paid for making inferences that machines can't do. That they can't do yet.
Indeed, MongoDB (with very careful configuration) has recently passed a round of Jepsen test, although patches were necessary after -rc3; see https://jepsen.io/analyses/mongodb-3-4-0-rc3.
Twilio Wireless (Programmable SIMs)
If you can blithely produce the sentence (if you can call it that), "This is not a meaningful phrase, you know that?", I think you ought to be able to find it in your heart to accept the use of full stops as an indication of a lengthy pause.
The Blitz was huge. It was terrible. It was also across a channel. He's talking about ground-level, street-to-street fighting, where you see men clomp into the town in which you live and remake your society, and that's very arguably a difference of kind. Britain has not seen fighting on its soil that was not internecine in the better part of a thousand years (honorable mention to the French who bailed on Fishguard Bay, though). The countries he's talking about were stomped on in living memory.
Does anyone even read posts?
I submitted our startup cambassy.com, and noticed that no clicks have been made, this means that users don't really look for new interesting posts, but instead flock around popular posts, if you read this post click upvote so we know if there is a point in posting here.
Checked exceptions are the correct answer. Just handle it.

Exception obfuscation frameworks (Spring) just kick the can down the road, creating problems without any discernible benefit.
Why aren't Java runtime environments install-able on Android like they are on almost any other operating system?
>don't yearn for a boss to tell which is which.

This is not what is being said - I will quote the parent commenter:

"Here it seems that an influence / behaviour change campaign could be waged relatively cheaply against a relatively small number of people, exist completely outside the normal rules for fact checking or veracity, and the majority of the population would have no idea about it."

This is talking about being "bubbled", and how different collections of people are seeing completely different things, and because both sides don't know what the other is looking at, they become alienated from each other.

Furthermore, there is another problem - while a singular lie can be countered, a thousand different lies told to a thousand different communities is much harder to defend against.
> strncmp and other API that treats the pointer to the string and its length as separable variables are not dangerous. They are much more secure than the non 'n' options.

"More secure" doesn't imply "not dangerous". It's definitely safer to drive a car without seatbelts than to ride a bike down the highway, but that doesn't mean that not wearing your seatbelt isn't dangerous.

> Problem here was usage of them at all. Hashes are not really strings, memcmp should have been used or even better secure (that doesn't leek timings) memcmp should be used.

This is incorrect for two reasons.

The first is that hashes in ASCII format are strings: it's useful to want, for example, case-insensitive hash comparisons.

The second is that (if I'm understanding the vulnerability correctly) the exact same bug would be present with memcmp:

if (memcmp(target, user_string, user_string_length) == 0)

> Problem here was just mistake in the program not in the C lib.

Yes. But a library that people make mistakes with all the time is dangerous. If you are a programmer who ever makes mistakes (and clearly the AMT folks are, but I'm pretty sure so is everyone), you should avoid dangerous libraries.
The 1000 Most Popular Books on Reddit – BookAdvice – Medium
".. soon its community will make good implementations of almost every hard problem in software and Rust will be absolutely everywhere"

This is very unlikely. I can't see when Rust would solve the problems Julia (for example) does. And vice versa of course.

Nothing wrong in a language tackling a few domains really really well and not trying to solve "every hard problem in software"
Most of my commits end up being "Yep" or "more stuff" or "Fixing tests". But before I make a pull request and/or push the branch to my remote, I squash them all together and

What you're saying about planning out/writing out what to do before the code, however, is still great advice. I end up doing that in the ticket description so I know what I'm doing before I touch any code.
The right to protest is not equivalent to the right to shutdown other people's speaking or listening rights. The protestors cross the line when they resort to using intimidation, physical obstruction, threats of violence, and/or actual violence. In most municipalities, such violations would be addressed quickly by the police. However, universities (and increasingly large left-leaning cities) have tolerated protestors use of intimidation and obstruction. One could argue why but I suspect it's a variety of practical as well as ideological reasons.
One of the hardest things about teaching error handling in Rust is that there is a lot of nuance. It's fun to say "unwrap is evil, don't use it," and more than that, it's not exactly wrong either. The nuanced version is that you shouldn't use unwrap for error handling, but:

1. If you're prototyping or writing a quick throwaway program, then unwrap will neither pick your pocket nor break your leg.

2. If you have an invariant that you either can't (or won't) move into the type system, then unwrap/expect/panic'ing can be appropriate precisely because if that unwrap gets tripped, then that will indicate a bug in your program that should be fixed.

The more succinct advice that I like to use is this: "if end users of your Rust application see a panic, then you have a bug." But this is slightly harder advice to follow because it's a statement about the user experience.
My first memory of browsing a GitHub repository, just a little before I started using Git (and any version control whatsoever), is one of a repository that had a brief description of each file in it right in front of it.

Actually, the brief description was the commit message of the last commit that modified each file, you know what I'm talking about, but somehow in that particular repository they did some trick to make these commit messages appear as descriptions of each file.

Or maybe it is just an erroneous impression I had at that time.
Adanada аkılаlmаz olaу Büyü bоzacağı іddіasıуla öğretmenle evlendі ablasıyla…
One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this".

Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on.

Yes, there's some awesome documentation, and the error messaging has gotten a lot better. But the power and flexibility of Rust comes at the cost of it becoming harder and harder to figure out how all the thousands of little pieces are supposed to fit together. What's really needed is a kind of "cookbook" documentation that has things like "How to read a text file with proper error handling" and "what is the proper way to pass certain kinds of data around and why".

Right now there's a lot of "what" documentation going around, but little that discusses the "how to and why".
Another thing I've learned over time is "don't be afraid to introduce commits before your current working state".

Let's say you're writing code and you need to use component X, and as you dig into it, you realize it's not factored the way you want. Rather than lumping a refactor of component X into one code review with all the rest, it's often better to save your work (using stash or commit), move your git HEAD before your latest work (using interactive rebase), do the refactor that you want, and then apply your other work on top of that refactor. If you're doing more work with component X and realize the refactor needs a tweak, or if you notice a bug from the refactor, you can go back and fix that commit using interactive rebase.

When you're happy with the refactor, you send it out as its own code review with a commit message mentioning "This is preparatory refactoring for feature Y". Then both the refactor commit and the feature commit are self-contained and easy for you to look over and easier for code reviewers to understand.
>The bigger the protest, the less credible the protestors seem.

I wouldn't agree. I've certainly never looked at a large protest and thought "wow, certainly those people look insecure", or seen someone speak unopposed and come to the logical conclusion that everyone who disagrees with them is so confident as to not show up.

>If the protestors are so afraid of a mild-mannered speaker that they need to prevent the speech from happening at all, that sends a pretty strong signal that the views being suppressed must be really powerful and probably contain a kernel of truth worth listening to.

There's a big debate as to what "mild-mannered" means, but I think it sends the stronger signal that there's a large group of the population who strongly oppose the speaker and will do the same to anyone who agrees with them: this is definitely effective, since articles like the one in the OP keep cropping up about how these people should be allowed to speak without fear of the protestors.

In any case, the protest is not over how convincing the views are, but whether they should be expressible at all.
man, that's awesome!)
Open-source self service customer portal for Stripe
it is just a tomb, how did belong to a saint?
Did you read the article? It's whole argument is that housing in Japan is much cheaper than other cities.
Exceptions don't need RTTI and have only runtime cost when thrown.
From where I'm standing, it looks like you're shifting goalposts:

> > RISC-V is thrown around like if it's an already working CPU but it is not

(Evidence of existing CPUs provided)

> I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.
Restricting freedom of movement was fine when it was done by most existing EU members to the Visegrad countries at the time of their accession.
> Democracy implies respecting the will of the majority whether you agree with them or not

Really, profoundly odd that you start going off about Trump in the same post where you write this. He didn't win the popular vote. He does not represent the will of the majority.
>How much does these uglifiers slow down the code for a the client?

I thought minification is good for the client. Smaller payload, easier for browser to parse the code because it doesn't have any unnecessary white space, comments and characters. Also not the best solution to security, but does obscure the code to make it harder for malicious client to read through the code.
There is an active (but just started) project to write a cookbook: https://blog.rust-lang.org/2017/05/05/libz-blitz.html
𝗇ìϲе homoglyph search tool you've made :)

(it found all the letters of the word "nice" quite well!)
"They've also pointed out that they can't give the UK a soft landing, as they need to show that leaving the EU is not without consequences; there's a few states thinking of departing, and if departing is painless, why wouldn't they?"

That says something truly horrible about the EU as an institution - that, by the admission of its leaders, what they think will continue to hold it together in the future is threats and intimidation.

Presumably this is because they intend to enact more Weimar-style tactics like they did to Greece and Cyprus and they think that the consequent impetus to leave across the EU will only strengthen.

The fact that they've been clear, up front and honest about this and May is in denial about it doesn't make it any less reprehensible.
Now you're making "planning" seem like a huge deal. No, sometimes you just want to do little change, that's what the article is talking about.

In other words: you commit a lot, right? Do you have an issue for each commit? If not, then you're not using "planning" in the same way OP is doing, and your comments about "planning" don't apply.
The 1-michelin star ramen place is 1500 yen all in.
> but little that discusses the "how to and why"

Have you read the book's chapter on error handling?[1] It's being replaced in the second version of the book, but I still plan on maintaining it as a blog post[2]. Any advice you might have to add more of what you want would be helpful. (And I ask this because I tried to attack the "how to and why" angle, so I'm wondering if I got that wrong.)

[1] - https://doc.rust-lang.org/stable/book/error-handling.html

[2] - http://blog.burntsushi.net/rust-error-handling/
> “Something not many people are talking about is playing the temperature card,” Bronner says [...] "All the talk I hear is about stretching Moore’s Law in the datacenter, such as using GPU accelerators. Those will work, but it’s a one-time shot. You use it once and you are done.”

But isn't "the temperature card" something you only get to play once as well? Once you've adopted supercooled computing, where do you go from there?

(This guy knows there's such a thing as absolute zero, and that you can't just keep getting colder, right?)

Sorry, I guess I still have antipathy towards Rambus since the 1990s. =)
SFGate had an article about this phenomenon.

http://m.sfgate.com/business/article/When-Their-Shifts-End-U...
This is the right answer. This makes easier to stay in flow because you are not distracted by side tasks like committing and have no worries about code getting lost. SVN was doing great here with autoversioning via WebDAV but git is even better because before you put in a PR you can squash your entire "run".

As for what the commit message is, who cares. I use uuidgen -r but whatever works. If the proverbial manure hits the circular cooling device and you need to back to a working version, you will work your way back via git log -p and similar tools anyways. It's more of a controlled undo than anything else.
Because Android does not run a normal JVM.
> your 'safe' language then happily crashes and burns everytime something goes wrong

I'm not sure why you put 'safe' in quotes here; nothing about 'unwrap()' (or even 'panic') is unsafe in the context of Rust. In fact, it acts just like Python would in the same circumstances: print a developer-centric message out and exit with a bad return code.

What's unsafe about that?

> if you're gonna have unwrap, you basically have to have exceptions as well

Why do you think that? unwrap() is meant to be the same as throwing an uncatchable exception; if you want to throw an exception that you mean to catch somewhere, you should be using something else.

> people prefer to use [unwrap()] than use the verbose match statement

People may not be aware (which will come with time) but there are more than just those two choices when it comes to error handling in Rust.
If you are going to limit learning to resources perfectly catered to your level of knowledge, then you are missing out on a lot. It's really not hard to go look up a few terms.
That's a great thing about Visual Studio. Difficult to do in a shell/vim environment.
How is this problem solved for C++?
Think you missed a "not" in there. =)
I prefer the list format without the images. Can you elaborate on what the specific dark pattern is in the Twitter case? I'm not a Twitter user.
The functional trio: map, filter, reduce is one place where it matters. In Python2 that was simple Python stuff. In Python3 map, filter, reduce is unPythonic.