U.S. Is Bankrupt and We Don't Even Know It - <AUTHOR> http://www.bloomberg.com/news/2010-08-11/u-s-is-bankrupt-and-we-don-t-even-know-commentary-by-laurence-kotlikoff.html

<comment><USER2> These kinds of articles often seem to include a line like the one in this one: "And bond traders will kick us miles down our road once they wake up and realize the U.S. is in worse fiscal shape than Greece."

What is it that makes people think people in US bonds are "asleep"? I certainly don't know whether they are or not, but it seems to go against the almost dogmatic claims you see elsewhere that the market "knows" and already has rational future expectations priced in.

<comment><USER3> The Starbucks Principle: Just because something seems stupid and wrong, like opening four Starbucks outlets on the same intersection, that doesn't mean the market will punish it.

Some people are deeply offended by the fact that America's unique position in the world economy allows it to run an incredible deficit without being punished by the market. The bond vigilantes are just a bogeyman invoked to preserve the illusion of a just world. The reality is that heavily-indebted examples like Japan suggest that the US can probably be mismanaged for decades before real consequences kick in.

</comment></comment><comment><USER4> I would think that news about U.S. bankruptcy _should_ be of interest to the startup community, so let's maybe re-orient this discussions towards: "Does this kind of doom-and-gloom news also scares the crap out of you as a startup founder? Or is it just meh?"

<comment><USER5> But this article isn't "news" about US bankruptcy - it's one-sided polemic. The US can't default on its debt in pretty much any scenario, because its debt is denominated in a currency it can print, and even more so since deflation looks like the problem, no inflation in sight; but that's only the beginning of its one-dimensional perspective, and it really doesn't belong here.

<comment><USER6> I voted you up, though I disagree that it shouldn't be here. I think it would be interesting to take the article and have an interesting discussion around its main points. These kinds of rational and intelligent discussions at HN are what make it so worthwhile, regardless of the topic. With the caveat that I don't want a Repub vs Democrat or Apple vs Android flamewar, but I don't think this qualifies as that type of piece.

<comment><USER4> Interesting you put Apple vs. Repub and Android v.s Liberal in the same sentence.

</comment></comment></comment></comment><comment><USER7> "Hacker news" is getting more and more political everyday. Thought I signed up for a tech and VC news site.

Disclaimer: I actually agree with the opinion in this article, but I don't want politics with my tech news.

<comment><USER8> This is no mere political news, but an ominous sign of the times - of today's broken system. It might/will directly affect more than half of the hackers and indirectly all of us.

<comment><USER9> In what sense is "mere political news" distinct from an "ominous sign" of "today's broken system" that will "indirectly [affect] all of us?"

These submissions are getting really tiresome, not least because of the way discussions proceed: the article is submitted, it's silently upvoted by people who agree with it, and everyone who disagrees posts comments explaining why. This was the pattern on the "Why I'm Not Hiring" submission a while ago; nearly every comment explained the many idiotic deficiencies of the article, but it was still a highly upvoted submission because of people who agreed with its substance.

Very annoying.

edit: And now I'm getting silently downvoted too, in the mirror image of the above phenomenon. Excellent.

<comment><USER8> Fair enough. I'll explain why I find this article important.

The current crisis is not cyclical, it's man-made:

<http://www.rollingstone.com/politics/news/12697/64796>

Some have seen it coming, ie it could be averted.

<http://www.youtube.com/watch?v=2I0QN-FYkpw>

Countries have been breaking the basic economic law - income >= spendings - for a long time. There are several ways to get rid of the debt, eg inflation or nationalization. All of them are unethical and are basically stealing from all but a select few at the top. That's what this article is about.

If things come as far as the author writes, it will affect all of us here at Hacker News. There is a lot of people here trying to create something, to enrich the others and thus to get rich. It will all be in vain if our governments decide it's time to rob us.

I could have been less emotional and more specific about this. Thank you for challenging me.

<comment><USER4> This is exactly why I think this kind of article is appropriate for HN. If you know as an entrepreneur that you are operating in a closing window of opportunity before the big crash comes, how does this affect your startup decisionmaking? Are you building with the people on Flippa.com in mind or the fine folkds at the Long Now?

</comment></comment></comment></comment></comment><comment><USER10> How about a nice big disclaimer:

 _Bloomberg Opinion_

<comment><USER11> Actually this is Laurence Kotlikoff, he's pretty interesting : )

<http://en.wikipedia.org/wiki/Laurence_Kotlikoff>

Wikipedia: _In Kotlikoff's words, using the deficit as a guide to fiscal policy is like driving in LA with a map of NY. For unlike in our physical world in which we are all using the same language (have the same frame of reference), in the world of economics, we are each free to adopt our own frame of reference -- our own labeling convention. Thus, if Joe wants to claim that the U.S. federal government ran enormous surpluses for the last 50 years, he can simply choose appropriate words to label historic receipts and payments to produce that time series. If Sally wishes to claim the opposite, there are words she can find to "justify" her view of the past stance of fiscal policy. And if Sam wishes to claim that that economy has experienced fluctuations from deficits to surpluses of arbitrary magnitude from year to year, he can do so. Language is extremely flexible. And there is nothing in economic theory that pins down how we discuss economic theory._

</comment></comment><comment><USER12> As soon as he brought up Social Security as the problem instead of, you know, two Trillion Dollar Infinite Wars^W^W^W^W infinite wars costing trillions or the Bush tax cuts, I stopped reading.

<comment><USER13> I had a similar reaction. You can often tell where a writer's bias/agenda lies by what is cherry picked and what is ignored.

</comment></comment><comment><USER14> If the US is bankrupt and we don't know it, does it not then mean that the consequences of being bankrupt are trivia enough that we should not worry about bankruptcy?

</comment><comment><USER15> Bankrupt means _you cannot pay your bills today_.

The US has many future obligations, which I'd best characterize as "indebted". We can easily meet them if we war a little bit less and tax people like we used to.

</comment><comment><USER16> We all know the U.S. is worse off than most citizens earnings compared to the 14% GDP of what the government brings in every year. And to date, the U.S. Government has NEVER missed a payment for their debt, loans or interest. So until they do, will our economy be destroyed.

What this will take is some think tank getting together and congress listening to them with a KEEN ear. We know our country is under bad circumstances, but with personal greed and politicians thinking that this $200k trip won't do anything in the overall scheme of things is what we need to change. It needs to change fast and with a drastic scale, but when are we actually willing to listen.

<comment><USER16> Why did this get bad reviews when its the truth.</comment></comment>


Facebook worker dies at company headquarters in an apparent suicide - <AUTHOR> https://www.cnet.com/news/facebook-employee-dies-after-jumping-off-of-office-building-in-apparent-suicide/ <comment><USER2> Can we stop the blaming here? Every suicide is one suicide too much. I know what this does to relatives and friends; my father committed suicide when I was 12. I'm 33 now and it still affects my life.

If you know someone who appears to be depressive or even suicidal, try to be kind and supportive. It helps a lot.

</comment><comment><USER3> This sad news is buried here on HN but surfaced on my Twitter timeline. Surprised there isn't more empathy or anecdotes going around to bring light to issues surrounding this situation. There is a real need to humanize work in our industry and heed mental health. Work is hard, and this lost life speaks to how terrible reality becomes when work and identity has is unbalanced, too tightly coupled.

</comment><comment><USER4> Why flagged?

</comment><comment><USER5> Why all the downvotes?

<comment><USER6> > At least this person didn't hurt anyone else

Except

\- the ones passing by while or shortly after it happened

\- the people looking out of the window and seeing them fall

\- paramedics and other rescue staff having to look at them from close up

\- the people who have to clean up afterwards

\- the ones who have to pass by that spot in future

\- ....

And then: Not to forget colleagues, friends and family who lost somebody. Probably now with a feeling of "why didn't I help?"

Sad when people see no other way out than suicide.

<comment><USER5> That's not what I meant. I meant in the USA there is a culture of shooting a place up when you're depressed. Fortunately that did not happen, that's all I meant. I've had friends kill themselves. I've battled with depression and I've seen someone die in a horrific car accident right in front of me.

<comment><USER7> School shooters don't fit a single profile. Some of them are well liked and popular like Jaylen Fryberg and the perpetrators of Columbine were bullies themselves rather than being victims of school bullying.

</comment></comment></comment></comment><comment><USER8> Flagged, because I think it's irresponsible to include the method in the headline.

</comment><comment><USER9> Still below the national / global average. I see nothing newsworthy here, just a very sad story.

<comment><USER10> Setting aside the fact that counting tragedies is kinda in bad taste, I think it's relevant to point at a past exemple:

"French" company Orange, who has around 100K employees, got into national trouble for a "wave" of suicide that counted in the thenths. [1]

The company's french boss got terrible press by calling the series of event a "mode des suicide" (roughly translatable as "suicide fad" or "suicide fashion").

The events highlighted "structural" managerial problems at the company.

FB has around ~20k employees, so that might affect the "newsworthyness ratio".

It is obviously too early to know if the situation at Facebook is comparable to Orange.

I would not be surprised at all, if the narative of "Facebook badly treats is employed" gets popular. FB already has a rather bad rep.

Facebook top management had better handle this thoughfully - if only, by pure human decency.

[1]: [https://theguardian.com/business/2014/mar/19/orange- france-i...](https://theguardian.com/business/2014/mar/19/orange-france- investigates-second-wave-suicides)

<comment><USER11> France has an average suicide rate of 12 over 100,000 per year.

A company with 100K employees and over 20 suicides per year, is concerning.</comment></comment></comment>


Ask HN:Harvard Business Review Case studies worth reading - <AUTHOR>

I just subscribed to HBR and in generaly, looking through the treasure trove of case studies and articles on HBR (recent discovery for me :( ).<p>Are there any case studies/compilations that you folks would particularly recommend? Startup/product related would be nice but just anything interesting/insightful would be good <comment><USER2> Four I read recently that I recommend:

Darwin and the demon: innovating within established businesses. 82(7/8). 86-92.

Blue Ocean Strategy. October. 76-84.

Take command of your growth.April. 127-133.

Growth outside the core. December. 66- 73.</comment>


Show HN: Shishua – Fast pseudo-random generator - <AUTHOR> https://espadrine.github.io/blog/posts/shishua-the-fastest-prng-in-the-world.html <comment><USER2> The design approach of just iterating until it passes a suite of statistical tests is ... not the best.

The issue is that the common suites of statistical test don't include every credible statistical test at their level of complexity.

Essentially as you retry against the tests you expend their utility, producing a result that is guaranteed to pass them as a byproduct of your process. ... but may in fact be extraordinarily weak to yet another reasonable statistical test (and/or broken in some practical application) that no one has yet thought to include in the test suite.

<comment><AUTHOR> Very true. Sadly, this is the main approach the non-cryptographic PRNG community has at the moment.

On the plus side, those tests are fairly extensive and brutal nowadays. They detect anomalies in cryptographic algorithms that were still used a decade ago, such as arc4random().

But one thing I hint at at the end is that I hope, and anticipate, to see more accurate quality measurement tools in the future.

<comment><USER3> A partial workaround is to reserve one or two of the tests until your PRNG passes the others.

If it passes the remainder on the first try, you might be on to something.

If it fails, you've got a problem: tweaking until it passes isn't going to help you.

</comment></comment></comment><comment><USER4> > Indeed, AVX2 has a bit of a quirk where regular registers (%rax and the > like) cannot directly be transfered to the SIMD ones with a MOV; it must go > through RAM (typically the stack), which costs both latency and two CPU > instructions (MOV to the stack, VMOV from the stack).

I don't think this is quite correct. You can move efficiently from r64 to XMM/YMM without going through memory with MOVQ/_mm_cvtsi64_si128. I'm not able to look into it more closely right now, but these links should give insight:

[https://www.felixcloutier.com/x86/movd:movq](https://www.felixcloutier.com/x86/movd:movq)

[https://software.intel.com/sites/landingpage/IntrinsicsGuide...](https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=movq&expand=1885)

My vague recollection is that you might be right that this is clumsy with AVX2. Maybe it's a case where you have to take advantage of the fact that XMM1 and YMM1 are same register, and cast the YMM to XMM? Or just drop to inline assembly.

But thanks for the writeup, and I hope to be able to look at Shishua more closely at some point in the future.

<comment><USER5> Yes, most instructions that modify only the bottom element(s) didn't get a ymm (256-bit) version since it would serve no purpose as it would produce the same result as the xmm one, and the corresponding intrinsics mostly follow the same pattern. So there is no int64 -> ymm intrinsic.

An intrinsic cast works fine though:

[https://godbolt.org/z/M9XWCb](https://godbolt.org/z/M9XWCb)

Intel even says about the cast:

> Cast vector of type __m128i to type __m256i; the upper 128 bits of the > result are undefined. This intrinsic is only used for compilation and does > not generate any instructions, thus it has zero latency.

That seems a bit beyond their mandate since what the compilers generate is mostly up to them, and in fact it doesn't seem true: at -O0, both gcc and clang generate a few extra instructions for the cast. With optimization on, it's all good though.

</comment></comment><comment><USER6> If you need something fast and with stronger security guarantees, Google Randen remains a solid choice. [https://github.com/google/randen](https://github.com/google/randen)

<comment><USER7> The article mentions Randen is slower than ChaCha8.

<comment><USER8> Where? CTRL-F Randen doesn't show anything, and the Randen repo claims it's faster than ChaCha8.

<comment><AUTHOR> It is not directly in the article, but in a link to a tweet by djb, the creator of ChaCha8. He believes that the cpb listed in the Randen comparison is off:

[https://twitter.com/hashbreaker/status/1023965175219728386](https://twitter.com/hashbreaker/status/1023965175219728386)

He mentions that perhaps the implementation of ChaCha8 for the benchmark is done by hand and unoptimized. And it is true from what I saw that a lot of benchmarks with ChaCha8 are implemented with none of the tweaks that make it fast.

In this instance, it looks like the Randen author didn't reimplement it from scratch, but they used an SSE implementation, not an AVX2 one, which would have been faster: [https://github.com/google/randen/blob/1365a91bafc04ba491ce79...](https://github.com/google/randen/blob/1365a91bafc04ba491ce79b88968744726225cf1/engine_chacha.h)

</comment></comment></comment></comment><comment><USER9> This looked ugly and so much out of place...

> Or, as Pearson puts it:

> From this it will be more than ever evident how little chance had to do with > the results of the Monte Carlo roulette in July 1892.

> (Not sure why his academic paper suddenly becomes so specific; maybe he had > a gambling problem on top of being a well-known racist.)

<comment><USER10> i found it quite funny. And I don't really find calling a well know eugenics advocate racist to be even remotely provoking. Maybe out of style compared to the rest of the text, but apart from that I didn't find it conspicuous in the least.

</comment></comment><comment><USER11> > One of the not-ideal aspects of the design is that SHISHUA is not > reversible.

Why is irreversibility a bad thing? Is it just the loss of useful state which reduces the internal entropy?

Is irreversibility ever useful? Wouldn't some amount of discarded bits make it harder for an adversary to infer the state?

<comment><USER12> CSRNGs are mentioned a few times in TFA, but cryptographic security doesn't appear to be among the design criteria for SHISHUA. There's no mention of linear or differential crpytanalisis, which is table stakes for a CSPRNG.

<comment><AUTHOR> I added a warning in the GitHub's Readme. SHISHUA is not to be used for cryptographic purposes.

You mentioned the lack of cryptanalysis; there is also the lack of rounds (which prevents researchers from breaking partial versions to ease their study, and allows setting a security margin).

</comment></comment></comment><comment><USER13> What is a real world use case where CSPRNGs are too slow on modern hardware?

<comment><USER14> Shuffling 100 million points per second (probably much more if it wasn't both, disc IO and CPU->GPU transfer limited), and shuffling in general if you want to maintain high throughput. e.g.: [https://bit.ly/2zcUzJq](https://bit.ly/2zcUzJq)

</comment></comment><comment><USER15> This is not a bad thing, and maybe I'm alone in this, but I spent my first minute thinking over whether "Shishua" was some kind of romanized mandarin or mandarin-esque word!

(I speak cantonese, though, so maybe mandarin speakers wouldn't fall in this trap)

<comment><USER16> It's a "stone brush" 石刷 _shíshuā_. (Alternatively "It's a number!" 是数啊 _shì shù a_ , but then pinyin orthography requires writing it as "Shishu'a" with an apostrophe in front of the third syllable.)

</comment></comment><comment><USER17> Will everyone soon be using Shishua then? (I don't know much about PRNGs.)

<comment><AUTHOR> Good question.

SHISHUA is a strong design, suitable for many use-cases. But the decision of which PRNG is right for you depends on platform, context, comfort, and ease of access.

If you are making a simple video game, it might be fine to just use your standard library; or to write one of the simple ones that you memorized and that don't have too terrible an output.

If your video game has more severe stakes, if it is the backbone of a virtual economy in a massively multiplayer game where servers feed on a large amount of randomness that needs high quality to ensure players don't find flaws and abuse the system for their own gain, maybe SHISHUA is right for you.

If you are targeting a platform that does not support 64-bit computation, SHISHUA can't do it well, and other PRNGs such as sfc32 can be good there.

If you are working on machine learning that feeds on heaps of randomness over the course of months of computation, and that need quality to ensure an unbiased, even learning, SHISHUA can be right for you.

There was a neat article recently that contrasted a large number of PRNGs for use on video games, in particular on consoles: [https://rhet.dev/wheel/rng- battle-royale-47-prngs-9-consoles...](https://rhet.dev/wheel/rng-battle- royale-47-prngs-9-consoles/)

It is before the publication of SHISHUA, but the insights there are interesting.

<comment><USER18> I couldnt find the license? Is this MIT

<comment><AUTHOR> CC0 it is! I added the legal information in the GitHub project.</comment></comment></comment></comment>


Show HN: Watercooler Questions – super effective team building (just 30 sec/wk) - <AUTHOR> https://www.trytape.com/watercooler <comment><AUTHOR> Author here. Let me know if you have any questions or suggestions…

Our team built a visual communication tool (think video stories for workplace communication) and one of the surprisingly effective ways one of our pilot customers began using the tool was as a quick team builder. Someone would send out a really simple question over video and teammates would respond on Tape. Simple questions like "What was the last country you visited" turned into easy ways for people to discover they had overlapping interests/experiences.

The experience was way more effective than expensive happy hours or offsites which are nice but generally just let friends at work hangout with each other rather than building new connections. The only problem was it required everyone to download our mobile app ([https://www.trytape.com/app](https://www.trytape.com/app)) and someone had to come up with a question every week. Because of that, we decided to devote a quick sprint to productizing the interaction and make it dead simple for any team to take part in the program.

Watercooler Questions:

      - No app installation required (done 100% through email/web)
      - Fully automated (we send your team a new question every week)
      - Super effective and time efficient (Spend just 30 sec a week answering a question and learn more about your teammates)

Check out a fun example here: [https://www.trytape.com/t/E1efYE42xr10](https://www.trytape.com/t/E1efYE42xr10)

Looking forward to on-boarding more teams and continuing to iterate on it. Excited to hear feedback!</comment>


Linux kernel in-tree Rust support - <AUTHOR> https://email@example.com/T/#u <comment><USER2> Rust in Linux will be fantastic _except_ for compile time. Rust (and the world) needs a Manhattan Project to build a fast Rust compiler (where by "fast" I mean both efficient and scalably parallel when compiling a workspace with many crates and long dependency chains).

To put this in perspective, though: increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people. Compared to the size of the projects that are starting to depend on Rust, that's a rounding error.

<comment><USER3> GCC 10 supports Dlang directly. (The support is still immature and it's being updated to the newer version of Dlang.)

Dlang compiles quickly not because the language is simple, but because the compiler authors care about compilation speed:

Lexer skips four spaces at once [https://github.com/dlang/dmd/pull/11095](https://github.com/dlang/dmd/pull/11095)

Optimize core logic to 7x compilation speed of language feature [https://github.com/dlang/dmd/pull/11303](https://github.com/dlang/dmd/pull/11303)

Cache rarely used types to improve memory locality [https://github.com/dlang/dmd/pull/11363](https://github.com/dlang/dmd/pull/11363)

<comment><USER4> The D language uses GC, so it's unlikely to be acceptable for the Linux kernel. (That's not to say that you can't write a kernel in D, just that the Linux kernel maintainers don't want to write a kernel that requires GC.)

Rust's ownership model, which allows you to write straightforward, non-leaky, non-use-after-free-filled code without a GC, is quite complex at compile time. It's definitely possible to make it faster, but it's definitely a thing Rust does that D doesn't do.

<comment><USER5> D has a nogc flag that can be used on methods and taints methods down the line. It's pretty neat. I'm a big fan of D, but I still think I wouldn't write a Kernel in D. I find it much more suited to quicker smaller programs, kind of like Python but with better typing. The script support for D is also really neat, and I've used that instead of Perl a few times.

</comment></comment></comment></comment><comment><USER6> These threads always devolve into "rust is too slow" written by developers (or enthusiasts) that have never written no_std code in production. I've written and shipped firmware for embedded devices written in rust, yes, still using cargo and external crates, and had zero issues with compile time because the nature of the dependencies in the deps tree is different and very carefully curated.

Anyway, I really just wanted to point out that from the mailing list we have Linus and Greg endorsing this experiment/effort from the Linux side and a commitment from Josh on behalf of the rust team to grow the language itself with the needs of the kernel in mind. That's quite impressive and more than I could have hoped for.

I've actually played with writing kernel code in rust - for Windows/NT, however - and it's quite weird to be able to use such high-level type constructs in code where you typically manually chases pointers and wouldn't be surprised to see statically allocated global variables used to monitor reference counts.

<comment><USER7> Linus, normally being C has its quirks but is great and Anti C++ in general is endorsing Rust?

Why is that? Did he ever gave out his reasons?

<comment><USER4> I don't know Linus's reasons specifically, but our presentation at Linux Security Summit last year laid out why we think that Linus's past objections to C++ don't apply to Rust. See slides 19-21 of [https://ldpreload.com/p/kernel-modules-in-rust- lssna2019.pdf](https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf) .

His previous objections were:

        In fact, in Linux we did try C++ once already, back in 1992.

        It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

        The fact is, C++ compilers are not trustworthy. They were even worse in
        1992, but some fundamental facts haven't changed:

         - the whole C++ exception handling thing is fundamentally broken. It's
           _especially_ broken for kernels.
         - any compiler or language that likes to hide things like memory
           allocations behind your back just isn't a good choice for a kernel.
         - you can write object-oriented code (useful for filesystems etc) in C,
           _without_ the crap that is C++.

In brief, Rust does not rely on C++-style exception handling/unwinding, it does not do memory allocations behind your back, and its OO model is closer to the existing kernel OO implementation in C than it is to C++'s model. (There are other good safe languages besides Rust that I personally like in _general_ but do not satisfy these constraints for this particular use case.)

<comment><USER8> How do you write OO code in C?

<comment> amw-zero This is a really in depth read about OO design patterns in the Linux Kernel using C: [https://lwn.net/Articles/444910/](https://lwn.net/Articles/444910/)

The easiest to understand example (for me) is that you can manually implement polymorphism support using function pointers that take in a struct instance as an argument. Polymorphism is fundamentally just a method call that's dependent on which target object it's being called on, so this pattern allows you to pass in the target object (as a struct since it's C) explicitly.

From the article:

> Some simple examples of this in the Linux kernel are the > file_lock_operations structure which contains two function pointers each of > which take a pointer to a struct file_lock, and the seq_operations vtable > which contains four function pointers which each operate on a struct > seq_file.

<comment><USER9> The huge and important difference is when you use this pattern in C the compiler has no idea what you are doing and can't check anything, nor can it reduce the cost of this dispatch mechanism. A compiler for a language where this is a feature can check what you are doing and de-virtualize virtual dispatch. In C you pay the highest possible cost for polymorphism while enjoying the least benefits.

<comment><USER10> > The huge and important difference is when you use this pattern in C the > compiler has no idea what you are doing and can't check anything

Function pointers exist in C and are type-checked by the compiler just fine.

> A compiler for a language where this is a feature can check what you are > doing and de-virtualize virtual dispatch.

Virtual dispatch is pretty much only used in the kernel in places where virtualization is necessary. Devirtualization is pretty rare in C++ in practice (I don't believe I've ever seen a "virtual final" method, and my day job is on a large C/C++ codebase).

<comment><USER11> You don't need "virtual final" for devirtualization, the compiler will speculatively devirtualize in some cases.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> The title is not very accurate, this is a thread about a discussion on this topic which will happen at the upcoming Linux Plumbers Conference in late August.

<comment><USER13> The title is perfectly accurate, it's an email thread about Linux kernel in- tree Rust support. Sure, you could misconstrue such a title to be implying that the Linux kernel supports Rust in-tree already it if you wanted to, but half the titles on a site like this could be similarly misconstrued.

<comment><USER14> > The title is perfectly accurate, it's an email thread about Linux kernel in- > tree Rust support.

The title the person you are responding to is complaining about is not the title of a email thread but the title of a hacker news post.

<comment><USER13> Unless there's a strong reason not to, the Hacker News post title should match the email thread title. It does match, and I see no even _slightly_ compelling reason for it to deviate.

</comment></comment></comment></comment><comment><USER15> Immunant folks wrote a blog post [1] about automating conversion of Linux kernel drivers from C to Rust by using their tool c2rust[2].

[1] [https://immunant.com/blog/2020/06/kernel_modules/](https://immunant.com/blog/2020/06/kernel_modules/)

[2] [https://github.com/immunant/c2rust](https://github.com/immunant/c2rust)

<comment> yjftsjthsd-h I don't see them discussing what I view as the biggest question of such conversion: is the converted code safer than C, or is it a direct translation with all the issues that we were trying to fix by using Rust? (This came up, IIRC, with automatic C to Go; it _worked_ , but was only useful as a first step because it gave you unsafe unidiomatic Go code)

<comment><USER16> It is currently a direct translation into unsafe.

They are also interested in "unsafe to safe refactoring tools" in my understanding, but they're not there yet.

<comment><USER15> There is a good refactoring tool[1][2] to automate the process. It also allows scripting in Lua[3].

[1] [https://github.com/immunant/c2rust/tree/master/c2rust- refact...](https://github.com/immunant/c2rust/tree/master/c2rust-refactor)

[2] [https://c2rust.com/manual/c2rust- refactor/commands.html](https://c2rust.com/manual/c2rust- refactor/commands.html)

[3] [https://c2rust.com/manual/c2rust- refactor/doc/scripting_api....](https://c2rust.com/manual/c2rust- refactor/doc/scripting_api.html)

<comment><USER16> Oh awesome! Thank you!

</comment></comment></comment></comment></comment><comment><USER17> Pleasantly surprised by Linus response. IIRC his attitude to C++ was that it should be refused if only to keep C++ programmers out.

<comment><USER18> His attitude towards C++ also changed when using it for his side project [1].

Initially he started with C and GTK+ and later migrated to C++ and QT Framework.

[1] [https://subsurface-divelog.org/](https://subsurface-divelog.org/)

<comment> globular-toast Did he have an "attitude" about C++ in general? I thought he only commented on it with respect to operating system development. He did make much more general statements about Java, though.

<comment><USER19> I thought the famous comment on C++ was in the context of git, not operation systems?

</comment></comment></comment></comment><comment><USER20> So this surprises me, obviously this is early discussion about a potential topic, but the general consensus seemed to be more positive than I thought.

I thought I'd remembered reading something (maybe from linus) that seemed very against having rust in the kernel, can anyone find a source for that, I searched a little and can't?

(caveat, I obviously realise that linus isn't supporting rust in the kernel, and is only saying something bounded that, if we have it, it shouldn't be completely hidden behind some config options, but it doesn't match my memory)

<comment><USER21> Maybe you're remembering Theo's comments about Rust in OpenBSD?

[https://marc.info/?l=openbsd- misc&m=151233345723889&w=2](https://marc.info/?l=openbsd- misc&m=151233345723889&w=2)

<comment><USER22> The sad part is that Theo's answer on the thread seems to be one of the most polite and realistic ones

<comment><USER23> This was interesting to read:

> Such ecosystems [Rust] come with incredible costs. For instance, rust cannot > even compile itself on i386 at present time because it exhausts the address > space.

<comment><USER24> But is that a huge issue? One could compile on better machine with i386 target, no?

<comment><USER23> According to the link above, in openbsd the policy is that 'base builds base'. Rust can't be included in the base on i386 without violation of that policy.

<comment><USER25> And this is a reasonable and understandable policy. It just means that Rust in it's current form is not a good fit for OpenBSD base system.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Just stating something obvious since I don't see it noted here: Linus is a smart guy with this idea of not wanting it to be some niche feature that nobody enables and hence nobody cares about and sees breakage from.

<comment><USER27> I think what he did has nothing to do with smart. it's experience that matters here, he learned such stuff, sometimes even on the hard way.

<comment><USER26> The smarts, I guess, is in recognizing which pieces need this treatment and which do not.

Also, he is suggesting this change to experienced people who did not do it that way. So experience is not 100%.

</comment></comment></comment><comment><USER28> I always find these email threads very hard to follow, specially on mobile.

Is there anyway to have them shown more friendly?

<comment><USER29> Firefox reader mode seems to do a decent job

<comment><USER30> It is also a blessing for paywalled news sites.

</comment></comment></comment><comment><USER31> 6 months ago, as I hopped on the Rust train, I told a friend of mine that I'm convinced that Rust will "eat the world" like Python did[0]. These moves to see Rust enter the Linux kernel only prove to me that this pace is starting to pick up.

0\. [https://www.techrepublic.com/article/python-is-eating-the- wo...](https://www.techrepublic.com/article/python-is-eating-the-world-how- one-developers-side-project-became-the-hottest-programming-language-on-the- planet/)

<comment><USER32> This is a deeply weird comparison.

Insufferably lazy "eating the world" headline aside, Python is incredibly popular because its runtime performance is "good enough" for a huge fraction of applications, its safety guarantees are leagues better than C/C++, and it's deliberately simple to write (it was designed in part as a pedagogical language).

Rust's performance is leagues better than Python's, it's safety guarantees are better by degrees, and it is _substantially_ harder to write than Python, not just because it requires a more sophisticated understanding how how programs are constructed and verified, but also because it requires developers to think carefully about memory management.

I fully expect Rust to "eat the world" of C/C++ code over the next 10 years, and look forward to a time where we'll look askance at kernel code still written in C. It will no doubt be important in a bunch of performance-critical settings (AAA gaming, browsers, network infrastructure) as well.

But Rust will never "eat the world" of general applications (that is, the overwhelming majority of applications), because Python is good enough across all axes for these applications. It would be engineering malpractice for most companies to rewrite working Python applications in Rust. That was not the case for C-to-Python (or even PHP-to-Python) rewrites.

In case this isn't obvious to anyone reading this thread --- though I'd be surprised --- the reason Rust is in the Linux kernel, while Python isn't, is that Rust was designed to be interoperable with kernels and browsers, and Python, like most other languages that have ambitious runtimes, was not. It's not an indication of Rust's popularity, but rather just Rust doing something it was designed to do.

(Rust is plenty popular.)

<comment><USER33> > Python is incredibly popular because its runtime performance is "good > enough" for a huge fraction of applications

Is there anything slower than pure python?

<comment><USER34> Interpreted BASIC, of which (in my opinion) Python is the spiritual successor.

I took an online class in college on Python and one of the assignments required the program to scan a plaintext wordlist for a word. I hesitantly made Python load in the entire wordlist and split it by newlines into values in a list, before something like "if word in wordlist". I fully expected my computer to grind to a halt because the _interpreted language_ was loading in a four _megabyte_ textfile, and I expected to have to make a much more complicated function to scan to see whether the word was in the list. I ran it and it ran in less than a second before printing whatever I put to signal that it worked. I didn't believe it so I ran it again with the same result.

Python is like BASIC if it was stable enough to be mission-critical and fast enough to work where it needs to. My previous experience with interpreted languages was with TI-BASIC and it blew my mind that my laptop was powerful enough to do something that fast. Sure, it's slow, but if you really need speed you're better off writing something in something like C or FORTRAN (or Rust now) anyway.

</comment></comment></comment></comment><comment><USER12> Assuming this happened and some essential drivers were written in Rust, would this effectively exclude GCC from being used to compile the full kernel?

<comment><USER35> GCC can still compile the components written in C. Only drivers for select hardware might be written in Rust in the future, optional components basically. And GCC won't be more disadvantaged than clang, as clang can't compile Rust code either. The only production compiler that can compile Rust is rustc.

<comment><USER12> rustc uses LLVM like clang. That seems important because features like LTO require the whole kernel to be compiled with the same toolchain.

<comment><USER35> It seems to me there isn't mainline LTO support yet?

<comment><USER36> Work in progress. The series was resent two weeks so. We've been shipping it in production in kernels in Android for years.

</comment></comment></comment></comment></comment><comment><USER37> So I don't know much about kernel development.

How many other languages apart from C are there in the kernel?

<comment><USER38> I'm a bit uninformed as well. Obviously it must use assembly in some places, it has makefiles for building and some scripts in perl. Here's what a cloc clone has to say.

        tokei
        </comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
        Language            Files        Lines         Code     Comments       Blanks
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
        ASN.1                  11          484          343           33          108
        Assembly                3         2751         2450            0          301
        GNU Style Assembly   1296       370153       270691        56418        43044
        Autoconf                6          347          303           20           24
        Automake                3           31           23            3            5
        BASH                   54         1991         1438          321          232
        C                   28971     19846129     14634535      2351170      2860424
        C Header            21110      6056898      4465297      1010398       581203
        C++                     8         2313         2016           68          229
        C++ Header              2          125           59           55           11
        CSS                     1          137           80           29           28
        Device Tree          3351       900862       735380        54238       111244
        Gherkin (Cucumber)      1          252          174           50           28
        Happy                   9         5750         5061            0          689
        HEX                     1           86           86            0            0
        INI                     1            7            3            3            1
        JSON                  328       174872       174872            0            0
        LD Script              15          412          317           48           47
        Makefile             2587        64666        43896        10957         9813
        Module-Definition       2          124          109            0           15
        Perl                   53        40583        31126         3931         5526
        Python                118        36932        29072         2980         4880
        ReStructuredText     2621       548840       417105            0       131735
        Ruby                    1           29           25            0            4
        Shell                 556        85666        59725        10972        14969
        SVG                    59        39038        37555         1405           78
        Plain Text           3230       239573            0       197373        42200
        Unreal Script           5          716          446          162          108
        Vim script              1           42           33            6            3
        XSL                    15          300          183           78           39
        YAML                  921        91167        72962         3985        14220
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
        Total               65340     28511276     20985365      3704703      3821208
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=

<comment><USER39> The Unreal Script is for the new 3D menuconfig ;)

<comment><USER35> Someone should replace that with GDscript.

</comment></comment></comment><comment><USER40> what does linux kernel in-tree support mean? that drivers can be written in rust or something?

<comment><USER36> Yes. In tree means their sources are in the Linux kernel git repository, as opposed to out of tree drivers. In tree drivers are maintained by the maintainers, so API changes are done together for all in tree drivers. Out of tree drivers don't get this benefit, and are more difficult to build in my experience.

<comment><USER40> thank you!

</comment></comment></comment><comment><USER41> Tangential question: what would be a career path for a typical product developer to become one of the programming gods who get invited to such discussions? (Even if it's technically open mailing list, you know what I mean). How many years of experience and how much formal CS education would it take to acsend to that level?

<comment><USER42> Formal CS education is pretty much useless for systems programming. Systems programming deals with real-world hardware, CS is theorizing about about fantasy machines. "Computers are to Computer Science what telescopes are to Astronomy." They're just different fields. They intersect, of course, but systems programming isn't very near that intersection. Being good at analyzing a DFA on a Turing machine isn't going to be much help when you need to bang bits to a non-compliant USB device.

If you want to get into these discussions, you need to be a kernel dev. That means you need to write kernel stuff. Probably the easiest thing is to write or improve a driver for some device you have (game controllers; steering wheels; audio devices; drawing tablets). It's not rocket science, it's all just bits and bytes and code, just like any other programming.

Edit: Just for an example, here's where the PlayStation controller driver parses the data it gets from the device into something applications can read over the input subsystem. Don't be intimidated, there's nothing magic here, just C code reading data and transforming it. Suppose you maintained this driver and wanted to re-write it in Rust. You could have some input into the discussion! [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid- sony.c#n940)

<comment><USER43> Except many universities don't teach CS like that, I guess that might be an US thing.

In the Portuguese university where I took my degree, for example, I had to write an UNIX floppy device driver, code in 80x86 and MIPS Assembly, implement my own userspace threading library, implement a distributed algorithm for maldebrot calculations across a Linux cluster via PWM (MPI predecessor) and report its scalability varying the amount of available machines on the cluster, create a compiler, stuff SUN RPC generated stubs with our own encryption algorithm, implement a B+Tree indexing library using inodes directly.

All look pretty useful to me.

<comment><USER7> And How long ago was that? :)

I would assume most CS in EU dont teach that anymore.

<comment><USER43> Mid-90's, so around 30 years ago.

My former university surely does it, although obviously not with the same exact content.

[https://www.di.fct.unl.pt/en/education/integrated-master- com...](https://www.di.fct.unl.pt/en/education/integrated-master-computer- science/study-program)

</comment></comment></comment></comment></comment><comment><USER44> The problem I perceive with Rust as a language for Linux, is not that Rust is not an excellent language. It is that it evolves rather quickly and code may break when you switch versions.

</comment><comment><USER45> Does rust/llvm even support all the CPU architectures Linux supports?

If not how will that work? Will some drivers be then limited to only some architectures?

<comment><USER36> No, but it's already the case that some drivers are already tightly coupled to an architecture. Does it make sense to build a driver for some internal piece of hardware from an ARM SoC for PPC? Generally, no.

<comment><USER45> The kernel contains vast number of drivers that are for universal buses like I2C, SPI, USB, PCI(e), SDIO, UART, writing any of these in rust would make these drivers unavailable to architectures unsupported by llvm. I think that would be quite sad.

<comment><USER36> Right. I don't think anyone is proposing ReWrItE iT iN rUsT. There's way way more drivers that aren't buses (platforms) that don't need the level of portability we're talking about.

<comment><USER45> I'm not talking about buses, but regular drivers for devices on those buses. The buses are universal, that means that they can be supported on any architecture, so drivers for devices on those busses should not be limited to any single arch just by the choice of the language.

</comment></comment></comment></comment></comment><comment><USER46> While I like Rust I still picked Modern C++(17) for my next project. All modern languages are converging these days.

Adopted C++ because of its libraries at large. Will still learn Rust on the side. For the moment, boring and verified for product especially when they're updating and remaining up to date.

</comment><comment><USER47> To bootstrap Rustc you have to compile every single version. Say goodbye to reproducible builds. Say goodbye to civilians with cheap laptops being able to compile their kernel.

<comment><USER48> This is a strawman argument. To be reminded of what it takes to truly "bootstrap" a C compiler, I recommend everyone to read Ken Thompson's Turing Award lecture "Reflections on Trusting Trust".

<comment><USER47> gcc can still be bootstraped from just an assembler and linker[1] with very few binaries you have to trust and it is possible on comoddity hardware. Bootstrapping Rust is so difficult that adding it to Linux would for all purposes eliminate this feature (being able to be built completely from source) from Linux, probably leading to a fork of Linux without Rust for those that care about it.

[1] [https://guix.gnu.org/manual/en/html_node/Reduced-Binary- Seed...](https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed- Bootstrap.html)

<comment><USER16> mrustc can shorten that bootstrap, and also, many Linux distros already ship a rustc that they've bootstrapped as far back as they thought prudent. So yes, I can see some folks doing something like this, but I doubt that the major distros would.

</comment></comment></comment></comment><comment><USER49> Happy to see happening!

But to get the most value out of Rust, one needs to use the Cargo ecosystem too (even for kernel code!) and that will be a much bigger political quagmire.

<comment><USER4> We've got Cargo wired up in our prototype, which can let you link modules against no_std crates on crates.io: [https://github.com/fishinabarrel/linux- kernel-module-rust](https://github.com/fishinabarrel/linux-kernel-module-rust)

Probably one good end state is if the core kernel exposes appropriate safe abstractions, and vendors with out-of-tree modules (which tend to be worse at security than the main kernel) could use those APIs + things from crates.io to build their modules.

But yes, figuring out how to use useful things that aren't in libcore is one of the open questions.

<comment><USER49> Glad to hear it! I just hope Linux doesn't end up with the crates.io vendoring nightmare that the big-corps made for themselves.

</comment></comment></comment><comment><USER50> My only complaint about Rust is terminology.

"Immutable variable" what an oxymoron!

That's what is known as a constant!

A variable is mutable, a constant is not. Was it that hard to understand?

</comment><comment><USER51> Hmm... Might be time to start looking into Rust. Is it popular in college? I think that's what made Python displace Java.

EDIT: lol. Decided to dive in a hit this almost immediately: [https://docs.rust-embedded.org/book/start/io.html](https://docs.rust- embedded.org/book/start/io.html)

<comment><USER42> That's the guide to embedded programming. If you're just looking to learn Rust, start here: [https://doc.rust-lang.org/book/](https://doc.rust- lang.org/book/)

</comment></comment><comment><USER52> Hopefully this will not pass - The requirement of having GCC + LLVM + Rust installed in order to build kernel would be insane.

<comment><USER53> As someone new to the dev party who has never built anything more lower level than a win32 exe, may I ask why that's insane?

Adding 1000 npm dependencies, I see. Adding 1 rustc one? Doesn't SEEM terrible.

<comment> yjftsjthsd-h We only just got to a point where 2 C compilers could build Linux; adding rustc brings us back to a monoculture.

<comment><USER54> It sounds like you're saying that you should never use any programming language until it's supported by at least 2 compilers. Is that accurate?

<comment><USER55> Without a language specification for Rust, any compiler that isn't the reference implementation, by definition, cannot be correct. Put another way, how is a compiler writer supposed to know what is and is not a bug in the reference implementation?

<comment><USER16> Most languages do not have a specification, and it works out fine.

Rust's is in-progress. There are some things that are well-specified, and there are some things that are still up in the air.

<comment><USER56> Right, which is why it's a poor choice for the kernel at this time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER57> Now there is no legitimate reason to lock out C++.

<comment><USER58> There are plenty of reasons. As just one of them: C++ is unsafe by default. There's theoretically a safe subset, but there's no precise or consensus definition of that subset. There's no type-system or language support for helping you stay strictly within that subset (and requiring some kind of marker for if you don't). Often, the most obvious way of doing something is unsafe; for instance, in C++, arr[i] is unsafe, and you have to write arr.get(i) to be safe. (In Rust, arr[i] and arr.get(i) are both safe, and you have to write arr.get_unchecked(i) in an unsafe block if you truly want an unsafe indexing operation.)

<comment><USER32> Can you help me understand why locking C++ out of a kernel written almost entirely in C, and which receives huge volumes of new C code every year, wouldn't be an instance of making the perfect the enemy of the somewhat marginally better?

<comment><USER59> Here [1] is one of Linus's more well-known rants about C++. It's in reference to the Git source, but I think most of it applies to his attitude towards using C++ in the kernel as well.

[1] [http://harmful.cat-v.org/software/c++/linus](http://harmful.cat-v.org/software/c++/linus)

<comment><USER32> Just to be clear, I don't know that anyone in this subthread likes C++. I stopped writing in it in 2003 and I'm glad to be done with it. (I still adore C).

</comment></comment></comment></comment></comment><comment><USER60> I have a hard time seeing this happen. Rust has most of the same properties which prevent C++'s inclusion in-tree. (Look up Linus' opinions on C++ if you aren't already familiar.)

Further, as far as I can tell, Rust currently lacks mainline GCC support which I believe will be a blocker.

<comment><USER61> The thing is the kernel is kinda hurting for maintainers and opening up the path for the next generation of systems programmers (most of whom don't want to touch C any more than they have to) has to be something Linus is more likely to prioritize than in previous decades.

<comment><USER62> How would requiring learning Rust, which is famously difficult, be the solution to that problem?

<comment><USER63> Writing safe C and C++ is even much more difficult than writing Rust code (especially with many developers). And when you are writing kernel code, both safety and performance are crucial.

<comment><USER62> The problem seems to be to find people who do not just want to write code, but do the administrative parts:

"We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have."

<comment><USER64> Finding people willing to review rust must be much easier than finding someone willing to review c.

<comment><USER63> Actually I think the answer is yes, as Rust is much stricter to the person who's contributing the code. If I was asked to review another person's code, I would much prefer reviewing Rust code, as I would be able to concentrate on the logic and the efficiency of the code instead of potential low level mistakes.

The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference counters, or dynamic behaviour, which is very easy to search for.

<comment><USER65> Is reference counters really a smell? I thought it was the main way to write Rust when the borrow checker is too strict for something you want to do.

Vec + generational indices might be the other way, is that preferred over Rc?

<comment><USER63> ,,when the borrow checker is too strict for something you want to do''

Most of the times it isn't. Just as an example here's a random part of serde, the high quality serialization library in Rust:

[https://github.com/serde- rs/serde/blob/master/serde/src/priv...](https://github.com/serde- rs/serde/blob/master/serde/src/private/de.rs)

The amount of extra automatic memory management is often a good indicator of not well thought out data structures (although of course they are not always needed).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER66> Formal leaning HN people: Does Rust just have better sales & marketing than C++? Or is it really better for safety and correctness?

* Rust is NOT a programming language with deep, well-integrated support for proof systems or state exploration e.g. TLA+.

* Rust is no Frama-C where static analysis and function contract support is far more apparent and important

* Rust is not ADA

* The previous items also arise and are quite important as a direct result of generality: to the extent Rust imposes (albeit with benefit) language design to avoid certain kinds of functional issues, those features can later become limitations as a pushy, over opinionated language. Therefore to have flexibility in designing fast code that's yet correct code one usually has to have the low-level ability of C/C++ augmented with formal tools.

I'm not seeing Rust do that. Now, I've made a couple of jokes elsewhere in HN about Rust's propensity to show up uninvited to every vaguely language issue and press its case --- ex. I was vacuuming the floor yesterday when Rust somehow got through the front door and was explaining how a Rust vacuum is so much better, or how I'd never need to vacuum again if I used Rust. But I am only half joking.

For the last year I've spent much of my time in GO after getting sick-and- tired of C++ build/language complexity for the previous 10+ years. I am somewhat aligned to others who rightly ask if speed is all that matters? (Recall the Meyers joke about Pavlov training and C/C++ programmers when it comes to speed).

Correctness counts too and if the compiler spends a little bit more I time I'd be fine with that if for distributed/parallel programming I've got good guarantees.

For those who use TLA, SPIN, Frama-C and other formal tools what's your take on this? I think designers of those kinds of formal tools will be surprised to learn some of their correctness aims were solved by Rust.

<comment><USER2> Rust makes it easy to write code that's very expressive (dynamic memory allocation etc) and has strong safety properties. Certainly easier than having to verify with SPARK or Frama-C. Rust's type system, especially traits and affine types, lets you encode a lot of important properties (e.g. typestates).

Rust does need tools to verify Rust code correctness and especially to verify unsafe Rust code. There is a lot of work going on in this area: see [https://alastairreid.github.io/rust-verification- tools/](https://alastairreid.github.io/rust-verification-tools/) for a sample.

<comment><USER66> I'm gonna look at rust; we're a huge c/c++ shop so there's room from improvement here. Now no program is a spec and implementation in one. Thus rust ought to be careful about keeping all it's hammers in language alone. If rust is smart and particularly wants to move to distributed computing or csps correctness will have to take on more complex meanings that bad index or divide by zero.</comment></comment></comment>


Ask HN: What kind of database to use for a Facebook like social network? - <AUTHOR> I am a self-teaching beginner. I am not asking this question to build the next facebook but to understand when should a particular kind of DB be used. Does using a graph database for users and a NoSQL database for the contents, posts, etc, while using an SQL to establish the relations between a user and their contents make sense? Or is using an RDBMS always the way to go and only start looking for alternatives when you hit a wall? <comment><USER2> If I were architecting such a system, I would start with one database. The analogy I would make is to Twitter which ran on Ruby on Rails as long as it could and only changed when it _had_ to change. The reasons it had to change were driven by customer utility not future proofing engineering.

</comment><comment><USER3> Give this a look

[https://neo4j.com/](https://neo4j.com/)</comment>


How to build Docker images from within a Kubernetes cluster - <AUTHOR> https://www.thenativeweb.io/blog/2018-08-14-11-32-kubernetes-building-docker-images-within-a-cluster/ <comment><USER2> This approach is very interesting to use kaninko inside kuberntes, but in what moments you copy the code of the application or provide the job, it would be interesting to make a kaniko operator with this feature</comment>


How Microsoft beat Google at understanding images with machine learning - <AUTHOR> http://www.techradar.com/us/news/world-of-tech/how-microsoft-beat-google-at-understanding-images-with-machine-learning-1311683/2 <comment><USER2> You should share the first page of the article, not the second.

<comment><AUTHOR> Sorry, I didn't notice. Don't think I can edit the link now. Maybe one of the moderators can.</comment></comment>


Ask HN: Apple and Google browser/OS bundling today vs. Microsoft circa 2000 - <AUTHOR> Why are Apple and Google not in trouble today for antitrust violations the way Microsoft was over a decade ago?<p>Microsoft bundled IE with Windows, in the same way Apple bunldes Safari with OS X and iOS, and Google bundles Chrome with Android. Is it because Microsoft had larger market share? Or have the barriers to installing alternative browsers been lowered? If the latter, then was the decision against Microsoft a mistake in retrospect? <comment><USER2> I think there has been a shift in recognition of what a browser is: at the time Microsoft added IE into Windows, Netscape was still a relatively large company with a vested interest and browsers were seen as commercial products. Microsoft argued that the future of the browser was not a standalone product but an operating system component that would be a requirement for an operating system moving forward.

I do believe that Microsoft was ahead of the curve in that forethought, and that in retrospect Microsoft was right and the world was changing out from under Netscape's feet. But I also don't blame people for questioning that at the time, the internet was young and nascent then and we were still feeling out which "apps" on it, such as the web, would be ubiquitous services that everyone would need access to.

(I'm much more angry about the similar XP-era decision that anti-virus was not a core operating system component, to appease some greedy companies, and I'm glad the statute of limitations on that mistake has passed. Go, go, Windows Defender.)</comment>


Ask HN: Rate my startup- CrushTease - <AUTHOR>

Three weeks ago I asked what I should do: http://news.ycombinator.com/item?id=1625791
Thanks to you guys I found a partner and have a product today:
http://www.crushtease.com
In short, it's an "anonymous matching/crush matching" service, with the twist that when two people are confirmed interested in each other, instead of telling both of them, you alternate between who you tell. This provides the uncertainty that makes relationships fun and interesting in their early stages.
You can read about it more on: www.zachjiganti.com
Please check it out and let me know what's good, bad, and if you think people will use it. <comment><USER2> _This provides the uncertainty that makes relationships fun and interesting in their early stages._

Um, isn't the "uncertainty" the whole reason that you haven't just asked them out in the first place already? Isn't it the whole idea of not wanting to ruin a friendship or 2 or more (in the case where you or the other person are "taken") the whole reason that a person keeps their feelings secret to begin with?

How does this app actually aid with those issues at all?

<comment><AUTHOR> This and other crush-matching apps aid with these issues by eliminating the chance that you could be rejected. CrushTease isn't really novel in this sense, other apps provided a medium so rejection won't happen, but there was no "happy medium" (no pun intended) that prevented rejection but maintained a level of uncertainty. That's our goal.

</comment></comment><comment><USER3> I think it's a great idea. congrats. I would change a little bit the way it works. You could ask when someone registers if they would preffer to approach or be approached. You could mix up the probabilities of getting the info according if you are more likely to approach the other person or not (I'm guessing your ultimate objective is to form couples) Best of lucks! Martin

</comment><comment><AUTHOR> Clickables:

<http://news.ycombinator.com/item?id=1625791>

<http://www.crushtease.com>

<http://www.zachjiganti.com>

<comment><USER4> Congrats :-)

<comment><AUTHOR> Thanks, I appreciate your help, it definitely progressed my outlook on the concept by getting a fresh perspective, especially from someone who knows the field well.

</comment></comment></comment><comment><USER5> This concept of "anonymous matching/crush matching" was the basis of eCRUSH. The founder did an interview on Mixergy <http://mixergy.com/ecrush-ranker- clark-benson-interview/>

Here are some additional links: [http://www.startup-review.com/blog/ecrush- case-study-why-tim...](http://www.startup-review.com/blog/ecrush-case-study- why-timing-the-ma-market-is-tricky.php) <http://en.wikipedia.org/wiki/ECRUSH>

Maybe there are some lessons you can glean from the eCRUSH story that will help you out.

</comment><comment><USER6> There is a startup out of dogpatch NYC who's doing a similar idea, but last I heard it was limited to college students.

www.goodcrush.com

Edit: It looks like they pivoted away and turned into something I thought about doing a while back.

</comment><comment><USER7> I'm a little curious about this:

>As a general rule, women lose interest once they know the other person is interested in them.

If a girl and a boy crush on each other, and the girl gets told and loses interest, the boy is in a worse position than before. Do you feel the uncertainty of "does he know I like him back?" will help keep her interested?

When you sign up it doesn't ask for permission to access relationship status. Does that mean you're not keeping track of your "success rate"?

<comment><AUTHOR> What I meant was that past services that tell both people make the relationship a little flat. Flirting becomes a little pointless, which is no fun.

In the instance you specified, she is still uncertain as to whether _he knows she's interested_ , which is enough to keep her wondering and somewhat emotionally invested.

As of right now we aren't keeping track of "success rate", but I think we'll eventually put up numbers as to how many people have both displayed their interest in the other person.

</comment></comment><comment><USER8> I can see people abusing this by saying they have a crush on everyone on their friend list, just to see if anything sticks.

<comment><AUTHOR> There is a limit to the amount of people you can crush, it's set now at 20. Thoughts on this number?

<comment><USER8> I don't know, 20 seems rather high. Maybe 3?

<comment><USER9> It has to be a number that works for social butterflies too. "Crushing" means something different to everyone; friendship, dating, hookup, marriage, etc. People also change their 'crushes' at different rates depending on their lifestyle and personality.

</comment></comment></comment></comment><comment><USER9> It's interesting because when two people have a mutual crush, and you are told of the crush, you won't know if they were told unless they mention it. So you have a confirmed connection of some sort, but you still need the balls to act on it. Or maybe you won't act on it?

Think about it the other way too: They were told, but you weren't. You think she just doesn't crush you, but maybe she did and you weren't told. What if she was told and she starts flirting with me?

The mystery is glorious.</comment>


Show HN: What movie to see in theaters, powered by Hunch - <AUTHOR> http://www.whatmovieshouldwesee.com/

<comment><USER2> Good movie recommendations near me. I like the popup maps on the right-hand side, although it looks like you might have reached the limit of calls (just me?).

</comment><comment><USER3> Dig the minimalist layout. Translates well to mobile.

</comment><comment><USER4> +1 for a mobile version. Very slick.

<comment><AUTHOR> functioning map too, i hope people find it useful

</comment></comment><comment><USER5> +1 for "Reticulating Splines"!

<comment><AUTHOR> simcity foreva</comment></comment>


Java Language Support for Visual Studio Code Has Landed - <AUTHOR> http://developers.redhat.com/blog/2016/09/19/java-language-support-for-visual-studio-code-has-landed/ <comment><USER2> A java IDE written in JS. This is kind of "historic" in its own way.

<comment><USER3> Actually Swing is dead end in my perspective, no matter how much JetBrain tries to improve it(forget about Oracle, they don't even care about Swing), it sucks, in so many dimension. Even after investing so much money and time, they could have much better UX with other options.

I had my eye in standalone version of Eclipse Che. But VSCode with Java support is actually is so great. Smooth UI with minimum latency.

<comment><USER4> Of course Oracle doesn't care about Swing, because there's already a replacement for it called JavaFX in active development.

<comment><USER3> Discontinuing Scene Builder sent mixed message about Oracle seriousness about JavaFX either.

</comment></comment></comment></comment><comment><USER5> I do not want to crap on either RH or MS devs and the volunteers around surronding projects, but I really like the idea of building backends you can plug into various editors of your own choosing.

\- Java and emacs/vi: eclim \- .Net and whatever: OmniSharp \- Haskell and whatever: scion

These are all so-so examples. But I wish we would move more towards this notion of abstracting backends out.

I am one of those jackasses who loves emacs. And I should be able to impose that on myself AND only myself. I think we are reaching a point where tool lock-in a la Visual Studio and even in the open source space with projects like neovim-spacevim and spacemacs shows we are not cool with it.

So is it possible for me to run this JS backend for Java parsing and replace eclim? Haha.

<comment><USER6>
      Right. IDEs and editors appear, get their hype, some stale, others get forgotten, people get attached and then whine for years about shortcomings and weak support for certain languages and complain about lack of specific features. Or fell into Stockholm syndrome without slightest realization of how miserable and inefficient their workflow has become.
       Who remembers Borland C++ Builder? who uses Komodo or TextMate today? And now check the number of projects on Github written in Emacs Lisp.
       No matter how popular those shiny, fast and noisy F1 supercars would be - there always will be plenty of enthusiasts who'd rather choose Nascar, with its simplicity, openness and customizability.
      No IDE or editor would ever get even close to the power of Emacs. And the power of Emacs lies within its extensibility. I am not worried about other editors or IDEs getting better, faster or shinier. Because Emacs already can do same things better, or will be doing them better someday soon.

<comment><USER7> I coded in emacs for 20+ years and switched to clion last year for c++ work because of things like "good autocompletion" and "refactoring" and "warning about issues before compiling". Emacs has minimal autocompletion facilities, but for ideological reasons it does not and may never have many of the other features.

I still use emacs for non-coding text editing, and sometimes for python code and emergencies, but I've moved away from it big time.

p.s. please fix your formatting, that quote is unreadable.

</comment></comment></comment><comment><USER8> Interesting that RedHat is the driver behind this.

<comment><USER9> Don't see why. They're big into Java over there.

<comment><USER10> Don't they own JBoss ?

<comment><USER9> They do. They're also responsible for the Shenandoah low latency GC.

</comment></comment></comment></comment><comment><USER11> Would love to see a vim plugin that can function as a client for the server component. eclim works well but it would be great to have an alternative, or a company like redhat to help out with that effort.

<comment><USER12> Check out how neovim works with the various backends. F# has the FSAC (F# Auto Completion) that calls to a running mono process for auto-completion, syntastic/type checking, etc. It's also how the Ionide plugin for VSCode works. Really awesome work.

</comment></comment><comment><USER13> I'm a bit surprised it _didn 't_ have Java support already.

<comment><USER14> "support" in VSC is kind of a multi-tiered thing: you can have basic support with just syntax highlighting, or if you can hook it up to a server providing the appropriate language intelligence, then you can have refactoring/debugging/etc. VSC had Java syntax highlighting before, and a plugin that helped shell out to javac, but that was about it. Now it's getting the full package.

<comment><USER13> Awesome. Thanks.

</comment></comment></comment><comment><USER15> Now if we could only get proper SFTP support, I'd be off of Sublime for good.

<comment><USER16> Why would you be using Java without an IDE? Aren't Java/C# are one of few language that really benefit from a fully fledged IDE?

<comment><USER10> Intellisense Yes. Bulky IDE, not always.

<comment><USER16> Is this trade-off worthy? You gain performance but you are sacrificing huge amount of features. And once you add those features performance will always suffer.

<comment><USER17> If intellisense + debugging get you 90% there, do you need a heavy IDE?</comment></comment></comment></comment></comment>