skysight-inc/HackerNews huggingface dataset:
One of the big issues with this is how consumers/government will require algorithms to prioritize.

i.e. one can imagine that there are accidents with a certain context wherein a driverless car could prevent x amount of people from dying, by killing its own passenger. For example an axle breaks, you can't turn right anymore, only left, and you're coming up on a right turn. You're supposed to turn right and stick to your lane, you can't, you either go straight onto the other lane, or go left. You happen to be driving an SUV and there's two small cars in the lane. If you go straight you hit both of them, and the camera registers 2 young children in each and an adult driving. Given the difference in car sizes, you're likely to survive but also likely to kill at least two kids, perhaps up to 6 people, you'll definitely destroy 2 cars and injure all 6. Or you take a sharp left and drive infront of them straight off the road, you drop down in a cliff and die. In both cases the computer calculates to a large degree of certainty that if either choice is made that it'd go down pretty much like this.

Now this is a silly edge case but it's the best I could come up with right away, more plausible ones exists. Anyway the question now becomes, is it okay for cars to be sold that are programmed to prioritize the passenger's life, i.e. killing the maximum amount of innocent people who are not you, estimated between 2 and 6, injuring at least all 6, creating the biggest economic damage and loss of life or livelihood to innocent people (particularly 'innocent' as their car's axle was just fine, yours wasn't).

Or would a government require the algorithm to take a different priority, one in which the car's software is programmed to sacrifice the car's owner/passenger, for the sake of a utilitarian calculation?

I think the answer is pretty clear what's fair, and that if a computer wasn't part of the equation that an ordinary human would likely not have had the mental fortitude to identify the axle steering issue and all options and choose the best one and that the outcome would be worse than a driverless car. But I also think it's pretty clear that the 'fair' decision would still be highly controversial and scary to imagine and something that'll see quite a lot of debate and pockets of resistance the next few decades.
We care! Please do.
Looks interesting but hard to tell much about it based on the current website.
> Having a GC excludes you from some programming domains -- well controlled latency, bootstrapping/operating systems.

Even without the GC, D is still a good "better-C" language. The GC didn't stop people writing bare-metal / operating system kernels in D:

https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World!

https://github.com/xomboverlord/xomb
Typically they use row-oriented binary storage, optionally with individual columns or subsets of columns duplicated into indices for fast querying. Have you tried protobufs? How many hundreds of megs per second do you get? I think it is remarkably slow on the scales we're talking about here.
Tennessee University: stop using 'he' and 'she' – use 'xe', 'zir', 'xyr' instead
Not really. Those who don't hold this moral value will still think it's a privacy breach. If they think it's a joke and don't take it seriously, then it's some other problem instead of "moral vendetta"
The optimal betting strategy would be to "invest" a fractional percentage of your bankroll. See the kelly criterion from above.

Not doing so is suboptimal
Beware weaving progress bar code into computationally heavy routines. As soon as you want to start multithreading, it gets tricky. The worst is a ProgressBar singleton in a big C++ GUI program. If I'm going to bother using a library for progress bars, I want it to deal with all those work of combining multiple threads' progress, i.e. it has a queue, knows each thread's estimated share of the total work, and all the threads push progress messages on the queue.
hmm isn't this what people were mad at Amazon about? and now a story praising this type of work culture?

..unless i'm missing something

e: nevermind, they talk about a case of someone getting sick from overworking
The flip side is that these researchers also won't tell the public things uber doesn't want them to hear.
https://news.ycombinator.com/item?id=9414176
R&D and prototyping (like a ton of big inventions, e.g. the internet) could and should be funded to a very large extent by the government.

Wasn't the DARPA challenge a big driver for autonomous car technology?
How Hackers Could takeover Facebook business pages
Maybe founders are nice to Paul Graham but many of them are total douches to their employees. I don't recognize the industry I work in by his description.
After Successful Test: Blendle Deutschland to Go Live in Two Weeks
The slideshow referred to in the podcast: http://www.slideshare.net/reed2001/culture-1798664
> Could've sworn I've read somewhere the Rust maintainers stated that Rust will never have a switch to disable bounds checking. Has this changed?

Not having a switch to disable bounds checking is not the same as not being able to disable bounds checking.

> I don't know of any other specifics, but benchmarks usually show D outperform Rust (and often enough, everything else), e.g.:

It's been years since I saw those benchmarks. Those are benchmarks of the built-in library random number generator. Rust uses a more secure random number generator by default than most of the other languages, so it will go slower. If you really want to benchmark random number generation, pick a faster but less secure algorithm.
ummmm basically

the winners are basically amazing to their employees.

non-douchey.

because they're winning.

leading.

making their employees rich
Well said. Though of course another aspect of those social institutions was hierarchical stability: if a peasant married a nobility, had a child, and then gained claim to this family's assets then all would go to pots soon. On the contrary a marriage between two noble families would create political bonds to benefit them both. In fact the notion of "romantic love" didn't really exist until the renaissance (though unfortunately now we know pretty well this notion is also quite BS and against human nature anyways). Now with productivity largely increased and ordinary people having much more economic power such an institution has no reason to stand. It's just that social changes mostly occur slower than technical/economic basis for them.

And indeed, a relationship has to be based on mutual agreement and trust. If both sides agree this relationship to be open, then there's no problem at all. It's only problematic if they reached an agreement when starting the relationship, but later couldn't adhere to it. If no deal, then no relationship. If there's a deal, then you'll have to follow through.
YouTube is preparing to launch two subscription services
Secretary of Defense unveils $75M investment in Silicon Valley venture
I know many highly-competent individual engineering contributors and managers who quit Amazon (Lab126, mobile app store, CreateSpace) and found the NYT story accurate to varying degrees. Several of them were absolutely miserable. One was reasonably content, but still underpaid.
Oh man, this reminds me of the time I met an elevator with an operator. It was in one of the Smithsonian museums - perhaps appropriately the museum of american history? It was only 22 years ago, and I rode the elevator several times just to watch the operator work the strange controls. I wish I'd photographed it.
Again, bounds checking really doesn't show up in profiles. Iterators have none, and LLVM removes most of the ones that remain. It's really a non-issue.
Absolutely. I think they can do more. The Challenge was relatively (mostly because there wasn't much else) significant 10 years ago and had relatively small ($1m for the winner, per year) attached to them. Not quite the effort we'd expect in relation to the size of the automotive industry, or the damage of externalities of driving that could largely be solved or improved (loss of life, injury, congestion, fuel efficiency, cost of transportation etc). I'm also not aware they continued after 2007.

Of course I wouldn't be surprised in the least if all those university teams (e.g. Carnegie Mellon who came in first, or MIT who came in 4th) are either employed at e.g. Google or Apple working on these things right now, or provided or are providing the research to those who are.

edit: yeah Google's driverless car project is headed by the Stanford director whose team won the 2005 DARPA challenge.
> Not having a switch to disable bounds checking is not the same as not being able to disable bounds checking.

Not sure what you're getting at. Marking the entire program as unsafe is not realistic. Marking specific portions leaves a long tail of code that "rarely" runs, but still adds up.

> Those are benchmarks of the built-in library random number generator.

The levgen-benchmarks programs implement the XOR-shift RNG in both the Rust and D versions.
Hmm, well, we ended up closer to confusing. I couldn't make sense of your comment at all, not knowing anything at all about this author I assumed there was some reference I was in the dark about.
Rust has iterators which avoid the need for direct indexing in many uses of contiguous-memory storage, and hence avoid unnecessary bounds checks (just like D's ranges). When indexing is required, bounds checking can be disabled individually by indexing with `get_unchecked` (or `get_unchecked_mut`): http://doc.rust-lang.org/std/primitive.slice.html#method.get...

In any case, when comparing language performance, it's generally good to avoid comparing backend performance, i.e. focus on the LLVM-based compilers in the pnoise benchmark. A GCC-based Rust compiler would almost certainly outperform the current LLVM-based one for that benchmark (as suggested by gcc vs. clang and gdc vs. ldc2). Of course, such a compiler doesn't currently exist, so if you care about getting your code to run as fast as possible right now, Rust isn't the best choice based on that benchmark, but Rust has several reasons that it's likely to outperform both C and D by default:

- better aliasing information (than both C and D), so compilers can optimise more aggressively

- lifetimes mean more aggressive stack allocation/ownership patterns can be used without risk (a bonus over C, and something that D solves via GC, which has its own upsides & downsides)

- the type system has been designed to be particularly good at concurrency & parallelism, so again this can be used more aggressively and in more situations (e.g. libraries can expose interfaces that allow mutating data directly on the stack of other threads without risk of data races or dangling pointers)
China Takes Aim at Its Coders
You can't be further from the truth. A vast magntitude of bugs are due to the system running as if nothing has happened operating on garbage data, and giving you garbage results. If your system is robust to garbage data, say neural network training, good luck finding the bug then.
2008, 2010, 2011, and the recent events stemming from the Chinese markets seems like more than just twice in a decade.

Also, correct me if I'm wrong but day traders / short sellers aren't obliged to keep the stock positions for any length of time.

I just find the phenomena interesting in context of financial bubbles, as the largest financial traders are incentivized to exploit instability of markets, and would be eager to create bubbles for the inevitable pop and profits on the plunges.
Netflix' long term view is "Look at the bigger picture" and yet their turnover rate is an abysmal 20%-25%. I fail to see how this is looking at the bigger picture.

I also fail to see how you can feel passion for Netflix (one of their company values) when, as an employee, you are basically treated like a commodity.

I guess this kind of culture must be great for C-level execs like Ms. McCord, but not so great for run of the mill engineers or salespeople that favor stability for themselves and their families over a 2% increase in Netflix' bottom line.
A blog is not a Show HN. Please read the rules: https://news.ycombinator.com/showhn.html.
But don't you think his clients know that? If I'm buying fire insurance, I expect to lose money on it. I'm not betting on my house burning down, I'm just limiting the impact in the unlikely event that it does.

Now, if your point is that Taleb doesn't explain it that way, you are right. But the only astonishing thing about this is that the WSJ deems it worthy of reporting that put options have gone up a lot when the market went down a lot.
The problem with hypotheticals is just that: they're hypothetical. They don't exist in the real world. There's never a situation where you have precisely 2 options, one of which kills your passenger, the other of which kills oncoming cars. There's always a multitude of options, with various risk factors associated with each one.
Well, the edit window for the above post is now gone, but...

You can also see that the first clause is talking about the collection of States in the use of 'their' at the end:

>The judicial Power shall extend to all Cases, in Law and Equity, arising under this Constitution, the Laws of the United States, and Treaties made, or which shall be made, under their Authority

In Article III, Section 2, Sentence 1, United States does not refer to a monolithic entity and Laws does not refer to a specific unit of law (U.S. Code). The sentence refers to the totality of all laws that exist within the United States (that is, all states which the Constitution subsumed).

Can someone show a valid parse of that sentence that means otherwise?
> Languages that reject such ideas in favor of others simply will not be used, given a choice.

That is the key issue, "given a choice".

I saw game developers being dragged into accepting C was replacing their beautiful Assembly, followed by game developers being dragged into accepting C++ was replacing their beautiful C.

You can be pretty sure if tomorrow Sony, Apple, Nintendo, Google or Microsoft said "you must use language X", they would do it.

So yeah, given the choice they can continue to lose money thanks to memory corruption exploits.

Signed code and NX don't protect against memory corruption. One can use ROP to work around it.
What's especially interesting is the mention of "joint-stock companies". There's a little more detail on that here: [1] It's not clear whether these were ongoing entities or shares in a venture.

"Venture" in this sense comes from shipping, where a number of people would put in money to buy shares in a single ship voyage. When (and if) the ship came back, the profits were divided in proportion to the investment. (This is the source of the phrase "waiting for (their) ship to come in".)

But it's not a corporation. It's not a permanent organization. This is significant. The Roman Empire, even though it had a legal system and a stable government for several centuries, never developed the concept of the corporation, or of a common carrier. They had rich individuals as sole owners, and family businesses, but not larger multi-owner organizations. Something like a multi-city merchant company was out of reach. Even a commercial delivery service comparable to Wells Fargo (the stagecoach operation) was never developed.

Did Kanesh get past that hump and figure out how to set up a big business?

[1] https://books.google.com/books?id=vYMmrenUywQC&pg=PA131&lpg=...
> thinking you are checking for a null pointer may not always hold especially once inlining happens

Incorrect. The example code did not check for a null pointer. It dereferenced a pointer, which implies that the pointer will never be null, and then it pointlessly checked for null on something that could not have been null. The optimizer in fact made the code more clear and easier to read, while maintaining correctness.
> but still adds up.

No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). Even bounds checks in hot code frequently don't matter. Have you profiled Rust code and found bounds checks to be a problem?

> The levgen-benchmarks programs implement the XOR-shift RNG in both the Rust and D versions.

Oh, I see that they changed it. Still, that benchmark is from 2013 and doesn't compile anymore. It predates unboxed closures and many other performance improvements. And 15% is in the "different register allocation decisions will affect the outcome" range, where comparisons are fairly meaningless. The fact that D and Rust beat C doesn't mean that they're faster than C.
You can avoid elevators you can't avoid cars.
And elixir/erlang are great for writing custom servers handling custom protocols.... but you're better off just dropping in Cowboy and working at a higher level.

Go is really compelling in producing a single-binary application... but for web apps, I think Elixir wins because it's working at a much higher level, and thus you're more productive.
What excites you about channels in Clojure when you do not really have lightweight threads on the JVM?
In almost any case I can think of, the answer is: slam on the brakes and come to a complete stop.
I don't think there is any correlation between exciting/boring and profitable. Index funds ar one of the more profitable strategies (as they don't involve paying some guy a ton of money to play lotto for you). They are certainly boring. Taleb argues that people Investing are really bad at estimating the value of catastrophic failure (or blowout success) and invests accordingly. He is playing the other side of Y combinators strategy, very much in agreement with Fred Wilson, Y combinator etc, just the other side of the spectrum.
It somewhat annoys me that we could eliminate 99.9% of accidents, yet people still would object to a self-driving car because of contrived fictional situations like the one described above.

A freak situation like the one described above would surely make the news - "Hero driver saves family by giving his life" and/or "Our mom would still be alive if that asshole wasn't so selfish". Yet I don't remember seeing a single story like this, ever. From comment threads on self-driving vehicles, you'd think these moral dilemmas are a daily, if not an hourly, thing in traffic.
My biggest worry would be bad repair work on the sensors or people who know the car is buggy but won't take it in for repairs. You can legislate against that, but people only listen if they get caught.

But there are a lot of up sides, too, for driverless cars (no distractions / intoxication / etc.) so I hope we can work things out.

But we can debug computer failures in a way we cannot for driver failures, so I do think we'll see some predictable level of social backlash and fear of the unknown, even if it's statistically irrational. I mean, driving is already one of the biggest intentional risks that we underrate every day and I doubt computers are ever going to be perfect.
Please, God, Don't Let Mozilla Ruin Firefox
The output of the demo program, FWIW:

$ ./demo
Smooth |=====================================================| ETA: 0h00m06s
Three Second Task with a long label |========================| ETA: 0h00m03s
Fast |=======================================================| ETA: 0h00m02s
Custom <.....................................................> ETA: 0h00m06s
Indeterminate: 0:00:03
Status bar with a really long label: 0:00:01
Custom: 0:00:03
Merely identifying it as a separate concept is not especially useful. Tagging an image with the 'cat' tag is useful; tagging it with the 'concept 50765' tag, not so much.
> D is more pragmatic

Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless.

For example, for embedded devices D is a no-go from the beginning. I'm not just saying the reliance on GC. D has a few ridiculous behavior that may cost significantly on the low resource devices, such as http://forum.dlang.org/thread/mr6bl7$26f5$1@digitalmars.com D is never pragmatic in this area. But of course, D may be pragmatic in other areas.

> expressive

D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs.

> and generally has better performance (e.g. bounds checking is optional).

What? How can a GC'ed language be faster than a non-GC'ed language? Besides simple numeric evaluation, D is generally more heap-allocation-heavy than Rust, so it can never beat Rust. After all, there's no point in Rust if it's slower than a GC'ed language. The benchmarks you linked are questionable too, as their results say D is faster than C. Are you really sure D can outperform C in general cases?
I can't reply to pcwalton directly for some reason.

In reply to https://news.ycombinator.com/item?id=10139287 :

> No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with).

OK, I trust your expertise on this. The "long tail" applies to optimizations in general. I don't know why the benchmarks are slower for Rust then, could be the difference in backends.

> The fact that D and Rust beat C doesn't mean that they're faster than C.

I don't know what's going on there, but some languages allow writing fast code easier than in C, e.g. SIMD vector array operations.
The change in elevators was from having a professional operator to allowing passengers to push the buttons themselves. Elevators are still "driven" by humans, not robots. The self-driving cars are a whole different ball of wax.
> Prices for the Campaign items — chairs start at $495, love seats at $745 and sofas at $995 — are a bit more than Ikea’s, but they include shipping to anywhere in the US.

"A bit more" is a drastic understatement. Somebody buying a $160 Poäng for their first apartment or to replace a chair that three kids broke is nowhere near the same demographic as these prices.
I saw one in the Air and Space Museum just this summer. Your tax dollars at work, America.
Sure, but the trader from the article is just a single person with millions.

How many other traders out there look forward to bubble bursting events like this? Commodity disasters? Oil disasters and shortages? The whole "dumb money" (retail trades, casual investments, passive investment funds) vs "smart money" (day traders, hedge funds, insider traders, HFT) would lead me to believe that it's beneficial to exploit the excessive pumping up and bursting of financial bubbles, as it only siphons up 'dumb money'.
Nice! I did one in c++ when I was first learning the language and it's interesting to see the similarities/differences in the code.

Implementing a Chip 8 emulator is really a ton of fun and an excellent project to boot because it isn't too complex but teaches you all the fundamentals of emulation.

https://github.com/TylerBrock/chip8
The bloom filter thing is interesting - it was just useful enough to stay occasionally used, till what a decade ago when simple lookup needs exploded around key-value stores.

But I would suggest the "occasionally used" is as much a signal as anything - I'm wondering how to discover that signal.
No, the image most non-West-Coasters have of California was always a mirage. There was smog in the San Fernando Valley in the 50's.

But you can't really judge all of it from LA. California is huge, and LA is a small but uniquely artificial, plastic-y place, inhabited by pretend humans. If that's a problem for you, you're not going to like it. San Francisco has its own unique bullshit factor that you may also not like, but it's not the same culture as LA.

And the climate is getting worse (thanks to global warming).