Emacs-Helm development is now stalled - <AUTHOR> https://github.com/emacs-helm/helm/issues/2386 <comment><USER2> The Emacs package `Helm' is/was maintained by one guy alone named Thierry Volpiatto who is not even a developer. He is 57, and a mountain guide in the Alps!

See this rare interview from 2018: [https://sachachua.com/blog/2018/09/interview-with-thierry- vo...](https://sachachua.com/blog/2018/09/interview-with-thierry-volpiatto/)

<comment><USER3> I find it pretty amazing that someone who's been working for 20 years as a mountain guide and spends as much time as possible outdoors picks up an obscure piece of niche software like Emacs, learns to program in his 40ies and then becomes one of the most significant package contributors, all as a side hobby to his outdoor interests.

<comment><USER4> A lot of mathematicians are oddities that by some stroke of luck, or perhaps by consistent switching of hobbies, somehow figure out that they understood the basic premises of mathematics.

After all, the issue is that mathematics is _simple_. Humans don't like simple things. And when humans think they have found simple things they start wars or some novel iteration of discrimination against others.

<comment><USER5> > Humans don't like simple things.

I like simple things, am I not human?

<comment><USER6> The brain obscures a lot of complexities.

Just take any simple thing and start thinking of any aspect of it. That itself is not simple!!

</comment></comment></comment></comment></comment><comment><USER7> A follow up issue[0]:

> Thanks so much for everything! #2388

Nice to see a positive response from the emacs community.

Helm only seems to have 15 issues, maybe it really is that close to complete for most people using it. I know I use helm and haven't thought twice about it.

[0]: [https://github.com/emacs- helm/helm/issues/2388](https://github.com/emacs-helm/helm/issues/2388)

</comment><comment><USER8> Interesting, no details into why. Anyhow, for those who might want a replacement in case no one else picks up development for Helm, I highly recommend the Ivy package as an alternative in Emacs. I've always preferred it over Helm for being more minimal and speedier.

<comment><USER2> I higly depend on `helm-org-rifle' [1]. Lets me search trough all my org files (headars and content) and presents the results beautifully in a temp buffer. - Would be very sad if development of helm would stop.

And yes, ivy is an awesome package. Higly recommend it.

[1]: [https://github.com/alphapapa/org- rifle](https://github.com/alphapapa/org-rifle)

<comment><USER9> I'm glad you find it useful.

1\. Helm is not going to stop working anytime soon. I haven't even upgraded Helm in my configuration for a long time, and the version I have installed still works fine.

2\. The latest version of Helm should continue working for even longer.

3\. It shouldn't require much effort to make the occasional fix to Helm for compatibility with newer Emacs versions.

4\. It's likely that Helm will continue to be maintained by someone, if not Thierry after some time away.

5\. org-rifle already has a non-Helm interface built-in.

6\. See also org-ql, which supersedes org-rifle to some extent.

</comment></comment></comment><comment><USER10> Damn. Helm is the most important emacs package I use. It's what makes emacs "emacs" for me, and the main reason I find every other editor "from the past".

Is there a way to help Thierry financially?

<comment><USER11> I love helm but I've in the past years found ivy to work better in the ecosystem at large. I still miss some aspects of helm but it could be an option

<comment><USER12> It's a bit lighter on resources as well. Although with modern processors and memory sizes, helm really is nothing compared to some of the things that go on in vscode :)

</comment></comment></comment><comment><USER13> Moved from Emacs to ST then VSCode a few years ago, but still miss how that community feels (the software, the people, the discussions, EmacsWiki...)

IIRC I used to move around mostly using ido.el, when anything.el and later Helm appeared with their alternative way of displaying results, using half the window.

But then at some point got sick of the text UI and moved to Sublime Text. Probably multi-cursors made me move?

For a few years I remember opening Emacs exclusively for [https://www.emacswiki.org/emacs/grep- edit.el](https://www.emacswiki.org/emacs/grep-edit.el).

I feel like Emacs is full of those hidden gems that only a hundred people use.

<comment><USER14> Emacs has multi cursors ([https://html.duckduckgo.com/html?q=emacs%20multi%20cursors](https://html.duckduckgo.com/html?q=emacs%20multi%20cursors)) though I never saw them as useful, search & replace seemed better. Perhaps I was missing something.

<comment><USER15> I use multicursor all the time and it works great. Probably because I never got used macros.

<comment><USER14> I'd say spend the time to get used to macros and and regexes. Each is so capable, together they are more than the their sum.

</comment></comment></comment></comment><comment><USER16> I've been using selectrum lately, it works ok, no bells and whistles... The readme [1] has a [probably very biased] comparison of alternatives, including helm.

1: [https://github.com/raxod502/selectrum#why-use- selectrum](https://github.com/raxod502/selectrum#why-use-selectrum)

<comment><USER17> Thanks for this link.

For some reason, neither helm, ivy or selectrum allows to open a candidate buffer / file in either the current buffer, a vertical or horizontal split window, like what I have grown an addiction for with fzf.vim.

As I have also grown an addiction to org mode, emacs ergonomics always feel weird to me, even with evil mode.

Selectrum seems to explicitly exclude "alternate actions" :(

<comment><USER18> > For some reason, neither helm, ivy or selectrum allows to open a candidate > buffer / file in either the current buffer, a vertical or horizontal split > window, like what I have grown an addiction for with fzf.vim.

I use ivy and counsel, and both counsel-find-file and ivy-switch-buffer offer the alternate action "other window" under M-o j. I'm not sure if that covers your entire use-case, but it works fine for me.

<comment><USER17> Thanks, I have found this "menu", but it felt awkward and limited to either horizontal or vertical.

I have come to split first and search second.

It's all about personal preferences.

<comment><USER9> Being Emacs, it's just a matter of customization. In your example, it would probably be enough to apply advice to one of the Ivy functions to split the window appropriately when a candidate is selected. A few lines of code.

<comment><USER17> > being emacs ... customization ... a few lines of code

I see where you are heading and I am not following you in this rabbit hole ;)

I came to use emacs for org mode, when what I really wanted was to use org mode in vim. We can't have All the nice things, so it's okay, I'll live with that. I actually found out I could use emacs as a "org mode beautifier" in neoformat.vim; it is slow, but it can tangle the org file and output back to vim. Good enough.

</comment></comment></comment></comment></comment></comment><comment><USER19> For those unfamiliar with the alternatives, you can switch to ivy and counsel, it's pretty lightweight and a nice alternative. Works well with Doom Emacs and out of the box.

<comment><USER20> I switched from helm to ivy-counsel-swiper earlier this year and I haven't looked back.

</comment></comment><comment><USER21> That's too bad. Once I discovered helm, that was a complete game changer for how I used Emacs.

Guess I'll still hang on as a user, and see how it pans out over time.

</comment><comment><USER22> That's too bad. I personally didn't use helm and found it a little strange after being use to vanilla Emacs for many years, but I know a lot of people liked it a lot. I wonder what happened there?

<comment><USER23> Helm has a slight learning curve (more like un-learning curve). Need to forget Tab completing/narrowing. (It is hard for long time Emacs users)

Just start typing snippets of what you want.

Once you get used to it, you want it everywhere.

FZF on zsh works the same way and is a pleasure to use for people with 10 of thousands of items in shell history.

</comment></comment><comment><USER24> Nineteen minutes before opening the linked issue announcing that the development had been stalled, he removed a chunk of text from the README: [https://github.com/emacs- helm/helm/commit/9a5258db9c7bb12698...](https://github.com/emacs- helm/helm/commit/9a5258db9c7bb12698d8feb7b255006f134594e5)

Here's how it looked before that change: [https://github.com/emacs- helm/helm/blob/23f32ec37dadea5656fb...](https://github.com/emacs- helm/helm/blob/23f32ec37dadea5656fb73f49a487b8136952015/README.md)

Here's a representation of the text for those who don't want to click through:

> Maintaining Helm requires a [lot of work]([https://github.com/emacs- > helm/helm/commits?author=thierryvol...](https://github.com/emacs- > helm/helm/commits?author=thierryvolpiatto)), Thanks to all the people that > are helping or have helped Helm development,

> but they are actually too few.

> If you feel Helm is making your daily work easier,

> please consider making a donation.

> Thank you! — Thierry Volpiatto

> [PayPal link image][Pateron link image]

The Patreon link doesn't seem to be working (the page is mostly blank, which seems like a bit of a bug on Patreon's end if nothing else).

The PayPal link is still active.

\---

There was also this README change in May that removed some text: [https://github.com/emacs- helm/helm/commit/3be1389e3912d6580a...](https://github.com/emacs- helm/helm/commit/3be1389e3912d6580aac9c5532e2fa8fee88527c)

Which looked like this prior to the change: [https://github.com/emacs- helm/helm/blob/1fbb3a9f6da328519162...](https://github.com/emacs- helm/helm/blob/1fbb3a9f6da3285191621263660f3b3a9791f806/README.md)

Compressed representation:

> Maintaining Helm requires a lot of work, which I have done voluntarily since > 2011. As it demands lots of my time it gets increasingly difficult > maintaining it without financial help. Thanks to all the people that are > helping or have helped Helm development, but they are actually too few to > continue serenely. By the way, after the release of version 3.0 I will have > to stop developing Helm seriously until I get enough financial support, only > providing a minimal bugfix maintenance. Thanks for your understanding

> If you feel Helm is making your daily work easier, please consider making a > donation. Thank you! — Thierry Volpiatto

Development was also apparently stalled for a time in 2018-2019: [https://github.com/emacs-helm/helm/issues/2083](https://github.com/emacs- helm/helm/issues/2083)

From my brief skimming, it seems like this has been coming on for a while, which is a sad thought.

\---

One more thing that might be meaningless, but which I think indicates a level of ongoing care about the project (which is not surprising given his past work on it). The commit that most recently modified the README accidentally undid the latest change he'd made, from two days before. He added another commit a minute later to re-apply it. A small thing, but I figured I'd mention it.

<comment><USER25> The state of the Patreon page is what it looks like when someone has an ordinary patron account. In this case, it probably means the account was reverted from a creator account to a patron account.

</comment></comment><comment><USER26> (neo)vim user here; is this like the myriad of ctrl-p vim plugins like fzf, cpsm, etc? In the vim world the core functionality is often shelled out to a task-specific process via a plugin, and the vim code is only used to communicate with it. Is that not the case with emacs?

<comment><USER27> It's more like fuzzy search for everything you could possibly do, with docs and completion. I'm a vimmer, emacs people should correct me.

It's magic because everything is a single lisp environment. So the client/server thing vim does isn't as unified.

<comment><USER28> No that is right, emacs has two main contenders for "fuzzy search" \- ido-mode and helm. They act as completion engines for all kinds of search; file, word, buffer, commands etc.

Helm acts similar to Ctrl+P, ido is like an incremental search so finding a file named BasketViewController.swift in path ~/Code/MyApp/;

In helm would be 'bvc', whereas in ido it would be c -> code (hit enter), m -> MyApp (tab across if its not first result, enter) Bas -> BasketViewController.swift

<comment><USER29> > emacs has two main contenders for "fuzzy search" \- ido-mode and helm.

Also Ivy.

</comment></comment></comment></comment><comment><USER30> My one point of contention with helm is it's too controlling. There is no built in function for enumerating the candidates list, if you happen to want that. The current contents of the minibuffer (whatever you have typed or have not typed) up until recently couldnt be used as as the selection. Now there is a must-match parameter, but it can only be set upon invoking helm and not via a key binding (if you wanted both behaviours). The parameter must-match also doesn't solve the problem of selecting the empty string and selecting the empty string breaks out of helm. I still use helm for when I want strict control over the candidates, such as for running elisp functions with M-x. Ivy, on the other hand, is a much simpler fuzzy-finder. It's more like fzf. I use ivy as the default completing-read function.

</comment><comment><USER31> Helm is amazing in that you can add it to your workflow, read practically no documentation and get a significant boost to productivity and user experience. Its a must have for me.

</comment><comment><USER32> I hope somebody will step up a new maintainer. Helm is very popular and part of many people daily emacs workflow.

</comment><comment><USER33> Fork me!

</comment><comment><USER34> Could you please rename the title to state that it's Emacs-Helm search extension? Otherwise it's too click baity for the Kubernetes crowd.

<comment><USER35> Eh, and I almost lost my breath when I thought my favorite open-source synth[1] was being discontinued.

[1] [https://tytel.org/helm/](https://tytel.org/helm/)

<comment><USER36> Is it actually under active development? Are pull requests getting reviewed and merged?

</comment></comment></comment><comment><USER37> (The Emacs thing, not the Kubernetes thing.)

<comment><USER38> Also not the synthesizer thing. [https://tytel.org/helm/](https://tytel.org/helm/)

<comment><USER39> Made the same assumption too.

</comment></comment></comment><comment><USER40> Helm and Magit are why I use Emacs. This is really sad. Can this repo be handed over to someone else? I'd really like to support Helm in my own way, by making code contributions if possible.

</comment><comment><USER21> Post is _flagged_?!?

Why, oh, why?

<comment><USER41> Kubernetes people..

</comment></comment><comment><USER42> Thanks for the mini heart attack. Thought it was the Helm synthesizer. [https://github.com/mtytel/helm](https://github.com/mtytel/helm)

<comment><USER24> Well.. it looks like that hasn't had any commits for over two years anyway. Which might be okay; it could be done.

<comment><USER43> What? More like commits every other day for several years.

[https://github.com/emacs- helm/helm/commits/master?after=19d2...](https://github.com/emacs- helm/helm/commits/master?after=19d2ba9d36615f1dea6be6cd6dcf5792dfefc45b+34&branch=master)

<comment> kalium-xyz The comment you are replying to is not talking about the emacs helm but rather the synth.

</comment></comment></comment></comment><comment><USER44> This title is extremely misleading and terrifying for a Friday night, since the most common "helm" tool is the Kubernetes one. To avoid further SRE/devops mini-heart-attacks the title should probably be updated.

<comment><USER21> Most common for you. I've never even heard of that thing.

But yeah, if the title can be more specific, that can't possibly hurt anyone.

<comment><USER44> I admit that, yes, it's more common for me.

I felt comfortable calling it the "most common" on a wider scale based on a quick search for "helm" using the HN Search. At quick glance ~90% of "Helm" mentions are the Kubernetes tool.

</comment></comment></comment><comment><USER45> Helm is a mess of code, I'd suggest it probably has become unmaintainable. Ivy is my preferred completion plugin.

<comment><USER46> Why the negativity? Helm has served me really well for pretty much every day for the last 10 years. I'm extremely thankful for it.</comment></comment>


Mosaic's birthday: 25 years of the modern web - <AUTHOR> http://www.zdnet.com/article/mosaics-birthday-25-years-of-the-modern-web/ <comment><USER2> It did a good job of handling the details, even for a nitpicker like me. (Eg, careful to say that there were web browsers before Mosaic, including graphical ones).

I will nit-pick this part:

> Andreessen and Bina quickly realized they could make a mint from Mosaic. > They took the Mosaic code. In October 1994, they turned it into the first > successful commercial web browser: Netscape Navigator.

As I recall, NN is not based on the Mosaic code, though I believe Netscape did license the Mosaic code. Quoting [https://en.wikipedia.org/wiki/Mosaic_(web_browser)](https://en.wikipedia.org/wiki/Mosaic_\(web_browser\)) :

> Netscape Navigator was later developed by Netscape (originally known as > Mosaic Communications Corporation), which employed many of the original > Mosaic authors; however, it intentionally shared no code with Mosaic.</comment>


How long does it take to linear search 200MB in memory? - <AUTHOR> https://www.jonathanotto.com/linear-search-benchmark <comment><USER2> Not wanting to be the 'Old Man Yells At Cloud' figure, but this is a perfect illustration of how _not_ to do it, particularly multithreading in Go before using a reasonable algorithm.

Searching for a long string like this is preposterously easy. You can use a classical algorithm, or, given you are looking for a 64 byte long string, you could do a strided inspection - every 32 bytes, look to see if you have a 4-gram from the first 35 bytes of the string. More or less _anything_ works as almost any reasonable string searching mechanism can outrun memory bandwidth.

Or you could go use my old project ([https://github.com/intel/hyperscan](https://github.com/intel/hyperscan)) and then you could look for regexes too. :-)

<comment><USER3> Depends on how often you need to search. The implementation of the parallel linear search in Go is a lot easier to get right than what you're recommending.

Though I would certainly agree that paying for more vm cores just so you can do a linear search on each of them is a bit silly

<comment><USER2> The linear search code should probably be in a library, and in fact often is, if you have the GNU extension memmem().

I'm also not convinced that it's that hard. This seems to be the new cult; just because someone buggered up binary search with an integer overflow once, we're not going to write non-pathological algorithms anymore?

<comment><USER3> I'm not saying it's a bad idea to implement it, but there's a greater time cost, and if the performance gains aren't worth the effort, then there's no reason to make the improvement

<comment><USER2> Fair enough. I guess you would figure out how long it takes to either clag the code from somewhere else or write it yourself and plug in the math at the bottom of the page (as they are trying to quantify the value of doing this).

I strongly suspect dragging in memmem() would be the most cost effective way of doing this and run in the most places, even if it's a non-standard GNU libc extension.

</comment></comment></comment></comment></comment><comment><USER4> 0.25s for 200MB (in memory) seems pretty slow for a modern CPU (800MB/s) which is more than an order of magnitude below what you would expect from main memory.

There can be a lot of performance left on the table even in standard library implementations: [http://0x80.pl/articles/simd- strfind.html](http://0x80.pl/articles/simd-strfind.html)

<comment><USER5> This isn't super surprising to me. String comparisons are super slow if not handle with care, and even then may be surprisingly slow. This does a LOT of string comparisons.

Depending on the requirements, sliding a window through doing byte comparisons may be better. [https://golang.org/src/bytes/bytes_decl.go?s=522:550#L7](https://golang.org/src/bytes/bytes_decl.go?s=522:550#L7)

EDIT: I believe paper trail does or did have a limitation on case sensitive searching. You can imagine why they may be doing this if you consider the performance implications.

</comment></comment><comment><USER6> The ruby version looked a bit odd to me. It would be unusual to not use regex in this context.

I'm not sure if this is in the spirit of the test, but using regex reduced the time from 27s to 0.04s on my machine.

        require 'benchmark'

        contents = File.read("/tmp/200mb.txt")
        find = "07123E1F482356C415F684407A3B8723E10B2CBBC0B8FCD6282C49D37C9C1ABC"
        result = nil
        elapsed = Benchmark.realtime do
          result = (contents =~ /#{find}/)
        end
        puts "Found at index #{result} in #{elapsed}s"

(The search string was placed at the end of a 200mb file)

<comment><USER7> You can reduce the time to 0.02s by just using `String#index`.

</comment></comment><comment><USER8> The fastest, Golang at slightly over 2.8GB/s, is still surprisingly slow for modern (as in, under 10 years old) hardware. I just wrote a similar linear search in Asm using the not-so-fast REPNZ SCASB/CMPSB instructions and got 6GB/s on an i7 860 from 2009.

If you're just scanning for the string then algorithms like BMH can do up to x times memory bandwidth, where x is the length of the string, since they start matching from the end and can skip over chunks of x bytes at once.

This article from someone with a rather... distinctive style shows >10GB/s on 5-year-old hardware with target strings only slightly over 50 bytes:

[https://www.codeproject.com/Articles/250566/Fastest- strstr-l...](https://www.codeproject.com/Articles/250566/Fastest-strstr-like- function-in-C)

<comment><USER9> I recall repne scasb was significantly slower than the equivalent loop unrolled a few times. Not sure if that's still the case but it was something like 2x slower.

</comment></comment><comment><USER10> I don't have a computer at hand, but I imagine it would be a lot shorter (and likely faster due to algorithmic optimisations) to use bytes.Index. As other have pointed out, 1 GB/s seems slow. I would expect that performance when reading from disk.

(Also, iterating over indexes is not too idiomatic in Go. You can iterate both the index and value using `range`, just like enumerate in Python.)

[https://golang.org/pkg/bytes/#Index](https://golang.org/pkg/bytes/#Index)

<comment><USER11> Turned out bytes.Index is initially similar or slower in speed, but search time goes down to 40ms as soon as you lop off the last byte.

For strings over (on my machine) 63 bytes, bytes.Index uses a rolling Rabin- Karp hash. For this data it's ~25% slower than the loop to search. However, that evens out if you make the whole file hex, which makes the search loop have some branch mispredictions. (Also, the simple loop search isn't complete! More below.) The R-K search is more reasonable than this one comparison makes it sound; it avoids bad worst-case behavior when there are a lot of partial matches. (Also, it may be less optimized because authors think most bytes.Index searches will be for short bits of data.)

Relatedly, the loop search doesn't back up its position when it discovers a partial match isn't a complete match, which means it's incorrect; it won't find a real match that overlaps with a false match (a prefix of a match). Like, when I made a file that contained "07123E1F482356C415F684407123E1F482356C415F684407A3B8723E10B2CBBC0B8FCD6282C49D37C9C1ABC", it didn't find the match starting at the second 071... because it overlaps with a prefix of a match (at the start of the string) that didn't turn out to be a full match. (The overlap is two digits here, but same thing would come up if it were one digit.)

Searching for shorter strings, Index on Intel platforms uses AVX/SSE search. If you're going to search for long strings and feel lucky, you could search for a prefix of whatever your platform's max SIMD-searchable length is, then check if it's a full match. If so, you're done; if not, keep searching starting at the next byte. In case of pathological data you could bail out to the safe R-K approach after n false matches, like one of Index's existing strategies does. It might be something for someone who wants a stdlib patch to try submitting to Go, though it might also be that they see it as too much of a corner case to merit complicating things more.

</comment></comment><comment><USER12> That search doesn't handle head/tail overlaps, but otherwise it's a good approximation. I'm surprised it isn't faster; I think I got a few hundred MB/s on trie-based matching.

Protip: bring benchmarks like this to your meeting with the sales rep.

<comment><USER13> It's pretty bad: Say it's searching for "AB". It won't find it in this string: "AAB"

<comment><USER14> I think the point was just to test each string against the query for equality. The benchmark could be slightly tweaked to test each string against the query for substring inclusion or regular expression match, but I suspect the results would only change by the cost of the test predicate.

<comment><USER13> Not necessarily when comparing different language, as they might allow different optimizations. For example, you'd be able to compare several bytes at a time with C if you pad the strings, while node.js' V8 is unlikely to optimize that far.

</comment></comment></comment></comment><comment><USER15>
        console.log(bulk.length); console.log(new Date()); pos= bulk.indexOf("788bbd6b12d79a4ee18e36a8a264fb496465c71b7932a965ed731397b7c97d14"); console.log(pos); console.log(new Date());
        209715266                           debugger eval code:1:1
        Date 2018-04-28T00:08:30.231Z       debugger eval code:1:27
        209715202                           debugger eval code:1:139
        Date 2018-04-28T00:08:30.252Z       debugger eval code:1:157

That's about 0.021 seconds for however Firefox implements String.indexOf().

        $ dd if=/dev/urandom of=200mb.dat bs=1M count=200
        200+0 records in
        200+0 records out
        209715200 bytes (210 MB, 200 MiB) copied, 2.98279 s, 70.3 MB/s

        $ echo 788bbd6b12d79a4ee18e36a8a264fb496465c71b7932a965ed731397b7c97d14 >>200mb.dat
        $ time grep -o 788bbd6b12d79a4ee18e36a8a264fb496465c71b7932a965ed731397b7c97d14 <200mb.dat
        Binary file (standard input) matches

        real    0m0.056s
        user    0m0.028s
        sys     0m0.028s

That's not too terribly different.

<comment><USER16> Something feels off about this, but I can't put my finger on it.

</comment></comment><comment><USER17> The multi-core Go benchmark is spawning the goroutines before calling `start := time.Now()`.

<comment><USER18> Go's concurrency model defines that memory writes in one goroutine won't be observable in another until a context switch can happen (e.g. by send/recv on a channel). In practice, newly spawned goroutines often don't get the chance to run at all until that context switch. But yeah, it's not a good idea to rely on this behavior here.

<comment><USER19> I'm not sure where you got that information?

Go's goroutines launch on threads when multiple CPUs are available. They have all the race conditions of C code. Memory writes certainly are visible on other goroutines.

<comment><USER18> > I'm not sure where you got that information?

From the very official spec? [https://golang.org/ref/mem](https://golang.org/ref/mem)

Goroutines do not map to OS threads 1:1. Whether the scheduler decides to spawn a thread or not is its own, entirely private decision. No action is guaranteed to be taken until scheduling occurs.

<comment><USER19> Well, from that spec: "When multiple goroutines access a shared variable v, they must use synchronization events to establish happens-before conditions that ensure reads observe the desired writes."

However, that very specifically does NOT say that writes may not be observed BEFORE synchronization events. They MAY.

Under "Incorrect Synchronization": "Note that a read r may observe the value written by a write w that happens concurrently with r. Even if this occurs, it does not imply that reads happening after r will observe writes that happened before w."

These memory ordering rules are the same as C, C++ or machine code. Go makes no special effort to avoid the natural machine behavior of x86, ARM or MIPS.

And on goroutine spawning and execution order, I have observed both behaviors. Sometimes Go will continue on the current goroutine before launching other goroutines. Other times the new goroutines begin executing immediately. It's possible that some other, background goroutine is causing a scheduling event, but if so it's so random that no one could predict it.

</comment></comment></comment></comment></comment><comment><USER20> A single frame of Quake is 800x600=1mb of memory, and quake ran at 30fps on a pentium-233 in software. That's 30mb per second circa 1995. So your times all seem extremely slow to me. You should be getting a couple orders of magnitude better speeds. Try it in rust!

</comment><comment><USER21> I'm actually somewhat surprised it wasn't faster. I may play with this and see how fast I can get it to go.

Edit: After a number of attempts (such as using Golang's regexp library or strings.Contains()), I wasn't able to speed it up much. Interestingly, grep performs the same search in about 5ms on my machine.

<comment><USER22> grep is the product of a lot of thought and engineering. There's a great rundown by GNU grep's author, if you're interested [1].

One big takeaway is that grep doesn't simply traverse the string linearly, instead using the Boyer-Moore algorithm [2].

1: [https://lists.freebsd.org/pipermail/freebsd- current/2010-Aug...](https://lists.freebsd.org/pipermail/freebsd- current/2010-August/019310.html#)

2: [https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_sea...](https://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_search_algorithm)

EDIT: Interestingly, there seems to be an internal Boyer-Moore implementation in Golang's strings package[3], though it only appears to be used in strings.Replace("")[4]

3: [https://golang.org/src/strings/search.go](https://golang.org/src/strings/search.go)

4: [https://golang.org/src/strings/replace.go?h=stringFinder](https://golang.org/src/strings/replace.go?h=stringFinder)

<comment><USER23> And if you want an even faster version of grep, checkout ripgrep (which happens to be written in Rust).

[https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

</comment></comment></comment><comment><USER24> Ignoring the somewhat low performance, unless I'm misreading things, this version won't be able to find the string:

       07123E1F482356C415F684407A3B8723E10B2CBBC0B8FCD6282C49D37C9C1ABC

in the string:

        07123E1F482356C415F684407123E1F482356C415F684407A3B8723E10B2CBBC0B8FCD6282C49D37C9C1ABC

or to make this a bit easier to read, it won't find:

        AXAY

inside the string:

        AXAXAY

at the start it will match all the way up to "AXA" then fail to match "AXAY" with "AXAX", and then it will try to search for "AXAY" in the remainder "XAY" which fails.

The correct way of handling this is either searching from the start at for every possible position, which will usually fail quickly so it's not _that_ inefficient, or you need to take into account that partial matches might overlap with an actual match, using something like the KMP algorithm.

</comment><comment><USER25> Maybe i'm blind - but i'm not seeing where the benchmark results are? Also, is this code the same code that you actually ran? For ruby, i notice you are outputting 'contens' not 'contents' so i imagine you would get a runtime error?

<comment><USER26> I also had a hard time finding performance. It's listed in the grey bar at the top of each language.

I'd love to see this comparison expanded to a few other languages (particularly C/C++ with custom memory allocation).

<comment><USER27> A c++ implementation gives 5.7[ms] for searching through 200MB of vector<string> on a Ryzen 1700x.

EDIT: Reworking the code.

<comment><USER28> I did some benchmarking for a dictionary app a while back, and the fastest I could get was strstr(), if I recall correctly. It substantially beat std::string::find(). Using a loop is bound to give terrible performance; for large data you should be using one of the string-search algorithms (which strstr() surely does). And given the very large search string, those string- search algorithms should be able to skip large chunks at a time.

Here's a small version that allocates 200 MB of uninitialized memory.

      #include <stdlib.h>
      #include <string.h>
      int main(int argc, char *argv[])
      {
    	int size = 200 * 1024 * 1024;
    	char *bytes = malloc(size);
    	bytes[size - 1] = '\0';
    	strstr(bytes, "788bbd6b12d79a4ee18e36a8a264fb496465c71b7932a965ed731397b7c97d14");
    	return 0;
      }

      > gcc test.c
      > time ./a.out
      real	0m0.006s
      user	0m0.002s
      sys	0m0.002s

(Since the author ignores time to read off disk, I figure uninitialized memory should be comparable. The chances of strstr() actually finding anything are pretty slim, but I ran it a number of times just to be sure, with the same results.)

This is on a 2012 MacBook Pro.

<comment><USER29> Note that strstr will stop as soon as you have a 0 byte so this is not a fair comparison.

Uninitialized (practically often zeroed) also produces different results from random and explicitly zeroed, since I assume it affects how often it can fail fast.

        #define _GNU_SOURCE
        #include <stdlib.h>
        #include <stdio.h>
        #include <string.h>
        #include <time.h>

        int main(int nargs, char ** args)
        {
          struct timespec start;
          struct timespec end;
          int mode = atoi(args[1]);
          const char * needle = "788bbd6b12d79a4ee18e36a8a264fb496465c71b7932a965ed731397b7c97d14";
          const int N = 200*1024*1024 ;
          char * haystack = malloc(N + sizeof(needle));
          strcpy(haystack+N,needle);

          printf("Mode is %s\n" , mode == 0 ? "zeroed" :
                                  mode == 1 ? "random"        :
                                  "uninitialized");

          if (mode == 0)
          {
            memset(haystack,0,N);
          }

          if (mode == 1)
          {
            FILE * urandom = fopen("/dev/urandom","r");
            int nread = fread(haystack,1,N,urandom);
            fclose(urandom);
            if (nread < N)
            {
              fprintf(stderr,"read returned %d\n",nread);
            }
          }

          clock_gettime(CLOCK_REALTIME, &start);
          void * found = memmem(haystack,N+sizeof(needle),needle,sizeof(needle));
          clock_gettime(CLOCK_REALTIME, &end);

          printf("Took %g secs to find string at offset of %llu\n", end.tv_sec - start.tv_sec + 1e-9*(end.tv_nsec -    start.tv_nsec), found-(void*)haystack);
          return 0;
        }

        $ gcc test_find.c -o test_find
        $ ./test_find 0
          Mode is zeroed
          Took 0.0147023 secs to find string at offset of 209715200
        $ ./test_find 1
          Mode is random
          Took 0.129951 secs to find string at offset of 209715200
        $ ./test_find 2
          Mode is uninitialized
          Took 0.0371922 secs to find string at offset of 209715200

<comment><USER30> Note that if you malloc that big of a block, it's going to come directly from a MAP_ANONYMOUS _mmap_ , and so it _will_ be zero initialized!

Your uninitialized mode _is_ slower than zeroed, but nowhere near as slow as random.

The difference between initialized and uninitialized may be due to page faults: in the uninitialized case, the search is touching the memory for the first time. Maybe we're seeing TLB misses?

<comment><USER29> Yeah I was expecting the uninitialized to be the same as the zeroed case for that reason, but was surprised to see a (slightly) different result.

Edit: you are almost certainly right. I added a getrusage call before and after, and we have ~50k soft page faults in the uninitialized case and ~2 in the zeroed case during the memmem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> [https://blog.burntsushi.net/ripgrep/#literal- optimizations](https://blog.burntsushi.net/ripgrep/#literal-optimizations)

</comment><comment><USER32> I made a program to add spaces into Chinese text, which requires a lot of string comparisons.

[https://pingtype.github.io](https://pingtype.github.io)

The algorithm works as follows: Read 5 characters. Is that in the dictionary? No. What about the first 4? No. 3? No. 2? Yes! Copy to the output string, add a space, slide along 2 characters. Repeat.

Searching a 5 MB dictionary repeatedly like this was too slow. I made it a little faster by splitting the dictionary based on the number of characters in the word (fiveWords, fourWords, threeWords, twoWords). It's still slow, though. I have to run it in local JavaScript, because I don't have a server. Any suggestions?

On a totally different extreme, the iTunes Store's EPF data (freely available!) is 55 GB of text. I'd like to sort out Artist names by Producer. To grep the file takes 30 mins. Is there a faster way?

Third, my algorithm for offline StackOverflow was optimised for disk space. I search the index of titles as 200MB of plain text to get the post ID. Then I use dd to get a 4KB chunk of the tar.bz2 compressed file. I can read it using bzip2recover. Then I check if the post ID is there, and binary search like that. It's slow (5 seconds to load) but doesn't waste my precious disk space, and I can be patient when I need offline StackOverflow.

<comment><USER33> I would put your dictionary into a prefix tree if some sort, and the first implementation I would reach for is a trinary tree [1]. As you scan your input, walk the tree. Each time you get to the end of the tree, insert a space one go back to the root. Once the tree is built it's O(length of input) [2] regardless if dictionary size.

1: [https://en.m.wikipedia.org/wiki/Ternary_search_tree](https://en.m.wikipedia.org/wiki/Ternary_search_tree)

2: for a fixed alphabet size. It's really closer to O(dictionary size * log(alphabet size)) if that increases with dictionary size.

</comment></comment><comment><USER34> This is actually something I'm trying to figure out. I currently use (and pay for) Scalyr, which is the best of the bunch (super fast, flexible alerting) but I hate shipping my log data there. It just seems like a potential attack surface I am not really happy about.

Is there anything open source that I can run in a docker container somewhere on the internets that allows me to create custom alerts, extract data, create charts and dashboards?

<comment><USER35> Scalyr CEO here. I'd love to hear more about how you're thinking about attack surfaces – drop me a line? My email address is in my profile.

<comment><USER34> For example, I am wary about who has access to my log data. I know that theoretically, I "invite" your support team, and can revoke it, but without an understanding of the architecture behind Scalyr, I am afraid this is just lip service.

</comment></comment></comment><comment><USER36> Hmmm, the Boyer-Moore indexing in Go takes 2 x as long as the naive linear search.

Now I feel bad for wasting an hour wrestling with Go weirdness to get my program to compile.

</comment><comment><USER37> Not regarding the time it takes to search stuff in an array. You really don't want any sort of naive string search to comb through your logfiles.

It might depend on your usecase but if you have some constantly running web app some service to diggest all the logs is very nice to have.

It is true that a lot of those logging services are absurdly expensive and i would rise even privacy concerns regarding sending all the internal data to someone else.

I really don't get why so many people buy overprices services, if all it takes is half an our and the skill to run through an installation instruction.

At our company we use graylog i guess there are other good alternatives too. Its open source and we slapped it on some cheapo v-server which cost a few bucks per month. That thing swallows like 150 messages a second and finding things takes no time at all. And if need be we can scale it to whatever is needed.

</comment><comment><USER38> You'd be much better off with an FSA or (honestly) Boyer-Moore implementation. For a baseline, a simple fgrep should show you FSA speed.

You might want to read about classical string search algorithms. Your naive algorithm is straightforward but far from ideal.

</comment><comment><USER39> "But isn't transient log storage a popular use case, and if so why don't any services optimize for it?"

Well I could start with "define transient"! I also note your unhappiness with third party logging facilities. I also note you went very DIY.

A three node ES cluster with a Graylog on the front can ingest quite a lot of logs for a reasonable time outlay in learning how it hangs together. A bit of tuning might be required.

I suspect I'm not your target market.

</comment><comment><USER40> The Ruby implementation looks wrong. He's shoving the file into an array:

      contents = contents.read.each_byte.to_a

When really he should be streaming each byte from the file. I suppose he should do that for all of the implementations (or just use grep & cat?), but Ruby objects are annoyingly expensive since there's so much bloat.

</comment><comment><USER41> So, if this is to measure the relative speed of a naive algorithm across multiple languages then great. If this is an attempt to measure how fast a single cpu can scan memory for a string then there are better algorithms. This is just one: [1]

      [1] https://en.wikipedia.org/wiki/Rabin%E2%80%93Karp_algorithm

</comment><comment><USER42> Golang single core version:

        if (b[n]) == (find[found]) {

Isn't indexing an UTF-8 string "find" O(n)? To get 10000th char, you need to iterate all 9999 previous characters first.

Edit: Clarified I'm talking about string "find" and not byte array "b".

<comment><USER43> I don't know Go, but b and found appear to be byte arrays, not strings, which would imply O(1) indexing.

<comment><USER42> Single core version:

      find := "07123E1F482356C415F684407A3B8723E10B2CBBC0B8FCD6282C49D37C9C1ABC"

That's definitely a string.

Otherwise (single core) golang code seems to be just a test whether the compiler is smart enough to remove branch in this code:

        if (b[n]) == (find[found]) {
          found += 1
        } else {
          found = 0
        }

I wouldn't be too surprised if golang compiler generates superfluous range checks costing even more performance. At least golang 1.4 seemed to generate a lot of unnecessary checks in code I optimized a few years ago. Hopefully newer versions are better.

<comment><USER43> yep, my mistake - was looking at multicore

</comment></comment></comment></comment><comment><USER44> [https://lists.freebsd.org/pipermail/freebsd- current/2010-Aug...](https://lists.freebsd.org/pipermail/freebsd- current/2010-August/019310.html)

How to really do it.

</comment><comment><USER45> Using the same algorithm I got 0.175 or so seconds in Java.

Sample code: [https://pastebin.com/duYF2QfE](https://pastebin.com/duYF2QfE)

This was on a "Early 2015" rMBP with a 3.1 GHz i7.

<comment><USER42>
      if (data[i] == strArr[found]) {

Shouldn't that be:

      if (data[i] == stringToFind.codePointAt(found)) {

... if you claim to use the same algorithm. That's what golang needs to do to index a UTF-8 string, right? (Comparing to golang single core version.)

That way both golang and Java will be performing proper unicode code point indexing.

Of course the optimization you made makes sense, but I think it'd be fair for the golang version to do same.

</comment></comment><comment><USER46> I wonder how long a simple grep over a 200MB file takes on linux. I guess if you put the 200MB file on a ramdisk then you could easily do it from memory.

That would be my first and dirty approach.

</comment><comment><USER47> I'm kinda surprised this task isn't limited by RAM or IO. There should be no benefit of multi-threading except for blocking I/O.

</comment><comment><USER48> For such a simple problem you should be shooting for about 25GB/s on a modern Intel CPU. Anything less is a disgrace.

</comment><comment><USER49> we use elasticsearch and it is pretty fast</comment>


Linus Torvalds: Successful projects are 99% perspiration and 1% innovation - <AUTHOR> http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/ <comment><USER3> Chris Anderson: So you spoke to me last week about these two guys. Who are they and how do you relate to them?

Linus Torvalds: Well, so this is kind of cliché in technology, the whole Tesla versus Edison, where Tesla is seen as the visionary scientist and crazy idea man. And people love Tesla. I mean, there are people who name their companies after him.

The other person there is Edison, who is actually often vilified for being kind of pedestrian and is — I mean, his most famous quote is, "Genius is one percent inspiration and 99 percent perspiration." And I'm in the Edison camp, even if people don't always like him. Because if you actually compare the two, Tesla has kind of this mind grab these days, but who actually changed the world? Edison may not have been a nice person, he did a lot of things — he was maybe not so intellectual, not so visionary. But I think I'm more of an Edison than a Tesla.

[http://www.ted.com/talks/linus_torvalds_the_mind_behind_linu...](http://www.ted.com/talks/linus_torvalds_the_mind_behind_linux/transcript?language=en)

<comment><USER4> Tesla worked for Edison and was a person who could finish things and some of them changed the world. He was _also_ person with vision, so I think Linus is either wrong or he is trying to put emphasis only on hard work. What if you have person like Tesla with both qualities?

<comment><USER3> I agree -- you need a little bit of both qualities. The vision of what to create and the execution to carry it out. The two go hand in hand. I think Linus is putting the emphasis on hard work because we mere mortals aren't endowed with the same genius that Tesla had and for us, the best way to achieve something great is through hard work instead of "divine" inspiration.

<comment><USER5> The Chinese made a whole industry out of executing without visionaries. It's called cloning products of visionaries. Or slightly improving them based on marketing feedback.

<comment><USER6> > _The Chinese made a whole industry out of executing without visionaries. It > 's called cloning products of visionaries._

That's how the US got its start too. In the 19th century still, most inventions were from Europe (England, France, Germany, etc), from the steam engine to the refridgerator, and from the radio to the internal combustion engine, cinema and photography. All European inventions.

<comment><USER7> And the Japanese post-WW2. Toyota was considered to be the poor man's Ford until at least the 1970s. Samsung and LG were mocked as artless copiers of Sony/Panasonic/Pioneer products as recently as the 90s.

</comment></comment></comment></comment></comment></comment><comment><USER8> I think we're all reading lots of different things into what Linus said here. My interpretation is that he's just saying that we tend to overvalue ideas and undervalue the less glamorous work involved in bringing those ideas to fruition.

The Tesla vs. Edison narrative is always couched in terms of the idea guy vs. the more pragmatic (perhaps more business-oriented) guy, not unlike the popular Woz vs. Jobs narrative, or the Jobs vs. Gates narrative in the '80s. These are popular narratives and archetypes that reflect the people involved, but can lead people to mythologizing history rather than understanding it.

In a different field, Lennon vs. McCartney.

So, among my peers at least, conventional wisdom is that Tesla was 100% an amazing visionary and got screwed over by unfair forces of history, and Edison was the villain whose contributions are overrated by historians. There's some truth there, but more than anything else it's a historical narrative where people are slotting Tesla and Edison into archetypes.

When a lot of people talk about Tesla vs. Edison, they're really just talking about those archetypes, and revealing to what degree they value inspiration vs. perspiration. I _think_ that's all Linus is doing here, saying that in his mind perspiration is undervalued and inspiration is overvalued among his peers. I don't think he's really trying to make a historical argument, which is what a lot of the commenters here are assuming.

<comment><USER9> I agree with your interpretation, "he's just saying that we tend to overvalue ideas and undervalue the less glamorous work involved in bringing those ideas to fruition."

I would also add, Torvalds is an enchanted unicorn from a resume perspective, it's not like he has followed a typical FOSS career trajectory, so seriously, _what does he know_ \--> that you can put to use? It's like a beautiful young woman telling you how you can get just a warning instead of a speeding ticket next time, _just do what she does_ (except if you follow Linus's lead you will definitely get the speeding ticket)

Humans have a built in instinct to follow great leaders, but if you are not a great leader yourself, emulating them might not actually work for you.

I have tremendous respect for Linus and for the HN community; I'm just saying, let's use critical thinking. There are plenty of successful super lightweight coding projects; he works on kernel level OS for a huge legacy of hardwares; he already was first to market, you still need to be, it's always tradeoffs. Borrowing/paraphrasing an idea from finance or population genetics, _maybe the world is the way it is because that 's the right mix_, why believe you know a better way to a greater extent than your already believing so is already part of the right mix?

so, I'm not saying don't think, reflect and improve, I'm saying don't throw yourself into these debates all on one side. One size doesn't fit all.

<comment><USER10> Then he wrote git and hit the doubt out of the ball field. This may be an anomaly, but he is behind one of the most successful large projects in the history of software engineering. It's an insult to say 'enchanted unicorn'. It makes this sound like luck. That is exactly what he is saying is bullshit.The difference between some great lightweight projects and the Linux kernel is not linear. There are almost no other projects that are as complex.

</comment></comment></comment><comment><USER11> It's funny how he says "Don't do this big 'think different'... screw that", apparently without realising that Apple did exactly what he's talking about. Almost all of Apple's big innovations were stolen from other places, and then they shut up, and got to work : making it work properly, making it user friendly, making it sexy, and then selling it.

Apple's slogan may have been "think different", and they have the image of being radical innovators, but hardly any of their innovations actually originated with them. Apple is 99% perspiration and 1% stealing good ideas :-)

There's even an infographic : [http://mashable.com/2012/10/27/apple-stolen- ideas/#Fs4Q5gSS....](http://mashable.com/2012/10/27/apple-stolen- ideas/#Fs4Q5gSS.ZqF)

<comment><USER12> For me the word "steal" in "Good artists copy, great artists steal" quote always meant: make it that good that the public will think it was always yours. The origin does not matter, because reality for people is what they believe in. If you will execute it better than anyone else it will be considered "yours".

Edit: At the same time there are also few options to make people believe it's yours beside exceptional execution, but that's not what the quote is about.

<comment><USER13> I like this. Build it so well the customers won't suspect a thing and will think you're the original creator. In a way, this is "fake it 'till you make it... the best version ever."

Apple is going to steal all the thunder again, this time in AR/VR, isn't it.

<comment><USER14> Hard to say. I can't shake the feel that that the consumer electronics Apple that we have come to know this last decade or so came down to them making products for one man, Steve Jobs. The iPod was basically tuned for his ears for one thing. If he didn't want to use it, never mind be seen using it, it didn't make it to the stores.

</comment></comment></comment></comment><comment><USER15> I deeply respect and admire Torvalds, but in the corporate world, the hypey/trendy thing helps tech people getting important changes approved by upper management, at least in my experience. I work in a tech company whose culture is primarily driven to productivity (read: getting business features delivered using the established stack and tools, as quick as possible). There is certainly an upside to it, but it produced a mindset in wich, in the face of a new problem, developers didn't even think of the possibility of bringing another tool to the toolbox. I mean seriously, to the extent of building their own xml parsers. Only recently we have been able to assemble an architecture team (i know, i hate the concept) to actually find adequate solutions to the bigger issues, and the hype is sometimes a powerful enabler to push things forward.

<comment><USER16> Traditionally big corporations, or anybody with legacy systems, are very conservative with technology choices...

<comment><USER17> It's a good thing. Imagine if they built something with Angular Material Design or Material Design Lite, for example.

</comment></comment></comment><comment><USER18> The strong words of the title are not the relevant or interesting part of the article (presumably of the talk also). The success in managing the network of kernel collaborators seems to be the real story here.

 _" It's a social project," said Torvalds. "It's about technology and the technology is what makes people able to agree on issues, because ... there's usually a fairly clear right and wrong."_

EDIT: Just for context, HN thankfully edited the title. When I wrote this the post was using the article's title: "Talk of tech innovation is bullsh*t. Shut up and get the work done – says Linus Torvalds"

<comment><AUTHOR> I preferred the original title. But I agree that the main point of the article is Linus' efforts in mastering (collaborative) process.

</comment></comment><comment><USER19> I like the header and experimented with current trends:

\- Talk of AI is bullshit. Shut up and get the work done.

\- Talk of Machine Learning is bullshit. Shut up and get the work done.

\- Talk of VR is bullshit. Shut up and get the work done.

\- Talk of Smart Contracts is bullshit. Shut up and get the work done.

\- Talk of IoT is bullshit. Shut up and get the work done.

Not sure if I entirely agree with him but there's some truth.

<comment><USER20> Blockchain is missing.

<comment><USER21> I assumed that Smart Contracts are built on top of the Blockchain.

</comment></comment></comment><comment><USER22> Upvote 1000x - I'm sick of hearing people who've done nothing and "thought leaders" ranting on. I'm pleased I put my head down, did work and did something that worked for me that I can encourage others with and give evidence. I wish those who have done nothing would go away - and stop filling my inbox, and targeted advertising spots, and meetups with their crap. I wish I could help others see over the shouting and point to what does work instead of seeing them fall for the hype every time.

<comment><USER23> 'Thought leadership' is about being honest about what's happening and expressing this. Giving a voice to SMEs about what they're doing, why they're doing it, and where they think this will go; it is ideal Agile, constituting the combination of thoughts from technology, leadership and subject matter expertise. A credible message which parts on their own cannot communicate. Some organisations do this very well.

When it goes wrong is when it becomes sales led.

> I wish I could help others see over the shouting and point to what does work > instead of seeing them fall for the hype every time.

That's the point of thought leadership vs sales. What you complain of is people using the term under the guise of sales.

<comment> aaron-lebo _' Thought leadership' is about being honest about what's happening and expressing this. Giving a voice to SMEs about what they're doing, why they're doing it, and where they think this will go; it is ideal Agile, constituting the combination of thoughts from technology, leadership and subject matter expertise. A credible message which parts on their own cannot communicate. Some organisations do this very well._

I don't want to be a dick but you've summed up what's wrong with 'thought leadership'. If thought leadership consists of a bunch of buzzwords that everyone else is using, you aren't a leader, you are a follower.

It's a business in and of itself; there's no correlation between 'thought leadership' and success. Of course the traveling preacher would want you to think there is.

<comment><USER23> You're not being a dick, I completely concur. HN itself is an example of what thought leadership can be, but would hate to be labeled with the tainted brush the term has come to stain.

</comment></comment></comment></comment><comment><USER24> Someone who should be a multi billionaire says to ignore marketing and sales and just work.

Edit: I'm not saying that he WANTS to be a multi billionaire, but the fact is that he has attained disproportionately less value than he's created. By rights he should be one of the wealthiest people in tech. He might have 150m but that's peanuts given what he's done. The wealth of the guy who made Instagram dwarfs that. The guy who made Whatsapp has a net worth of 8b.

Creation might be 90% perspiration as he says, but perspiration doesn't equal success, and success doesn't equal a career. Obviously everything isn't about money, and Torvald's legacy will be timeless. But if you want to ensure earnings, at some point it's a good idea to sell.

<comment><USER25> You somehow make it unclear whether or not Linus not being a multi-billionaire is a good or a bad thing.

Are you saying that because he didn't try to monetize his code as much as he could have, it somehow makes his opinion less valuable?

The man created Linux AND git, it doesn't matter whether or not he's got billions. He's got something more important than that, a legacy.

<comment><USER26> > He's got something more important than that, a legacy.

Why is that important?

<comment><USER25> In my opinion, a legacy like that of Linus means that he's produced a piece of software that has positively impacted the lives of people.

It's important because he's actually delivered on the famous SV con-artist promise of "making the world a better place".

Not directly, as in curing diseases or revolutionizing energy production or consumption, but in ways that help people in developing countries access information due to falling costs of computers (Linux) and phones (Linux through Android) and people in business can thrive because of the diversity it brings to the table (versus the Microsoft quasi-monopoly we had before).

That's what I put under the umbrella term "legacy", something that has, in a way and ever so slightly, changed the world for the better.

Then again, we might say "it's just software", but in a software-centric world, I reckon it does matter.

<comment><USER24> Positively impacting lives is surely important.

That's besides the point. My point is that working without selling is not a viable strategy for 99% of people. Hell it barely worked for him in terms of earnings, and he's one of the most impactful people in tech history.

<comment><USER25> It's not besides THE point, it's besides YOUR point, big difference.

Suppose that what matters is to monetize your work. Then by that metric, Linus is immensely successful (personal worth of over 100 million dollars, which likely puts him in the high brackets).

Now suppose (like I do) that the metric that actually matters is sharing the result of your work so that others will build upon that and end up creating even greater things. Well, by that other metric, Linus is still a HUGE winner.

So we're basically both right (unless of course we're ready to discuss obvious falsehoods such as "Having 100 million dollars means it barely worked for you").

</comment></comment></comment></comment></comment></comment><comment><USER27> > Torvalds said he subscribes to the view that successful projects are 99 per > cent perspiration, and one per cent innovation

Certainly true. IMHO, innovation is about orientation, while perspiration is about walking. They live in different timescales: GTD takes time while innovation is a spark. However, both are equally important: it would be useless to go forward in a wrong direction, it would be useless to identify a meaningful direction without going forward, and it would be of course useless to walk backward.

An acceptable - and subjective ! - balance is hard to find, these days.

</comment><comment><USER28> It takes all kinds. I say this seriously and without intent to offend: it's good to have a grouchy curmudgeon in the industry to keep us grounded.

<comment><USER29> Thank goodness for that one specific grouchy curmudgeon, otherwise there would be no grouchy curmudgeons and we'd all live like Eloi and waste the days away braiding each others hair :)

</comment></comment><comment><USER30> Invention, my dear friends, is 93% perspiration, 6% electricity, 4% evaporation, and 2% butterscotch ripple.

<comment><USER31> "That's 105%!" \- Mrs. Teevee

</comment></comment><comment><USER32> The OpenBSD folk have a similar (and surprisingly polite) motto of "Put up or hack up" which I've always been fond of.

</comment><comment><USER33> In the context of consumers, no one wakes up and thinks, "I gotta buy me some innovation today." NO. ONE. People just want their problems solved. _That_ is the target. Sure, innovation might be part of the means, but innovation is not an ends (as it's often framed to be).

p.s. As a side-snark...Enough already about all these various dev technologies. So they enable still-shitty user experiences? So what. No one says, "Oh. I love they use _____."

Users. Don't. Care.

So please, for the love of God & country, stop stroking yourself with your shiny new (dev technology) object. No one cares. The technology is a means. The experience is the ends. Stop focusing on the wrong problem. Please?

</comment><comment><USER34> This is a social political problem especially with 'exceptionalism'. People adapt to the environment they are in, that's one thing human beings are good at.

In the US there is intense pressure right from school to colleges to work to be 'exceptional', and to be recognized and celebrated for it.

There is nothing necessarily wrong, excellence is worth pursuing and to have individuals believe they can achieve it. But there is a huge difference between motivation by passion and interest and motivation by social recognition and celebration.

There are pitfalls and side effects in a society from a toxic focus on 'winners' and 'losers', constant judgement, politics and one upmanship, the ability of people to work together without the need for self congratulation and diminishing the collective. It takes a village and all.

Excellence always comes through, you don't need to do anything special, individuals who are brilliant will always shine in a self evident way without labels or self congratulation via their work, throughout history and now and in the future.

But you can't progress alone, progress comes from a generational interlinked collective, and there is huge risk of diminishing the collective and brushing every other factor under the carpet by an extreme focus on individuals.

</comment><comment><USER35> This is one of those statements that end up being understood in slightly (but significant) different ways based on one's own experience.

</comment><comment><USER36> Good grief, not that again. One of Edison's contemporaries said that Edison would have found a working lightbulb faster if he had put more thought into his investigations.

What works for me is a series of plan -> do -> review sequences with about 10 to 15% planning, 80 to 85% doing and 5 to 10% reviewing.

</comment><comment> happy-go-lucky > "All that hype is not where the real work is," said Torvalds. "The real work > is in the details."

That's where the real work is, in the details. I respect those who walk the talk and he's one among them.

</comment><comment><USER37> Genius is one percent inspiration, ninety-nine percent perspiration. - <USER2> Edison

It's not so original and it sounds like it was copied/pasted from an old quote 100 years ago

<comment><USER38> Linus literally talks about Edison and that quote in the article

</comment></comment><comment><USER39> wrt the rewritten HN headline, I've begun to prefer a different quip also attributed to Edison—

"Opportunity is missed by most people because it is dressed in overalls and looks like work."

+1 for that take on innovation.

</comment><comment><USER40> I would look at it as the Zeno's arrow paradox. 99% perspiration could be again broken down into 1% inspiration/innovation, and 99% perspiration, and so on...

We need innovation simply because its fun.

</comment><comment><USER41> Is it just me, or is this a predictable answer from someone who works exclusively on an operating system? There is no innovation needed in his job, everything has already been made by MS, Apple etc, he just has to take existing ideas and fit them into Linux. Or even write the code that glues pieces together.

Now ask someone in the VR/AR department. Everyday they have to think up is new 'innovative' ideas because they are on the bleeding edge. We know innovation is needed because so far not everything is working.

What about Neural Nets, where there have been a lot of innovations to get from one one 'neuron' to what we now call deep learning. And the list goes on.

<comment><USER42> Invention and innovation are two different things that get conflated together frequently, but innovation doesn't necessarily mean you have to come up with something from scratch, but it does mean that you'll have to improve something. Maybe it's more like all (successful) inventors are innovators and some innovators are successful inventors. Sometimes it is the execution of the invention that was done wrong rather than the concept itself - there's absolutely value to society there. People get PhDs for finding commonalities across different disciplines and uniting them under common terms. Hence, because of the massive surface area of what constitutes innovation compared to invention, business people and others with more visibility are typically "innovators."

</comment></comment><comment><USER43> Of course he says that. His project was a clone of something that already existed, Unix.

</comment><comment><USER44> It's 99% luck, 0.99% perspiration and 0.01% innovation.

</comment><comment><USER45> Yoga is 99% practice and 1% theory. – K. Pattabhi Jois

</comment><comment><USER45> Yoga is 99% practice and 1% theory. K. Pattabhi Jois

</comment><comment><USER16> Trust is earned, Linus is right.

</comment><comment><USER46> can 99% perspiration be automated with 1% innovation?

</comment><comment><USER47> Hear hear! Linus really is the patron saint of grumpy, cynical engineers. There's nothing more frustrating than listening to the bullshit artist spin castles made out of air, knowing that you're the poor son-of-a-gun that's going to have to do the hard work to make it actually happen, and get blamed when reality intrudes on the grand vision.

Also closes with a great quote. Code is easy, it's either right or it's wrong. People are the sticky wicket

> It's almost boring how well our process works," Torvalds said. "All the > really stressful times for me have been about process. They haven't been > about code. When code doesn't work, that can actually be exciting ... > Process problems are a pain in the ass. You never, ever want to have process > problems ... That's when people start getting really angry at each other.

<comment><USER48> "Also closes with a great quote. Code is easy, it's either right or it's wrong. People are the sticky wicket"

When I read that I got the feeling that people were thinking to themselves "it either executes or has an error," but that is certainly not the case when Linus deems code right or wrong. Obviously not executing is an automatic disqualification.

Two patches can correctly execute and achieve the same goal, and yet one will be deemed "brain dead" and "moronic" and the other be deemed "right," solely on the subjective whims of Linus. Totally his prerogative, and I have no issue with it.

But don't think for a minute that code is "black and white."

</comment></comment><comment><USER49> Ja cause if you tried 2% innovation you'd need 198% perspiration to go with it.

<comment><USER50> Wisdom

</comment></comment><comment><USER51> Fuck yea.

</comment><comment><USER52> linus troll status = epic</comment>


Motivational posters with a designy twist - <AUTHOR> http://deptofmotivation.com

<comment><USER2> It may be a cultural thing but I rarely find this style of poster motivating. More often I find it demotivating that an employer or co-worker has the gall (or perhaps naivete) to expect to influence my personal motivation through an arbitrary aphorism pinned to the wall. I enjoy witty and insightful as much as the next person but would not wish to work at a place where truisms decorate the halls. I'd rather have scenery and nice paintings, thanks all the same.

</comment><comment><USER3> Ask HN: Can I have $75 of your money?

</comment><comment><USER4> This is exactly what I need to fix the lack of meaning in my job! I know I'll be a top performer soon.

</comment><comment><USER5> What's the twist here?

<comment><USER2> Apparently the twist is designy.

</comment></comment><comment><USER6> These are excellent. I especially like the first one.

</comment><comment><USER7> Where is the design?</comment>


Entrepreneurial Rails developers wanted - <AUTHOR>

We're looking for some talented Rails developers to help maintain and grow a start-up idea / social experiement <comment><USER2> Your post is incredibly vague. People here love details.</comment>


Launch HN: PullRequest (YC S17) – On-Demand Code Review - <AUTHOR> Hi! I am Lyal Avery, founder of PullRequest (https://www.pullrequest.com) - we're currently in the YC S17 batch. PullRequest is offering code review as a service.
We built PullRequest to help developers.  After waiting several days for feedback on a pull request while a colleague was on vacation, I knew there had to be a way to improve this process.  Our mission is to improve code quality and save time for dev teams. We combine static and linting tools with real on-demand reviewers to help augment your current code review process. Dev managers like extra coverage, but our real intent is to free up developers to make better software more efficiently
We're onboarding experts across a lot of different languages for this reason.  Sometimes teams might only have one person working within a given framework/language – it can be difficult to get objective feedback before shipping to production if you're working on an island.
All reviewers sign NDAs to protect your IP.  We start with surface level reviews – complying with framework or language standards, algorithmic work, performance or other questions.  Since our reviewers continue working on the same projects, they will also gain context for deeper reviews.
Looking forward to hearing your thoughts and feedback! <comment><USER2> I am skeptical that this can work well.

Having deep understanding of the code in question is essential for a good code review. Not just the code under review, but the wider scope of the project. This helps spot architectural problems, inconsistencies, unearth hidden assumptions or assumption breakages, and the like.

Reviewing the code as a drive-by loses all of those benefits and boils down to focusing on the code at hand, coding style, nitpicks, and implicitly assuming the code fits well with the rest (enforcing consistent coding style and pointing out code smells is certainly useful, these however can be automated to some extent by linters and services like CodeClimate).

I have been a reviewer in hundreds of pull requests, and reviews I've done where I have been intimately familiar with the existing code base were consistently much better than the reviews I did as an outsider to the project - even when, knowing this, I spent a lot more effort on the reviews as an outsider.

The founders seem to recognize this (it's mentioned in the TC article) and mention pairing up reviewers with the same companies, but this IMHO will not be enough, unless these reviewers are basically on retainer and work regularly, and often, with the same company.

I'd love to be proven wrong, so good luck PullRequest team!

<comment><USER3> There are plenty of ways to significantly improve a codebase through review besides deep sweeping architectural changes. As you know, the goal of a review varies widely depending on how big the project, its maturity, how many people contribute to it, etc.

Things like not know about certain shortcut functions in the standard library, improving design pattern usage, docstrings, and otherwise improving modularity, decomposition, cyclomatic complexity, consistency, etc. Code Climate goes far but doesn't do all of these things as good as an experienced engineer.

</comment></comment><comment> git-pull This looks like something that could catch on, especially if you're already compartmentalizing projects into libraries, that alleviates a lot of hesitation in sharing a codebase. It's good to see that NDA's are involved as a layer of protection.

There are things that a human can suggest that computers can't. Such as a refactoring suggestion.

Here are a few ideas:

\- Consider adopting a standard like EditorConfig ([http://editorconfig.org/](http://editorconfig.org/)) for reviewers to have compliant indentation out of the box

\- For Enterprise packages: perhaps there can also be an opportunity to sub- contract out features and write tests?

\- Consider experimenting internal CI tools (like as done in open source projects) to scan for obvious/low-hanging fruit automatically

\- Scanning for / suggesting package updates

\- Provide QA / audit for a large open source project for exposure

\- Security auditing

Here are things that are good to hear:

\- Static / Linting: things like vulture, flake8, etc. seem like a nice thing to stick to. It's good that these linters have configuration files to it

<comment><AUTHOR> Thanks much! A lot of good notes; some initial reactions:

Completely agree re: editorconfig. Very necessary to prevent bikeshedding. We're actually building a dedicated review IDE.

Part of our roadmap is to offer open source projects code review -- not just for exposure, but to work with reviewer standards on.

We're definitely interested in security review.

</comment></comment><comment><USER4> I am very skeptical about this service. Aside from cosmetic changes (which should be automated anyway) code reviews are better served by people who know intimately the problem we are trying to solve. Some code could look pretty neat (and pass the review) but still overall would be a mistake to have it.

<comment><AUTHOR> Appreciate your view. I think for teams with strong code review practices, we make sense as extra eyes rather than full replacement.

Edit to expand:

We also believe that reviewers attached to projects will gain context quite rapidly. We had a reviewer catch an edge case bug for one of our teams that had gone unnoticed by internal review. Economic side of this would have been large... but was only possible through the context they gained in previous reviews.

</comment></comment><comment><USER5> Roughly speaking, I think there are 3 aims for code review:

1\. Style/consistency, re-use of existing code, utils, etc.

2\. Architecture/design, how does this fit into the rest of the codebase, scaling concerns, how will the deploy work, will this have race conditions, etc.

3\. Knowledge sharing with other members of the team.

Currently, it looks like this would satisfy half each of 1 and 2, but will miss the (possibly large) amount of context that people working on the project have. To be honest, I don't know how you solve that. How does a reviewer who lacks knowledge about the codebase spot a common pattern and know that another dev abstracted that out into a util a few weeks ago, for example.

I also wonder what could be done to address (3). I've seen the team I work on go from a place where everyone could review everything to a place where I can't review all the code that goes live, and particularly after time off, I can't really catch up. I'd love to see some sort of automated changelog of useful notes on what has changed. I'm not sure if this is possible, but summarising merged PRs, highlighting config changes, showing new utilities that have been added, etc, would be quite valuable.

<comment><USER6> To me, code style should not be part of the review process. This should be automated away [https://blog.alt-three.com/code-reviews-are-not-about- coding...](https://blog.alt-three.com/code-reviews-are-not-about-coding- standards/)

<comment><USER5> I completely agree, we actually use linters to automate a lot of this, but there is a class of things that linters have a hard time with, like naming, or re-use of existing design patterns or utilities.

<comment><USER3> Especially true in dynamic languages like Python.

</comment></comment></comment></comment><comment><USER7> Seems like a good idea, but I wonder about the true quality of the review? In my experience, only a true team member who's familiar with the project (i.e. has actually been working on it) can provide a quality code review. Beyond that, they're just looking at ways to optimize blocks or find weird bugs in non-breaking recursive lines...

<comment><AUTHOR> Great insight. Definitely something we are tackling. For once off reviews on an individual pull request, it can be challenging to do anything but surface review. As a result, we're building some summarization tools to help provide context rapidly to a reviewer. Over the lifetime of a project, we have reviewers assigned to the same projects so that they build up context, in the same way that team members do.

<comment><USER7> That's great :). Most problems worth solving aren't easy by any means. This could be a huge market if you do it right!

</comment></comment></comment><comment><USER3> I'm a huge fan of static analysis and code quality, and am really excited to see where this goes.

It would be nice to see a demo video before giving full access to my private repos.

> Pricing > Standard starting at $49 per month*

> * Billing is dependent on amount of meaningful change per month. $9 per user > per month for static analysis.

This metric is pretty unclear. Does this mean hourly billing based on reviewer time? Are there tiers or an upper bound? Is there a different tier for open source? Is the pricing different for surface vs deep reviews?

As one of those weird people that thinks doing code reviews and managing code quality is really fun, if I wanted to become a reviewer, what's the vetting process like?

Can you elaborate on, besides involving humans, how the underlying service is different than Code Climate, Codacy, etc?

P.S. Found a small bug on your dev signup form which I reported on Twitter. It would be awesome to be able to help review PullRequest using PullRequest ;).

<comment><AUTHOR> Great catch! Thanks, replied on twitter - we're dog fooding our own product, so as a reviewer, you'll definitely see our code in the review queue.

</comment></comment><comment><USER8> My suspicion is this:

All the issues someone with no familiarity of the code base or the problem could typically uncover are things that are prone to be automated away by software in the long run (or are already in the process of being automated).

<comment><AUTHOR> I think that's a natural place where our tooling will evolve to - a lot of things that aren't caught in an automated way, after being trained with real review, will. There's no replacement for the human component of review though, and we believe that by allowing reviewers repeated access to the project, that they will gain the context necessary.

</comment></comment><comment><USER9> I would love this as an individual when learning new languages on my own projects. I find it really hard to tell if I'm actually doing things the "right" way without talking to someone more experienced.

<comment><USER10> yes this is a good thought. I wish they had a free tier for this purpose. 1 review a month or something.

<comment><AUTHOR> We would love to offer one review a month - unfortunately, because there are humans on the other side of the review, it's harder to do this than for a straight SaaS operation.

We'll definitely have free tiers for our static and instrumentation product though.

</comment></comment></comment><comment><USER11> Awesome idea, just signed up to help out and review code! Is there an incentive / gamification system to reward strong reviewers so their reputation increases as they provide good feedback to companies?

<comment><AUTHOR> Thanks! We're still early in our life cycle -- but on the roadmap is the creation of reviewer profiles (as an optional feature). This'll allow us to highlight strong reviewers, their projects, etc.

Incentives and gamification are definitely there as well. We want to bonus people for doing thoughtful code review.

<comment><USER12> This is a big opportunity to create an entirely new specialized role. Could be very lucrative for people to make names for themselves.

<comment><AUTHOR> Completely agree! The idea of a 10x reviewer has been a big part of my thinking on creating this company (and the movement of specialization for review out of big tech companies into smaller engineering teams).

<comment><USER12> Great idea. Admittedly, I didn't get it at first, but I'll be watching your progress now that I see it. Good luck!

</comment></comment></comment></comment></comment><comment><USER13> ___All reviewers sign NDAs to protect your IP._ __

How does your company back this up? What happens if one of your Developers violates this? Will you pay for the legal fees?

<comment><AUTHOR> We're still exploring the landscape on this. At the core, we're hiring reviewers in jurisdictions that we have presence for (currently North America), and they are signing a 3 way agreement with the company under review. This offers the same level of protection as a traditional consultant in terms of protections.

</comment></comment><comment><USER14> Do we expect them to provide feedback like "this algorithm is not right because XYZ" or "I fixed this algorithm to work correctly". Those are very different levels of service and I think defining exactly what someone should expect will really helps set expectations.

I also think that this seems absurdly cheap, and I can't imagine it scaling with quality reviewers. Would love to be wrong on this one.

<comment><USER15> Thanks for the feedback! I think you are right that we should add more expectations/FAQ section to our website. We expect the feedback to be more of the former, suggestions and comments but still up to the code author to correct and implement. Re: pricing: we are still working out the details of pricing but we believe that we should be able to get quality reviewers at this price. We expect our reviews/custom review client over time to help increase our efficiency to drive costs down.

</comment></comment><comment><USER16> I like this idea, it seems useful for all the ways described. My skepticism comes from the reviewers themselves. I think they will have a hard time attracting and keeping top talent who can provide high-quality reviews as such talent will want to be creating code, not only reviewing it. I'm not sure how they would resolve this.

<comment><AUTHOR> Review offers flexiblity that other forms of contracting don't - there's no project management, client negotiation, etc.

</comment></comment><comment><USER17> Very interesting. What are your thoughts about independent developers using this as an education tool? It would be really nice to get external input on projects I'm using to teach myself new technologies and patterns.

<comment><AUTHOR> We have a few folks that have signed up for just this! I think it's a neat concept.

<comment><USER17> Took another look at the pricing page and saw "billing is dependent on amount of meaningful change per month. $9 per user per month for static analysis."

Does that mean I could expect to pay < $49/mo for a learning use case? These projects don't move to quickly, so I envision using static analysis extensively, then getting a more complete review 1-2 times a month.

Might be worth clarifying the pricing description.

<comment><AUTHOR> Thanks for the insight. We'll definitely be clearing up the pricing packages.

</comment></comment></comment></comment><comment><USER18> I am very interested in a product like this even if for just individual use. Your pricing says $49/month depending on "meaningful" changes suggested? What does that mean?

Another good idea is for new programmers in a production environment just having an eye over their shoulders making sure they aren't making rookie language mistakes (simpler ways of doing etc.). Letting official company engineers focus on architectural/roadmap related issues.

This, to me, would be the fastest way to learn as well.

<comment><AUTHOR> We price based on the amount of review being done per month. $49 is the base threshold; individual reviews can vary based on the amount of code being reviewed at once. We're figuring out the exact pricing model for individuals and teams that'll be easily communicable.

</comment></comment><comment><USER19> Dang. One of the most painful things to do in this field, is dig through someones code. I don't even like figuring out MY old code. I'm surprised reviewers are voluntarily submitting themselves to this torture :D Cool program though, hope it takes off for you.

<comment><AUTHOR> Thanks. Different people like different things - I absolutely love reviewing code. We're hoping that by letting people focus on what they love doing, teams everywhere will be happier and more productive.

<comment><USER19> awesome! dope domain too.

</comment></comment></comment><comment><USER20> What are the benefits of reviewers over automated testing?

My workflow (which I believe is pretty standard) is:

* Write code

* Verify that tests pass locally (including stylistic tests, linting)

* Submit pull request

* Pull request triggers build and tests on Travis

* If all tests pass on Travis, code is stylistically and functionally correct

* Merge pull request

How can human reviewers improve this workflow?

<comment><USER21> Those things have nothing to do with a PR, other than maybe a PR being a good way to say "this is done, let's automatically verify it".

A PR is about _showing_ the rest of the team the changes so more than one person knows how stuff work and what's going on in the code base. And for the rest of the team to give feedback on stuff like how the feature was architected, not to nitpick on indenting.

<comment><USER22> _A PR is about showing the rest of the team the changes so more than one person knows how stuff work and what 's going on in the code base._

But that's not really applicable here, right?

</comment></comment></comment><comment><USER23> Great idea! I agree that $49/mo is a bit steep if targeting startups. Though at the same time, each PR could easily take an hour to review so it could get time consuming fast. Is there any free trial?

<comment><USER22> To me, $49/m seems impossibly cheap for a service that requires quite specialized human skill, not to mention the vetting and risks inherit to handling IP from other companies. And I come from one of the poorer EU countries, not from SV.

<comment><AUTHOR> Yes; pricing starts at 49$ per month, but that would be for a single review.

</comment></comment></comment><comment><USER24> Congrats on building this product, guys. This tool is very interesting for startups that have only one developer and freelancers. However, a $49/month pricing may be quite expensive for these people.

<comment><AUTHOR> Thanks! Pricing is a place we're working out details. We'd like to offer lower tiers for individuals/freelancers in the future for our static and automated tooling.

<comment><USER25> From a business POV I'd wonder whether the RainforestQA model of much higher pricing ($10,000 per month) with a focus on highly parallel resource deployment (review a lot of code quickly) might be a better strategy.

</comment></comment></comment><comment><USER26> Do you pay reviewers? How much ?per review/hour, how's that work?

<comment><AUTHOR> We're trying out a few different models right now. Our goal is to make sure that developers are getting great pay and want to work with us!

</comment></comment><comment><USER27> This could work well for Ethereum smart contracts

<comment><AUTHOR> I agree - interesting landscape to play in.

</comment></comment><comment><USER28> You should edit the submission description to make [https://www.pullrequest.com/](https://www.pullrequest.com/) a clickable link. I've seen that done for other Launch HN submissions.

<comment><AUTHOR> Thanks! Updated.</comment></comment>


Post-Quantum Cryptography - <AUTHOR> https://pqcrypto.org/ <comment><AUTHOR> Thought this might be relevant given how many people in the following thread were surprised to see IBM's 50-qubit computer: [https://news.ycombinator.com/item?id=15671408](https://news.ycombinator.com/item?id=15671408)</comment>