Fast Fibonacci - <AUTHOR> http://www.nayuki.io/page/fast-fibonacci-algorithms

<comment><USER2> The Fast Fibonacci article links to an article on an algorithm called "karatsuba-multiplication". Oi - I just lost two hours of my life to reverse- engineering it. (But it was worth!). In case anyone else was wondering, here's what I got out of it.

      x*y =  (x)(y)
          // fragment into binomials
          =  (x/m*m + x%m)(y/m*m + y%m)     // uses integer division
          // distribute binomials
          =  (x/m*m)(y/m*m)  + (x/m*m)(y%m) + (x%m)(y/m*m) + (x%m)(y%m)
          // extract modulus from each term
          =  [(x/m)(y/m)]m^2 + [(x/m)(y%m)  + (x%m)(y/m)]m + [(x%m)(y%m)]
          // rename terms
          =  [A]m^2 + [B+C]m + [D]
          // where [A]   is what nayuki calls (a),
          //       [B+C] is what nayuki calls (a-b-c), and
          //       [D]   is what nayuki calls (c).
      Q.E.D.

Geometrically, what we're doing is:

1) taking the area of two binomials;

2) shrinking Quadrant A by a factor of the modulus's perfect-square (e.g. 3^2);

3) shrinking Quadrant B and Quadrant C by a factor of the modulus per se (e.g. 3); and

4) leaving Quadrant D the same.

      [B B B D D]  scaled by modulus  [B D D]
      [A A A C C]  </comment><comment></comment><comment>---->  [A C C]
      [A A A C C]  where m = 3
      [A A A C C]

<comment><USER3> You've left out the key observation that makes Karatsuba multiplication faster than naive multiplication: after having computed [A] and [D], we can compute the combined [B + C] with one multiplication rather than two. That is, to multiply two binomials of a given size, we only need three multiplications of binomials of half that size, rather than the naive four. This is what improves the runtime of Karatsuba multiplication to Ө(n^(log_2(3))) from the ordinary Ө(n^2).

Why are we able to get away with only three recursive multiplications instead of four? The observation here is that in the product (Em + F)(Gm + H) = EGm^2 + (EH + FG)m + FH, after the first and last coefficients EG and FH have already been calculated, the middle coefficient (EH + FG) can be calculated using only the one new multiplication in (E + F)(G + H) - EG - FH, rather than the naive two in its definition.

<comment><USER3> We can also view Karatsuba multiplication as a special case of a general class of polynomial multiplication algorithms (after all, numbers written in a particular base are just polynomials evaluated at that base). Naively, multiplying two polynomials of degree n takes (n + 1)^2 multiplications of coefficients, but a more clever approach would evaluate the two polynomials at a number of points, then multiply those values together, then fit a polynomial to the results. This involves only (2n + 1) multiplications (the number of values needed to determine the resulting polynomial).

Thus, our clever binomial trick is the observation that multiplying two polynomials of degree 1 yields a polynomial of degree 2, so we need to pick 3 points for our evaluation; if we pick the points to be 0, 1, and "infinity" (in the sense of a value such that P("infinity") = the leading coefficient of P, just as P(0) equals the degree zero coefficient of P), then we get our Karatsuba trick: we break (Ex + F) down into F, E + F, and E, and similarly for (Gx + H), then multiply the corresponding values together (our three multiplications), and from those results reconstitute the polynomial product we are interested in. (And we can apply this recursively to break down the multiplication of polynomials of greater degree than 1)

An even more clever approach notes that we can evaluate our polynomials at various roots of unity all at once very efficiently with the Fast Fourier Transform, which is what leads to the most efficient multiplication algorithms known.

</comment></comment></comment><comment><USER4> Interesting to see that "slow dynamic programming" which is the classic exchange-and-add algorithm is the fastest up to around n=126, at which point fast doubling with naive multiplication takes the lead, and Karatsuba multiplication needs n over 5000 before it becomes faster than the other methods. But, assuming that you can much more easily get an order of magnitude improvement out of the "simple and slow" method than the more complex ones, then the break-even point moves up to n=1260.

In other words, always choosing the asymptotically fastest (and often more complex - with larger constants) algorithms is a bad decision if most of your inputs never get large enough; simpler algorithms are good, even if they're not the theoretically fastest, because they also tend to be easier to optimise.

However, the recursive algorithm being faster than slow-DP until n=5 is a little odd... some other effect could be responsible for that.

<comment><AUTHOR> Optimizing on Big-O is always about working with interestingly sized data. If we're going to be doing lots of calculations and only talking about a limited range of possible values, memoization is asymptotically O(1) time.

</comment></comment><comment><USER5> A nitpick:

> If we wanted to compute a single term in the sequence (e.g. F(n)), there are > a couple of algorithms to do so, but some algorithms are much faster than > others.

If we wanted only a _single_ term in the sequence, we would just use the closed-form equation, which takes O(1) bigint arithmetic operations,

        F(n) = (phi^n - (-phi)^-n) / sqrt(5)
        (Where phi is the golden ratio.)

But if what's needed is the entire sequence F(0) up through a chosen F(n), then the algorithms in this article come in handy.

<comment><USER6> Regarding the computation of a single term:

No, the well-known Binet formula involving phi is unsuitable because it uses real numbers. See these detailed comments about handling quadratic surds properly, which is effectively the same as the fast doubling algorithm:

\- Chinjut: [https://news.ycombinator.com/item?id=9316574](https://news.ycombinator.com/item?id=9316574)

\- xyzzyz: [https://news.ycombinator.com/item?id=9316144](https://news.ycombinator.com/item?id=9316144)

Regarding the computation of F(0) through F(n):

No, this is not true either. The matrix method and fast doubling only compute O(log(n)) terms of the sequence, not the complete sequence from 0 to n.

<comment><USER5> Ah, right, I am wrong on both counts. Thanks for the pointers!

</comment></comment></comment><comment><USER7> Good stuff! I love Fibonacci algorithms and if you dig deeper, there are even faster algorithms that exploit even more identities like the fast doubling and look-up tables.

It's a fun recreational mathematics thing, but unfortunately I've never come across a problem where I need to solve Fibonacci insanely quickly. However I still keep my hopes up!

<comment><USER8> Just a guess, but it might be useful for fractal rendering. That's the only real application I can think of.

<comment><USER9> The techniques developed are useful in other areas. Eg Double_Cast talks about fast matrix multiplication above---certainly a useful technique elsewhere.

</comment></comment></comment><comment><USER10> Great writeup! I only wish the author had benchmarked the approximate algorithm with phi and floating points too, because it's often 'good enough'

        >>> fib = lambda n: 5**-.5*((.5+.5*5**.5)**n - (.5-.5**.5)**n)
        >>> fib(12)
        144.00138887270816
        >>> fib(250)
        7.896325826131797e+51

EDIT: Laughing, don't know why I called it factorial at first. Whoops

<comment><USER11> There is, actually, an even simpler formula.

While the explicit formula for the n-th Fibbonacci number is indeed F_n = 1/sqrt5 * [ ((1+sqrt5)/2)^n - ((1-sqrt5)/2)^n ] or F_n = (1.6180^n + 0.6180^n)/2.2361 you can notice that the -((1-sqrt5)/2)^n = 0.6180^n term tends to 0, and is in fact smaller than 0.5 even for n=2, which gives us an even simpler formula for F_n = ceil(1.6180^n/2.2361).

This would also take care of the limited precission of the float point numbers.

<comment><USER12> What do you mean, take care of the limited precision? The formula you gave is only correct for

        n = [1, 3, 5, 7, 9, 10, 11, 12, 13, 14, 15, 16, 17]

The reason the explicit floating point formula doesn't get used is because you need as many bits of floating point as you expect to get bits of answer. Which means that you get the wrong answer pretty quickly. If the goal was to calculate an approximation to the fibonacci numbers, sure, but then you don't need the (ceil) call.

<comment><USER11> Oh yeah you're right

Although, wouldn't variable overflow be the case for any algorithm, since already the 100th or so Fibonacci number takes more space than 2^64

And if you were to use the full float precision of sqr5 (and not just 4 digits like I did), you would run into 64bit float overflow way before that algorithm stops being accurate

<comment><USER13> Everything else is talking about bigints.

If you were dealing with fixed-length integers, just use a lookup table.

Also, you're wrong regarding floating-point. On my machine, fib(101) is off from your approximation by ~2 million (!). Well before hitting the limits of a 64-bit float. It starts erroring at n=71, and only gets worse from there. Worse, the relative delta grows as n increases.

<comment><USER11> Hmm ok

Thanks for actually testing it

<comment><USER13> Python is wonderful for that sort of thing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> It would be interesting to see what the asymtotic complexity would be in terms of number of (fixed-size) operations as opposed to number of bigint operations required.

I mean, the nth Fibonacci number requires O(n) bits to store.

<comment><USER14> It's O(M(n)) where M(n) is the complexity of the algorithm used for multiplying n-bit integers.

To see why, note that each step of the matrix powering or fast doubling algorithm 1) costs a constant C number of multiplications, and 2) roughly doubles the number of bits.

F(n) has b = O(n) bits, so the cost is essentially C M(b) + C M(b/2) + C M(b/4) + ... <= 2 C M(b) = O(M(n)), using the natural assumption that M(2x) >= 2M(x).

<comment><USER13> So then: is there any better solution? Or is that the optimal?

<comment><USER14> It's almost certainly optimal, but proving that is likely an open problem.

</comment></comment></comment></comment><comment><USER15> Maybe someone can help me understand a bit better. The author talks about how slow a recursive algorithm is, but the "fast doubling" implementation itself uses recursion. Would not the same slower effect be felt by this implementation due to its use of recursion?

<comment><AUTHOR> To use the language of Ableson and Sussman in _Structure and Interpretation of Computer Programs_ [node 15]:

The fast doubling algorithm has a recursive _definition_ and produces a logarithmic _procedure._

The classic implementation based on the mathematical definition:

      def F(n):
        if n == 0: return 0
        elif n == 1: return 1
        else: return F(n-1)+F(n-2)

Has a recursive _definition_ and produces a recursive _procedure_ [even worse the recursive _procedure_ runs in exponential time]. It is also possible to create a recursive _definition_ of a _procedure_ that runs in linear time.

[node 15]: [https://mitpress.mit.edu/sicp/full- text/sicp/book/node15.htm...](https://mitpress.mit.edu/sicp/full- text/sicp/book/node15.html)

<comment><USER16> In fact SICP covers the fast doubling fibonacci algorithm directly in exercise 1.19[1] (although in a slightly obfuscated form)

[1] [http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-11.html...](http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-11.html#%_thm_1.19)

</comment></comment></comment><comment><USER17> Fun stuff.

But why only take n up to around 4 million? Not too long ago, I was able to compute the billionth Fibonacci number on a pretty ordinary machine, using a Haskell implementation of the fast doubling method. (The number took 20 minutes to print out in my console window.)

By the way, I did a Python implementation, too. And I learned that GHC large- integer multiplication is a lot faster than CPython large-integer multiplication. I wonder why. (No, it has nothing to do with dynamic typing; almost all of the time is going to be spent executing internal integer- multiplication routines written in C.)

</comment><comment><USER18> One of my warm up questions is to ask to code Fib. It's easy enough to explain and leads to interesting questions about performance.

I'm still waiting for a candidate to break out Binet's formula.

<comment><AUTHOR> Interesting. Still runs in O(log n). Link: [http://mathworld.wolfram.com/BinetsFibonacciNumberFormula.ht...](http://mathworld.wolfram.com/BinetsFibonacciNumberFormula.html)

</comment></comment><comment><USER19> you know its actually an O(logn) operation with fast exponentiation through squaring.....

[http://en.wikipedia.org/wiki/Fibonacci_number#Relation_to_th...](http://en.wikipedia.org/wiki/Fibonacci_number#Relation_to_the_golden_ratio)

</comment><comment><USER20> bm</comment>


Pakistan's obstinately humble hero Edhi dies at 92 - <AUTHOR> https://www.thenews.com.pk/latest/133442-Philanthropist-Abdul-Sattar-Edhi-passes-away <comment><AUTHOR> It's a sad day. The greatest humanitarian the world knows little about has passed away.

From Wikipedia:

Since its inception, the Edhi Foundation has rescued over 20,000 abandoned infants, rehabilitated over 50,000 orphans and has trained over 40,000 nurses. It also runs over three hundred and thirty welfare centres in rural and urban Pakistan which operate as food kitchens, rehabilitation homes, shelters for abandoned women and children and clinics for the mentally handicapped.

Edhi Foundation runs the world's largest ambulance service and operates free nursing homes, orphanages, clinics, women's shelters, and rehab centres for drug addicts and mentally ill individuals. It has run relief operations in Africa, Middle East, the Caucasus region, eastern Europe and United States where it provided aid following the New Orleans hurricane of 2005.

He owned two pairs of clothes, never took a salary from his organisation and lived in a small two bedroom apartment over his clinic in Karachi.

<comment><USER2> Thanks, there are some articles linked from [https://en.m.wikipedia.org/wiki/Edhi_Foundation](https://en.m.wikipedia.org/wiki/Edhi_Foundation)</comment></comment>


Heroku Toolbelt is also for Linux - <AUTHOR> https://toolbelt.heroku.com/linux

<comment><USER2> I don't know what is new here. I used Heroku toolbelt on Linux a long time ago.</comment>


The Go Compiler Needs to Be Smarter - <AUTHOR> https://lemire.me/blog/2020/06/04/the-go-compiler-needs-to-be-smarter/ <comment><USER2> Sure, if your goal is to build a compiler that outputs the fastest possible code.

If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile- time evaluation.

Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't existed among actual C implementations (outside of maybe Plan 9) for decades now. It's yet more suckless idiocy: sacrifice everything, including utility and friendliness to end users, to buy "simplicity" for hackers. No wonder the suckless folks love Go so much.

<comment><USER3> Suckless is promoting C99 and disregards anything with a GC.

[https://suckless.org/coding_style/](https://suckless.org/coding_style/)

<comment><USER4> > All variable declarations at top of block.

And they say they want their C code to suck _less_?

Why voluntarily open the door to read-before-write undefined-behaviour? The lifetime of a local should be as short as it reasonably can be.

<comment> jagged-chisel But can't the compiler work that bit out? Source code is for humans. Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" and then let the compiler observe "var x is only used twice, so let's optimize that lifetime..."

<comment><USER5> > Source code is for humans

The reason why making the scope as local as possible is important is for _humans_ , not compilers.

> Put all the vars at the top to tell the humans "here's all the scratch space > I'll be needing in this block"

Why would humans care about how much scratch space is needed? That's for the compiler to know.

<comment> jagged-chisel We're not talking about scope. The scope is already decided. "Vars at the top of the block" doesn't mean "take those extra vars out of the while{} scope and elevate them to the next enclosing scope."

You've taken my "scratch space" too literally. Very few people need to count bytes for local vars. I'm talking about future maintainers reading and understanding code. Grouping the current block's variables at the top says nothing about how the compiler might organize the resulting code and storage. But it does inform future readers of the code.

<comment><USER6> The scope of a variable is from where it is declared to the end of the block. Moving a variable to the top of the enclosing block means that it can be referenced from more places in the code, which increases its scope.

Warnings about uninitialized variables help, but don't catch everything. For example, you don't usually get a warning for passing the address of an uninitialized variable to an external function (since it might be an output parameter), but that would be undefined behavior if the function expects the variable to be initialized. Initializing variables at the point where they are declared ensures that they can't be referenced at all in an uninitialized state.

Rust has a slightly more nuanced (and IMHO superior) system: non-mutable ("const") variables can be assigned exactly once, possibly but not necessarily at the point where they are declared, and all variables must be initialized before use, including passing references to other functions. This permits more flexibility in how the code is arranged while simultaneously offering stronger guarantees against undefined or otherwise erroneous behavior.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Does it really, though? Go really isn't meant for number crunching, or any CPU-bound code, really.

I think it's just fine for a language to not strive to emit the fastest possible code. I don't mind having an ecosystem where build times are fast in return for less optimized code. We already have plenty of languages that do the opposite (Rust, C++, Haskell, ...), and I would personally hate to see Go's compilation/link times creep up that level.

<comment><USER8> Why am I using a language with pointers if it doesn't care about being fast?

Another problem with not having a smart compiler is the gigantic binaries it produces. For wasm, an officially supported target, this makes it a non- starter.

<comment><USER7> > Why am I using a language with pointers if it doesn't care about being fast?

Because, I assume, you want to differentiate between pass-by-value and pass- by-reference - and pointers are a familiar, simple (if not simplistic) way of expressing that.

</comment></comment></comment><comment><USER9> I find it hard to fathom that many programming languages still don't use partial evaluation. That a popular language avoids inlining is even beyond that.

Inlining us hard to do in ways that makes sure you always produce the optimal code, but simple conservative inlining is probably among the simplest and most efficient optimisations you can do.

Edit: one of my favourite quotes is about the hardships of the heuristics of inliners: "I don't know how many of you have tried to write a good inliner. It is like barely being able to restrain a rabid dog on a leash".

I probably mangled that, but originally it is a quote by Andy Wingo when talking about the improved optimisations of guile 2.2.

<comment><USER10> Go does inlining and their inlining heuristic has been tweaked over time.

<comment><USER9> The example in the article is a typical function where I would expect inlining. Overly shy seems almost like an understatement.

<comment><USER11> You can see the reason actually:

      go build -gcflags="-m -m" .
      # _/tmp/inline
      ./main.go:7:6: cannot inline sum: unhandled op RANGE
      ./main.go:15:6: can inline fun as: func() uint64 { x :=
      []uint64 literal; return sum(x) }
      ./main.go:3:6: can inline main as: func() { _ = fun() }
      ./main.go:4:9: inlining call to fun func() uint64 { x
      := []uint64 literal; return sum(x) }
      ./main.go:7:10: sum x does not escape
      ./main.go:4:9: main []uint64 literal does not escape
      ./main.go:16:15: fun []uint64 literal does not escape

     package main

     func main() {
      _ = fun()
     }

     func sum(x []uint64) uint64 {
      var sum = uint64(0)
      for _, v := range x {
       sum += v
      }
      return sum
     }

     func fun() uint64 {
      x := []uint64{10, 20, 30}
      return sum(x)
     }

Go does not inline range operation.

<comment><USER12> > Go does not inline range operation.

do you know why?

[not _super_ familiar with Go, just curious]

<comment><USER11> I'm not sure I think it's just a current limitation: [https://github.com/golang/go/wiki/CompilerOptimizations#func...](https://github.com/golang/go/wiki/CompilerOptimizations#function- inlining)

They do improve the compiler every release, so we might see some of those operations get inlined in the future.

More information there: [https://github.com/golang/go/blob/master/src/cmd/compile/int...](https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/inl.go#L10)

</comment></comment></comment></comment></comment></comment><comment><USER13> I may have missed it, but this discussion seems to be lacking a key motivation of go. That is, the go devs have preferred a fast compiler over fast code output.

I have a hard time imagining them adding a bunch of optimizations around code generation when those optimizations will almost certainly:

* Slow down compile times

* Increase compiler complexity

* Be worse than what something like LLVM would produce.

Maybe it makes sense to integrate a "release" build which targets LLVM? IDK. But I do know that so long as compilation speed is a major goal for the language the you simply won't see optimizations being seriously considered.

<comment><USER14> Did you catch the note at the end about how gccgo is slower? If so how does pivoting to LLVM solve the issues seen there?

<comment><USER13> You can read about the why here.

[https://stackoverflow.com/questions/25811445/what-are-the- pr...](https://stackoverflow.com/questions/25811445/what-are-the-primary- differences-between-gc-and-gccgo)

The short answer is that there are optimizations that the GC is doing which gccgo is not doing.

The long answer is that gc will do escape analysis which can avoid allocating on the heap, gccgo doesn't do that.

Why might LLVM be better suited? Primarily because the framework also supports JIT and has efforts from the likes of Azul to make their JVM faster. Most optimizations that would benefit Java will benefit go.

[https://llvm.org/devmtg/2017-10/slides/Reames- FalconKeynote....](https://llvm.org/devmtg/2017-10/slides/Reames- FalconKeynote.pdf)

</comment></comment></comment><comment><USER15> Go mostly has been only picking up easy wins so far. I haven't seen any attempt to go further than that. Which is fair strategy for first few years since everything comes with a cost. But, people now expect to see more obviously specially the more it's being compared to more sophisticated languages and compilers.

<comment><USER16> > But, people now expect to see more obviously [..]

I don't. I mean, yay for improvements, but it's already working great for my usecases.

<comment><USER17> What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.

<comment><USER18> It isn't clear to me you're looking at a clear win there. If you do want to try it out, I recommend the strangler pattern: [https://docs.microsoft.com/en- us/azure/architecture/patterns...](https://docs.microsoft.com/en- us/azure/architecture/patterns/strangler) With HTTP it's really easy to rewrite one URL at a time. You just need some way to proxy things around, nginx if nothing else, and then you can swap things as you go along, so you can pick and choose which URLs to test the Go implementation on.

My rule of thumb for Go performance is that's roughly 2-3x slower that C/C++. While human loss aversion is probably kicking in and making that sound horrible, from an engineering perspective, it's likely you'll not notice it, speaking broadly from my position of ignorance. However, if you do have your code deployed to places that are routinely running the CPU at 50%+ all the time in your C++ code (as opposed to DB wait or whatever), and you are not interested in investing in more hardware, I wouldn't even consider switching to Go.

<comment><USER17> It's mainly binary to JSON conversion, and firing that out over HTTP a few thousand times a second. That's the only IO. Goroutines look very interesting, and as I said, ASIO (C++ async networking) is a real pain to work with. But there are latency requirements here. Something that previously took 1ms cannot now take 10ms.

</comment></comment></comment></comment></comment><comment><USER19> A frustrating thing about inlining in Go is that there's a fairly arbitrary cost model and you sometimes end up fighting it (lookup George Tankersley's talks on YouTube). There have been tons of discussions about whether or not it should be user configurable, if inlining hints should happen at the call sites or function definitions etc.

It's quite a nice discussion that helps people understand the toolchain. It also goes to show that while a self hosted build system is nice, you forgo decades of gcc/llvm optimisations. [https://github.com/golang/go/issues/17566](https://github.com/golang/go/issues/17566)

<comment><USER20> Those optimizations could be taken advantage of via gccgo.

Also many other languages keep having backend issues, because those optimizations are too focused on C and C++ code semantics.

<comment><USER21> > Also many other languages keep having backend issues, because those > optimizations are too focused on C and C++ code semantics.

Attribute it to LLVM monoculture.

<comment><USER22> Attribute it to benchmarks people care about being written in C/C++ (with maybe a dash of Fortran). e.g., SPEC CPU.

</comment></comment></comment></comment><comment><USER23> ___" I do not mind that Go lacks exceptions or generics. These features are often overrated."_ __

I agree 100%. I 've used them both in C++. I hope Go never gets them.

<comment><USER24> Generics, I would certainly be ecstatic for _if it was done in a way that is novel and feels Go-like_ , so not Java or C# or C++'s implementations. This has certainly been the stance of the Go team since the beginning of time. It has never been "anti-generics" it's always been "we've studied all the generics implementations out there, and didn't feel like any one of them were good enough, so rather than shoehorn them in, we are being patient." This approach needs to be celebrated more.

Exceptions, OTOH, I hope never see the light of day in Go. Curse them.

<comment><USER25> What's wrong with the way that Java, C# a, and C++ handle generics? I see this complaint fairly regularly, but I was never sure why. Is it how the compiler handles it, or how the language defines it that is the reason for this dislike? Genuine curiosity.

<comment><USER24> This is the lazy answer I know, but I wanted to at least answer your genuine curiosity: There is ample research available online on the subject that explains it in depth and far better than I ever could. However, I will leave you with a few quotes that help at least paint the picture.

From the Golang FAQ:

> Generics are convenient but they come at a cost in complexity in the type > system and run-time. We haven't yet found a design that gives value > proportionate to the complexity

Quote from Russ Cox:

> The generic dilemma is this: do you want slow programmers, slow compilers > and bloated binaries, or slow execution times?

Finally, one of the reasons the C++ or Java approach has never been palatable to Go core devs is summarized from this Rob Pike quote from his famous "Less is Exponentially More" blog post:

> If C++ and Java are about type hierarchies and the taxonomy of types, Go is > about composition

So therefore it really is also a matter of finding a generics approach that lives up to that spirit as well. Contracts I think are approaching that.

All that said, user defined generics (since technically speaking, Go has many generic capabilities today already) _are_ coming to Go, they just aren't being rushed. I think we will be happy with the generics implementation in Go within the next year.

</comment></comment></comment></comment><comment><USER26> The optimization I care about most is vectorization. A lot of ML and data science basically boils down to numerical linear algebra and optimization; vectorization is the key optimization for these kinds of problems. I bet if Go got a better autovectorizer it would compare more favorably against languages like Rust and C++ for numerical tasks. The trade-off, of course, is longer compile times, which I suspect will be unacceptable to the core Go team.

<comment><USER20> Even Java and .NET do better on auto vectorization.

Intel has recently published an article on using Go, their advice?

Manually use cgo or Go Assembly for the AVX.

<comment><USER27> Apples to orange comparison. Java and .NET have different goals, around 2 decades of optimization and a lot more money thrown at them.

Also, hi again pjmlp! Another Go thread, another nonconstructive Go bashing coming from you. From your other comments here I see you got pretty combative this time.

<comment><USER28> Please don't ever start or feed flamewars like this on HN again. We ban accounts that do that, and what you did here was egregious.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER27> I assume full responsibility. I started it.

Regardless of pjmlp's behavior in Go threads it doesn't justify me lowering the bar like this.

You wont see this kind of content coming from me in the future.

</comment></comment></comment></comment></comment><comment><AUTHOR> This[0] PR should fix some of it is my understanding but will have to wait and see -- not playing with /tip!

[0] [https://github.com/golang/go/commit/fff7509d472778cae5e652db...](https://github.com/golang/go/commit/fff7509d472778cae5e652dbe2479929c666c24f)

</comment><comment><USER26> Another pain point in Go I vaguely recall is that functions written in assembly are never inlined, so you always pay some penalty for using such functions (this may have changed in a more recent version of Go).

</comment><comment><USER29> No benchmarks or any other numbers. I wonder how much faster some typical Go code (some CLIs, Hugo or webservices) will run? Around 1%, 5% or 10%?

The Go compiler doesn't __need __to be smarter for Go 's usecase. If it can be made smarter, fine. For best possible performance look at C/C++ or Rust.

<comment><USER30> "No benchmarks or any other numbers."

And yet plenty of logical argument. The author assumes a level of optimization experience on the part of the reader, for example that the reader appreciates the physical cost of branch mispredictions.

</comment></comment><comment><USER31> With its well defined AST, I think Go can "easily" accommodate optimizations as described, but obviously at the expense of compililation time. And I gotta tell you that keeping compile times down is the more important optimization for me. However, I happily add automated scans for safety and correctness into my release candidates, and I would gladly pay for optimizations at that point. As long as I can test rapidly with the knowledge that I can add an "-O3" flag just before release would be a perfect compromise for me.

</comment><comment><USER32> Correct me if I'm wrong but comparing Go against Swift, C, C++, and Rust isn't really fair since one of Go's goals is compilation speed, in which it seems to shine against these other languages. From what I understand, you're going to trade performance against compilation speed, and Go is on the opposite side of these choices compared to the other languages.

<comment><USER33> Realistically, compilation speed is something every major language is going to try to improve upon to improve adoption.

I haven't looked at the internals of the go compiler, but it seems a bit simplistic perhaps in the interest of improving speed. For example, it stops outputting errors after a point when it can clearly go further after having demonstrated that it's parser can recover. The error messages have lots of room for improvement, particularly compared to Rust.

<comment><USER32> I think one of the pain points that Go addresses is the compilation speed of large C++ projects at Google, and it's one of the reasons it was made in the first place. From what I know C++ and Rust are in the same ballpark in terms of compilation speed, while Go gives a noticeable improvement.

</comment></comment></comment><comment><USER34> > In less fanciful languages like C or C++, the programmer needs to check what > the processor supports themselves.

I think by now most C++ compilers can target multiple combinations of feature flags and select a supported code path during program startup. The Intel compiler could do it years ago, but the resulting code was crippled on AMD CPUs.

</comment><comment><USER35> It will be a whole lot smarter on June 8th at 7am pacific, [https://www.youtube.com/watch?v=Dq0WFigax_c](https://www.youtube.com/watch?v=Dq0WFigax_c)

<comment><USER20> I believe it when I see it on [https://golang.org/doc/devel/release.html](https://golang.org/doc/devel/release.html)

Until then, it is just yet another "we are working on it" like so many that have come up during the last 10 years.

<comment><USER35> It has Lambda Man and Griesemer on the case. I think this one will stick because it was requested by the Go team and there is precedence with featherweight java and that Wadler designed the generics for Java. [1]

There are prototypes you can play with now.

[https://blog.tempus-ex.com/generics-in-go-how-they-work- and-...](https://blog.tempus-ex.com/generics-in-go-how-they-work-and-how-to- play-with-them/)

[1] [http://homepages.inf.ed.ac.uk/wadler/](http://homepages.inf.ed.ac.uk/wadler/)

</comment></comment></comment><comment><USER17> This is a very interesting at a time when we're seeing what we can replace C++ with.

(yes, rusticles, I know rust exists)

<comment><USER36> I think go is mostly used to replace Python and Java & co.

<comment><USER5> And yet, it's worse than both.</comment></comment></comment>


Patent troll gives up, can't defend "matchmaking" patent under new law - <AUTHOR> http://arstechnica.com/tech-policy/2014/09/lumen-view-gives-up-on-matchmaking-patent-cant-defend-it-under-new-law/ <comment><USER2> _" We imagine they siphoned off any remaining cash to investors, so they can declare bankruptcy and not pay the court-ordered legal fees."_ Is that a crime? If it isn't, it seems like it should be. The creditor already has a legal claim to the funds at that point. That's at least economically equivalent to stealing their money.

<comment><USER3> Sadly no, it is not a crime. And it is nearly entirely the reason that one creates a legal entity (and LLC in this case) to "hold" the liability. The flip side is that it is also not a crime for someone to take a million dollars of someone elses money and spend it paying themselves and some friends a salary while building a web site devoted to cat pictures while buying a bunch of hardware on credit. Only to have the web site go bust. In both situations, monetary judgements can be levied only to have the entity "die" and take with it the liability it was holding.

The "win" here is that "do it on a computer" patents are being invalidated left and right by the courts and that is crimping the revenue stream of trolls and having them re-evaluate their portfolios.

<comment><USER4> > Sadly no, it is not a crime.

That depends; it _can_ be, if the owners of the LLC act in sufficiently bad faith. That's what "piercing the corporate veil" is about: when the owners of a company abuse the liability shield badly enough that they should be personally liable. Pulling money out in anticipation of a bankruptcy (as opposed to spending it in good faith as part of doing business) could potentially qualify for that.

<comment><USER5> That only applies if they still do something illegal. This generally applies to cases of money-laundering, drugs, criminal intentions. There would have to be a separate case initiated by the legal system.

<comment><USER6> Not the case. Piercing the corporate veil depends on a number of factors that do not involve grossly illegal actions like you describe.

[https://en.wikipedia.org/wiki/Piercing_the_corporate_veil#Un...](https://en.wikipedia.org/wiki/Piercing_the_corporate_veil#United_States)

</comment></comment></comment></comment></comment><comment><USER7> Why can't it be classified as RICO? It's such a classic racket / shakedown scheme.

<comment><USER8> Not a lawyer, but RICO has to do more with conspiracies that try to hide crimes by assigning the individual acts to underlings.

And it's not a racket if what you're threatening is legal, which this kind of abuse of patent law unfortunately is.

<comment><USER7> But it wasn't legal, since the patent was fake. So it was racket.

<comment><USER8> What law does it break to threaten legal action to enforce a patent granted to you by the USPTO?

It sounds like you don't like what you see, and you want to find something in the law to use against them. But lots of smart people have looked and nobody has found anything, so it's probably not there. The correct solution is to change the law, not to use overly broad interpretations.

<comment><USER7> So, USPTO grants an invalid patent, and patent troll uses it to shake down whoever they wish? I surely think it's illegal. If there is no law which makes it so, there should be one. I'd say even if the patent is valid, one can't use shakedown methods like "pay up or else".

Patent trolls even big ones like Microsoft for example use intimidation to squeeze money. Their tactic is clearly to use high cost of litigation to force everyone to settle outside of court. I.e. it can go like this. A troll comes to some company and says: "Nice business you have here, it would be a pity if anything happens to it. Pay up or else". Company answers: "We'll fight to invalidate your patents". Troll says: "So what, we have tons more we can pull out, you don't have money to fight to invalidate them all, so better pay up". Whether they are valid or not such practice should be illegal because it's not any different than criminal shakedown.

 _> It sounds like you don't like what you see, and you want to find something in the law to use against them._

Indeed. I'd prefer them to be persecuted as racketeers, because they are such. I agree that if the law doesn't cover such case it should be fixed.

</comment></comment></comment></comment></comment><comment><USER9> I hope one of these companies takes the troll to the very end and gets their money back from the scum bags (excuse me attorneys) at the head of the troll. That will stop this very quickly and completely. Then this embarrassing history of patenting software can come to its logical end.

If any piece of software should've/could've been patented it was the original OS. And, Bell Labs took care of that when they gave Unix to the public domain. Ditto for the original BIOS. When IBM didn't bother to defend it that option was over too.

</comment><comment><USER10> This feels like the scene in Godfather where Michael Corleone walks into the restaurant washroom, comes out with a gun and gets his vengeance.</comment>


Fiat vs. Bitcoin - <AUTHOR> http://www.fiatfate.com/ <comment><USER2> Interesting graph. Of course it's saying a lot more about fiat currency than about bitcoin. The graph would look about the same with almost any commodity, stock, real estate, ... and so on and so forth. It would look the same (exponential shape) for any state, and crucially, it would look the same even if you went back centuries or even millenia.

The only real conclusion to draw from this is that governments have always spent more than they claim to spend, and they've always made up the difference by cheating with your money. The ancient Faraos did this, the Roman Senate and Emperors, the Athenean democracy did it, the Communists (Russians and Chinese) did it, and modern democracies do it. They've all been doing it this way, and for multiple millenia.

TLDR: Don't store wealth in fiat currency (or gold currency). Almost anything else performs better. This should not be news to anyone, but surprisingly few people seem to have realized this.

<comment><USER3> "your" money...

Show me the coin used for paying the tax." They brought him a denarius, and he asked them, "Whose image is this? And whose inscription?" -- Matt 22:19-20

<comment><USER4> "Render therefore unto Cæsar the things which are Cæsar's" \-- Matt 22:21

That story is all about Jesus telling people "religious law doesn't get you out of paying taxes."

<comment><USER3> Correct, and neither does the quasi-religious belief that currency somehow has significance in the theoretical absence of a state.

</comment></comment></comment></comment><comment><USER5> The way I understand money is to treat it as a technology. A technology is designed and operated to serve a purpose. The money of countries like the US and Europe is intended to serve as a medium of exchange, a _temporary_ store of value, and a tool of government tax and monetary policy. I think it's expected that people will hold onto a minimum amount of money, and store the bulk of their wealth somewhere else. Most people don't have substantial wealth in the first place.

Bitcoin is intended to serve another purpose: To demonstrate the behavior of a money system that is not controlled by a government.

As with any technology, people use money if it's useful to them. If a country has a poorly managed money system, then people start to use the money of some other country, or barter. If bitcoin has a chance of supplanting government money, it will happen when bitcoin works better for the people using it. I suppose this could happen sooner in countries that have really bad money, or if the use of government money becomes prohibitive because of transaction fees.

<comment><AUTHOR> very valid analysis, but how do you identify "countries that have really bad money" ? it doesn't happen overnight so which countries are going to face monetary issues in next 5-10 years, hard to tell? and unfortunately general public doesn't proactively monitor(and it is too complicated for public to understand because for some reason most of the primary schools don't educate about personal finance and monetary system) so most people realize after crisis had already taken place (mainstream news is their only validation).

<comment><USER5> That's a very good point. A technology can get screwed up. Maybe that's a good reason for identifying it as a technology, so that people don't think it grows on trees, and are more inclined to keep an eye on it. One indicator might just be a flight from a bad money system to a good one. I once met a person who ran a factory in Brazil during a period of hyper inflation, and he kept his money in US dollars.

A bigger fear is that the most robust currencies get screwed up, i.e., what might be loosely defined as a global financial system. If that were to happen, then the benefits of "good" money could simply vanish, i.e., prosperity.

I'd love to make personal finance and some basic economics be part of K-12 education. I'll bet college would suddenly get cheaper. ;-)

<comment><AUTHOR> agree 100% :)

</comment></comment></comment></comment><comment><USER6> By any reasonable definition, Bitcoin is a fiat currency. Unlike commodities like gold or silver, it has no inherent value whatsoever, and no applications for industrial use or jewellery.

Bitcoin is a fiat currency because it only has value while some group of humans collectively agree to pretend that is has value. The same as dollars or yen.

<comment><USER7> > By any reasonable definition, Bitcoin is a fiat currency.

Sure, if you entirely change the definition of fiat currency.

A fiat currency gets its value by being declared by government as legal tender, and then required by law to be accepted in a jurisdiction.

Bitcoin might share the "no intrinsic value" property of fiat, but that does not make it fiat. It's pretty much the opposite of fiat in every other respect.

Even for gold, the majority of its market value is not from industrial use -- it's from speculation driven by scarcity (pretty much exactly like Bitcoin.) This applies to gold jewelry too -- the scarcity of gold gives it its market value.

<comment><USER8> > speculation driven by scarcity

which makes it interesting as to why Ripples get "so much" value as a currency that has so many "coins". From Coinmarketcap[1], the circulating supply of ripples is 38,531,538,922 while bitcoin is limited to 21,000,000.

The other interesting thing is that Ripples "distribute" its coin as opposed to letting miners mine them.

I know nothing about economics so I would be interested to know why people put much value on Ripples. (disclaimer: I myself invested 6000 ripples just because they are currently cheap compared to the market cap they have.)

[1]: [https://coinmarketcap.com](https://coinmarketcap.com)

<comment><AUTHOR> Ripple is not decentralized at all. They've zero intention to bring decentralization, all they're trying to do is give banks a technology that can speed up remittances. Why do you need blockchain for that specially if you will be using banks anyways? Why can't banks speed up remittances on their own. Just do some basic search on the guy who created it, stellar lumens, mt gox, 70% tokens held by a few company individuals(although they say it is locked etc)

<comment><AUTHOR> not suggesting that they are not credible or anything but I think their technology shouldn't excite people that much. And may be rather than public funding this bank's side project, perhaps banks can use some of their profits to develop this on their own or with Ripple or at least may be it should be funded by large investors who have large stakes in banks. Just ponder upon, why should you fund this experiment/technology?

</comment></comment></comment></comment></comment><comment><AUTHOR> thanks everyone for all the discussion in this thread. Being the author of this website, I would love to hear any suggestions - I will try to add more interesting stats in the future but keep it lean at the same time. Also I hope people read FAQ section on the website, I had tried to touch upon very common questions but in a different way so that it can make people think rather than running to conclusions quickly.

</comment><comment><USER9> Now if only you could by bread with bitcoin.

<comment><USER10> You could I guess but it's really better to just use a credit card. Your CC company rewards you for using it while a Bitcoin transaction is the opposite - it costs you money to spend BTC. If you want anonymity, use cash. If not, use a credit card.

<comment><USER11> Do you really believe that the CC rewards are free?!? You, the customer, ultimately pay for them. Purchase by CC costs the merchants money (how much is it nowadays, around 2-3%?), the merchants pass that price increase on to customers (regardless whether they pay by cash or credit card nonetheless).

<comment><USER12> By that logic then it makes even more sense to use the credit card over both cash and <whatever>coin. If the transaction price is getting bundled into the overall price of the article I'm buying, why would I pay in cash and lose credit cart protections and loyalty points? Or even worse, why would I pay in bitcoin and lose the same as above and incur a transaction fee myself?

<comment><USER13> Assuming the merchant doesn't charge extra for using a credit card

<comment><USER14> Which they don't and also it's illegal. You can charge less for cash, but no one does that. (Except your one or two examples out of the thousands of stores)

<comment><USER15> It's not illegal, but it is against Visa and Mastercard's rules, to levy a fee or surcharge to use a credit card. What IS illegal is to prohibit merchants from offering a discount to induce customers to pay by cash or check, which is why merchants that do so don't end up having their Visa and Mastercard contracts cancelled.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I think that currency volatility won't be a problem in the future. Everything will be online and prices of items will update in real time to reflect supply and demand relative to any digital currency of your choice.

It will be like in the old days when people used to haggle over the price of everything.

<comment><USER17> > I think that currency volatility won't be a problem in the future .... It > will be like in the old days when people used to haggle over the price of > everything.

That does sound like a problem to me.

<comment><USER18> Don't worry, there will be algorithms that play the market by buying and stockpiling goods when their prices are low and sell them when their prices are high, smoothing out the supply/demand and taking a small margin in exchange for bearing that risk.

Then there will be services that virtualize that, with price insurance and the like.

Then there will be services that let you put in an order that will only buy something if its price goes below a certain level.

Then there will be services that let you put in a time-scale over which you want to buy something and make sure you get the best price while still getting the item within that time (including shipping price and time, of course).

Then there will be services that estimate all this for you.

I'm still waiting for someone to write the dystopian novel where you choose an "advertising agency" and they surveil you, automatically ordering everything you need/want based on your income, taste, preferences, etc.

</comment></comment></comment><comment><USER19> Love it!

</comment><comment><USER20> shameless plug: [https://fiatcoin.net](https://fiatcoin.net)

<comment><USER21> What in the world is this? Your plug says nothing, and your page says nothing. Hell, even the URL is pretty meaningless.

<comment><USER20> That's because it's just a landing page for now. That will change on Monday.</comment></comment></comment>


FWD:Everyone - <AUTHOR> https://fwdeveryone.com/ <comment><USER3> Thanks for submitting this, I was surprised to load HN and see it here. I've been meaning to do a proper update on what we've been up to for a while, but basically things that we've done since launching:

\- 99%+ of non-commercial email threads now parse correctly, better than Gmail in most cases. E.g. check out the inline reply parsing here: [https://www.fwdeveryone.com/t/Gb8CYKvGS6uFSXdb_hwiTA/blog- po...](https://www.fwdeveryone.com/t/Gb8CYKvGS6uFSXdb_hwiTA/blog-post- feedback-icos-cancer)

\- We now support oEmbed, so you can embed email directly within Reddit and Medium posts. And also within Confluence, your own site / blog, and hundreds of other places. C.f.: [https://www.reddit.com/r/nyc/comments/87a7my/restaurants_wor...](https://www.reddit.com/r/nyc/comments/87a7my/restaurants_worth_traveling_to_in_the_bronx/)

\- The site now works really well on mobile and tablet.

\- We've added organizations. Organizations can have public and private repositories. When publishing email to a public repository, by default permission request emails only go out to non-members of the organization. (And permission is never required to publish stuff to a private repository.)

\- You can now anonymize any message contributor. Anonymized message contributors don't receive permission requests. Users can later anonymize or de-anonymize themselves at any point. (This works even if message contributors haven't yet created an account.)

\- Threads are now SEO optimized. We basically take all the incoming garbage HTML that is modern email, and output it as really clean and minimalist HTML. (This also ensures that the redaction feature never breaks.)

\- We now have pretty decent video tutorials: [https://www.youtube.com/watch?v=Zwh9TJWoG6k&list=PLJAEYmnEjI...](https://www.youtube.com/watch?v=Zwh9TJWoG6k&list=PLJAEYmnEjIu4 --bpq5LSKZ9LS44po_NUx)

\- Users and organizations now have RSS feeds of their email, e.g.: [https://api.fwdeveryone.com/user/inbox.atom?username=alex391...](https://api.fwdeveryone.com/user/inbox.atom?username=alex3917)

\- Lots of recirc features, e.g. trending threads.

New features in the pipeline:

\- Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.

\- The front end is being completely re-written in React. Right now the front end loads in about 800ms, we're hoping to get it down to half that or less. (In comparison, the oEmbed loads in 80 - 130ms, hard to get much better without changing the speed of light.)

\- We're building a Gmail plug-in. This will allow people to publish directly from their Gmail, and it won't require read-only access to the user's entire inbox. (Even though our privacy policy is very good!)

When we built the site we knew that no one needs or is looking for a new social network, so we figured that we aren't going to get many sign ups until people have read at least 100 really good threads on the site. We're not quite there yet, in terms of having enough content and traction for this to be a real business yet, but we're trending in the right direction and I'm hopeful we'll be close by the end of the year.

But yeah, overall we're basically just trying to make the Internet fun and weird again, the way I remember it when I was a kid but with a more modern twist. And also a real business model, no BS advertising, ever.

Also, for all the stuff that gets published about how addictive social networks are, try actually building one; nothing is more addictive (or inspiring) than a blank page.

<comment><USER4> One thing you almost certainly want to change is the site's behavior with Javascript disabled - right now, it just shows a white screen with the text "Loading FWD:Everyone".

It's a bit of a pet peeve for me to see pages like this that are primarily static but are not accessible without JS, but I can understand that making a page built with a JS frontend work without it might be more work than it's worth, at least for an early stage project.

However, you really should put up _some_ sort of notice to users - while being able to read a short blurb about what the site is nice, even just "<noscript>This site requires Javascript to view.</noscript>" is better than a blank page or permanent loading screen.

<comment><USER3> Good suggestion on the noscript.

There is actually a bunch of animation and interactivity on the site though. E.g. if you click on anyone in a thread, you see their bio and their other threads. And when you hover over a user's popsicle stick on the newsfeed it pops up, which is stupid but oddly satisfying... We tried to give it the feel of popping bubble wrap.

Anyway prerendering more stuff is on our roadmap, so once that's set up we can reevaluate.

<comment><USER5> It's called CSS3 mate.

</comment></comment></comment></comment><comment><USER6> I'm sorry, but the idea of a product designed specifically to facilitate the mass redistribution of communications normally assumed to be private by default is deeply disturbing. Do I need to start including EULAs in every email I send? In what multiverse is this sort of thing okay?

Unless permission requests are mandatory and forever will be (regardless of anonymization), I will automatically refuse to communicate via email (and possibly any other implied-private medium, including one-to-one chats, mail, and SMS) with anyone I know to be using this service; instead, the only communications from me with these people will be through systems/services in which communications are already assumed to be public or shared (e.g. forums, mailing lists, public social media posts, blog posts / webpages, etc.). Likewise, I will never use this service myself; there are plenty of services out there that facilitate public-record written electronic communication while being upfront about it.

To reiterate: my emails to others should be considered private between myself and the recipient unless both of us explicitly consent to their publication, anonymized or otherwise. That's basic fucking courtesy - courtesy which FWD:Everyone seems to be explicitly designed to violate.

<comment><USER7> It requires opt-in from all participants in the conversation, as Alex posted down this thread last week:

[https://news.ycombinator.com/item?id=17401425](https://news.ycombinator.com/item?id=17401425)

> _We actually currently require double opt-in permission for each message > contributor in a thread to share stuff publicly. That might change in the > future, we 're still playing around with the model._

And yes, it does violate basic expectations - that's on purpose.

<comment><USER6> Per Alex's comment on _this_ post (and, in fact, the current top comment):

"Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment."

It requires opt-in from all parties _now_ , but there's already a publicized plan to change that.

"And yes, it does violate basic expectations - that's on purpose."

I'm not sure how "don't worry guys, we're _intentionally_ building a product to facilitate the wholesale violation of decades-old email etiquette and common courtesy" is supposed to make this idea sound any less horrific.

<comment><USER3> So just to clarify, we're changing the product to make it _possible_ to upload stuff without permission, but we're not trying to induce bad behavior.

E.g. Gmail has a reply all button and a forward button, but they don't encourage users to abuse them. They're just there for situations where it's (hopefully) appropriate, and they trust users to exercise good judgment. And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails.

There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed.

<comment><USER6> "Gmail has a reply all button and a forward button"

Last I checked, neither of those buttons are designed to publish the whole conversation to the whole world via the World Wide Web. Your product is. Therefore:

"we're changing the product to make it possible to upload stuff without permission"

Then you're changing the product in a way that is absolutely unacceptable for privacy reasons.

"we're not trying to induce bad behavior"

I'm not trying to induce meth addiction; I'm just selling it and hoping it won't be abused.

"And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails."

Then you're missing the point: I want to minimize the potential for abuse to ever happen in the first place. Hence the ultimatum in my top-level comment: if I know someone is using this service, then I'm going to refuse to communicate with that person via implicitly/semantically-private channels (in fact, it'd be nice if there were some way to programmatically get a list of email addresses registered with this service so I can maintain a blacklist on my SMTP servers and prevent myself from sending anything to them by accident). I _might_ waver from that if FWD:Everyone offers the ability to preemptively register my email address(es) in an "automatically deny permission" list.

"There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed."

Then that request for verbal permission should be along the lines of "hey, I want to post our conversation from a while back to FWD:Everyone; do you mind logging in real quick and approving it since the request probably went to your old email?". Even better if FWD:Everyone would keep track of who owns what emails and send requests to alternate emails if not approved in a certain amount of time.

Otherwise, tough beans. Just because Disney didn't respond to my email asking for permission to sell bootleg copies of Frozen on the black market (e.g. because I sent it to the wrong address or because it's obviously going to be a "no") doesn't mean I'm automatically allowed to do so.

In other words: if I'm unable to provide consent, then assume that I do not consent. Inconvenient, sure, but that ain't my problem.

</comment></comment></comment></comment></comment><comment><USER8> Sync my inbox? So basically, if you get hacked, all my emails are public. Or at the very least, an untrusted third party (you) gets to read everyone's private email?

No way I'll use it, nor allow anyone else I know to do so.

<comment><USER9> I feel like this would be a good use case to use blockchain where the code would be public and your email messages could be encrypted.

<comment><USER10> There was an IOTA "random" wallet generator where they posted the codebase online, but they had additional code on the page that made the range of generated wallets really narrow. The owner eventually robbed everyone.

I'd still be skeptical.

</comment></comment></comment><comment><USER11> > * Less work than blogging, way more benefits > > * Build a community around > your inbox > > * Only share the emails you intend to

It's just a fancy mailing list then? Minus the SMTP leg, plus privacy/consent issues and moving to a non-free storage format as well as concentrating the presence of the "thread" at one site.

The best email lore out there is saved to mailing list archives and can be linked to and shared just as easily. And mailing lists take "forwards" too.

<comment><USER3> > It's just a fancy mailing list then?

It's more of a social network built around email conversations. E.g. we make it easy to not only to leave comments and share on social, but also to embed threads within any other site.

Unlike email lists, we're also designed to make it easy to share great conversations after the fact, rather than having everyone copied on every message as it happens. I think one good use case for the site is sharing the best conversations from otherwise private mailing lists. (With everyone's permission, or if the list specifically allows it.)

> moving to a non-free storage format

If you look at the API response for our threads, it's actually much easier to parse than any archival format.

That said we're not (currently) an archival product; we don't store the original raw messages, and we don't output them into archival formats designed for longterm storage. I would like to integrate with some archival products in the future though. Right now when you donate your email archives to a university, they are only readable in the reading room of the university after signing an NDA with the librarian. I think we offer a good solution for making it easy to redact some of the more interesting threads and get them on the web, and I think a lot of that stuff would be super interesting.

</comment></comment><comment><USER12> Really thought this was some high-brow joke - nope! This is a real product/service to share your emails.

I think this is a truly terrible idea. But what do I know? google thought it was a good idea to have copies of the usernames/passwords for all the sites I visit stored on their servers. I think that's also a truly terrible idea - <USER2> they're a billion dollar company.

I would never use (to share) and I am doubtful I would find any thread between two other people worthwhile. But if they can find a paying userbase, mazel tov.

</comment><comment><USER13> Interesting idea, but anything that wants to read my email is a big Nope.

<comment><USER3> No OAuth is needed to make an account. For most social sites (e.g. HN), 95% of the content comes from 5% of the users. We're not trying to be any different, beyond the fact that it's also a useful business tool.

Also, when our Gmail plugin gets released the OAuth story will be much better. Basically they have a scope that's read-only OAuth, but the plugin only gets access to the thread that's currently open when the user activates the plugin for that thread. That's exactly how it should work. There are still a couple features missing, we can build it without them but we're trying to work with Google to save some duplicated code on our backend.

</comment></comment><comment><USER14> I think it would be better to use reddit or hn threads; using them as an outline for a blog post. I do that manually anyway.

Email would only be viable if it was a self hosted script. You're not getting access to my IMAP server. Duck that.

</comment><comment><USER15> Beyond the privacy concerns raised by others, I am not sure what this would amount to. Interesting conversations don't happen everyday, so this site might become just a collection of random email conversations that people submit that think is interesting. I am not sure if anyone wants to read them either.

Further, I don't think everything is "communityfiable". Like I said earlier, interesting conversations don't happen often, so stuff like following a person due to his one email upload or whatever, recommendations etc all seem a bit too much. Following would make sense if it is someone who uploads stuff often, but in this case anyone who does it would be breaching someone else's privacy unless the uploader is part of the conversation and everyone agrees to share it. But, again, as I said earlier, interesting conversations happen only once in a while.

That said, I remember how twitter was derided in the beginning as being a platform for people to share boring stuff that no one cares about, but it turned out to become something else, though not by design but only by chance, and is now quite successful.

<comment><USER3> These things sometimes evolve in unexpected ways, and sometimes it just takes a while for people to figure out how to really use something.

Use cases I think are especially compelling:

\- Industry leaders who get asked the same questions a lot

\- Professors and notable intellectuals who already give their email archives to a university when they die, and would like some of the accessible on the web.

\- Politicians. Their emails are already published under FOIA, but I think it would be super useful to folks campaigning also.

\- YouTubers, bloggers, Twitch folks, etc.

And then there are dozens of business use cases also for sharing stuff internally.

I'm sure there are lots of other uses beyond these though!

</comment></comment><comment><USER16> But what is it? "Learn more" is just videos.

<comment><USER17> It's a blank page that shows "Loading FWD:Everyone" ;-)

</comment></comment><comment> ryan-allen The last time I hit reply all by accident I lost my job.

<comment><USER18> What, did you call a client a Giraffe or something?

<comment> ryan-allen It was something like 'Giraffe', but rhymes with 'punt'.

<comment><USER19> Lesson I learned early in my career, luckily not on my own: never write something that you really don't want someone to see, especially bosses and clients and especially swearing.

Mails are replied to, mails are forwarded, long chains of emails happen, your stuff gets out.

A colleague at one of my first work places made fun of a client. 10-20 replies and forwards later, his mail was sent to a client. Luckily I think his message was buried too deep in the resulting mail and the client didn't see it.

I did, though, as did several people from my team. We didn't say anything but we all learned a lesson that day :)

<comment><USER20> This type of thing was always inevitable from the day top-posting became acceptable (and pretty much mandated by the email clients)

Before then, you would reply to points in line and trim unneeded information. The entire conversation wasn't bolted on to be ignored by 99% of people.

<comment><USER19> It would be harder, but still possible. The "trimmer" could keep the offensive bits in, causing even more damage because of the higher visibility.

Just don't write offensive stuff :)

</comment></comment></comment></comment></comment></comment><comment><USER21> Ahh this is such a great idea for a website!! Hope it takes off, it would be so great to see correspondences between professors or politicians.

<comment><USER22> Thank you! We hope so too. There's so much first hand knowledge locked up in inboxes that people would like to share.

</comment></comment><comment><USER23> Recently I've been thinking about writing a service which simply has an email address you forward an email to and it makes it publicly available via a URL - useful for things like open letters etc. I'm not sure if this is the same thing, or whether I should just go ahead and make it..

</comment><comment><USER24> We used this at the editorial house I'm at to organize the editing pipeline. Super helpful when there are a bunch of people passing around different parts of a project over email. Really hope this succeeds.

</comment><comment><USER25> I've been friends with the Alex duo for years now and I'm so impressed with how they've stuck with this core vision. Glad to see the engagement this is getting.

</comment><comment><USER26> I signed up, but I cant figure out how to delete my fweveryone account- is that not an option?

<comment><USER3> You can use Postman or whatever to send a DELETE request to [https://api.fwdeveryone.com/account](https://api.fwdeveryone.com/account) with your authorization token, but it's not in the front end yet.

Alternatively just send us an email and I'll delete it.

<comment><USER26> Thanks! I like the website, and probably will stick around. Was just curious about not having the delete option :)

</comment></comment></comment><comment><USER27> This is a cool concept, have to think about all the good things I may have spread across years of random PST files or gmail accounts. Hopefully at least one in there!

<comment><USER22> One of the features we have is a naive suggestion engine. Upon signing up you can feed the app a list of keywords. These key words are used to surface relevant threads from your inbox.

You can see this in action in this video: [https://youtu.be/MqbTUDCvYB8](https://youtu.be/MqbTUDCvYB8)

</comment></comment><comment><USER28> So basically have Twitter expand its character limit and ask everyone to replace their emails with Twitter? How cool is that? :)

<comment><USER29> Quora and Reddit would serve essentially the same purpose for readers.

That fact that it's email makes it more likely for an accidental leak of personal information.

</comment></comment><comment><USER30> I joined up, how do I ask for accomodation advice for a week in London in August? Do I have the right idea of the app?

<comment><USER3> Other way around. If you have conversations in your inbox that you think would be interesting or useful to others, then you should post them! We have a suggestion engine though, so if you enter in your hobbies / interests / work projects into the relevant field on the settings page then we do a pretty good job of surfacing relevant threads. (At least as good as we can do just using metadata search, since we don't actually access anything in your inbox except the stuff you choose to upload.)

But yeah we have a bunch of travel advice like that, it's definitely fun to read.

</comment></comment><comment><USER31> I don't use Gmail. Is there a way to forward an email as the name implies, or does it only work with Gmail?

<comment><USER22> Currently we rely on the gmail API, but it is on our roadmap to expand to the other major email providers. Is there one in particular that you would like to see on FWD:Everyone?

</comment></comment><comment><USER32> > We use OAuth to sync with your Gmail inbox so we'll never ask for the > password to your inbox.

Fuck. No.

If this is (and to be honest I didn't read it that closely) just about making a particular email public, why not just have an inbound address?

firstname.lastname@example.com

I'd actually consider using a service that did that.

<comment><USER3> > why not just have an inbound address?

We'd love to! Unfortunately going from just the last email in the thread to being able to reconstruct the entire thread would be exceedingly difficult.

Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity of conversations is very important to us. If you get a permission request from our site, we want you to be 100% confident that what you see when you preview the thread is going to be what you actually wrote, and that the uploader wasn't able to change the text at all. We support making redactions and anonymizing folks, but are strongly against people being able to change the text of what they or others wrote after the fact.

The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage. We're all for reducing friction, but we'd rather do it by just making a really slick Add-on so that we don't have to compromise on that core value.

As for the Gmail OAuth situation, I completely agree and have been raising awareness of this on HN since long before this became a big issue the other day. You can see my tickets requesting narrower OAuth scopes here:

[https://issuetracker.google.com/issues?q=reporter:alex.krupp...](https://issuetracker.google.com/issues?q=reporter:email@example.com)

<comment><USER33> > Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity > of conversations is very important to us.

Are you sure you have really tried? when you forward an email, it includes all the headers you need to for your validations.

<comment><USER34> I'm pretty sure most mail clients will not directly include _any_ of the headers from the original e-mail, unless you do "forward as attachment"

</comment></comment></comment></comment><comment><USER35> I initially thought this was satire based on 3rd party apps reading your email

</comment><comment><USER36> Four wheel drive? WTH? Can you please offer a ..... :(

</comment><comment><USER37> Very cool product! Will follow this and I hope it is successful.

<comment><USER38> I sure hope they aren't. This is terrifying, from a privacy perspective.

<comment><USER37> True, but only because it is OAuth. I like the overall concept if I don't have to share access to my inbox. Better if it was via forwarding to a specific address.

<comment><USER22> We are actively working on a gmail add-on which would allow you to not give us access to your inbox, rather, publish single threads to the site through the gmail interface. We have a few tickets open with Google to narrow the scope of the permissions available to us for exactly that reason! :)

</comment></comment></comment></comment><comment><USER39> It blows my mind that people are having "Group Chat" conversations like that via Email. Have they never heard of WhatsApp?

<comment><USER40> Email is much better for longer, well thought out replies and keeping track of multiple threads of conversation, each of which may have no activity for days at a time. Whatsapp is fairly limited to quick, short replies (mostly because of interface restrictions). Even chat-like email threads have much longer messages interspersed than what you would see on WhatsApp. Email also has much better tools for finding old messages than WhatsApp</comment></comment>


Obama uses a Mac, Change - <AUTHOR> http://flickr.com/photos/barackobamadotcom/3009087034/in/set-72157608716313371/

<comment><USER2> Sheesh. Enough already!

</comment><comment><USER3> Title should be "Someone uses a Mac near Obama". ;-)

<comment><USER4> That would be crazy Joe Biden, who also doesn't mind paying a premium for his shotguns.

<comment><USER5> I can feel the change starting now! _LOOK!_ One of Obama's running mate's aides is _HOLDING_ a Mac! I mean _IS_ there any better symbol of _CHANGE_!?

Yikes. The intersection of Mac and Obama fanboyism could probably create a reality-distortion-field large enough to cover the entire planet.

</comment></comment></comment><comment><USER6> Clinton and Bush Jr. were also Mac users...</comment>


TensorWatch – Debugging and Visualization for Deep Learning - <AUTHOR> https://github.com/microsoft/tensorwatch <comment><AUTHOR> I'm a member of this project. We are trying out few new ideas and your feedback and comments would be awesome! If you have been using TensorBoard, Visdom etc then you would probably find this work useful. Please let us know any questions you have.</comment>


Business Logic in the Database. Yes or No? It Depends - <AUTHOR> http://www.vertabelo.com/blog/notes-from-the-lab/business-logic-in-the-database-yes-or-no-it-depends <comment><USER2> This was marked dead which I found to be odd. I vouched for it. Could any mod's ring in?</comment>


Why I switched to Pylons after using Django for six months - grey-area http://www.mutualinformation.org/2010/03/why-i-switched-to-pylons-after-using-django-for-six-months/

<comment><AUTHOR> Give it a break. That article is 2.6 years old. Some of the points might still be valid, but there is a solution (and probably was at the time of writing as well) to every and each of the problem mentioned there.

Regarding the quality of reusable apps, well, it's like with all other software libraries out there. Some of the apps are really invaluable (mostly the utility ones addressing things like API creation, database extensions, forms or debugging), some of them address very specific problems and some of them should't ever see the daylight. Nothing new.

</comment><comment><USER2> The article is over two years old and looking at the source it seems like the site he was working on (<http://www.papsonline.org/>) is still Drupal. Would be interesting to know the background story is there.

<comment><USER3> Original author here. The website was drupal (which I championed originally), then pyramid when I redid it, now drupal again.

This is a voluntary association where I served two terms and then let somebody else handle it. The person in charge after me told me he was not familiar with Python, but used PHP a lot and after a few months changed the site back to drupal.

</comment></comment><comment><USER4> This article is two-and-a-half years old. Even if it were true at the time, things have moved on an awful lot since then.

</comment><comment><USER5> The article is old but i'd like to answer some points in the comments :

> I originally started a project of mine in Django only to find out that the > ORM couldn't handle the types of queries that I needed to perform.

I dont believe that , since you can do your own queries with Django , even in RAW sql.

> Not only that, but the ORM in Django forces it's own database conventions on > developers.

That's not true , you can use an old database that has nothing to do with django and still get a full integration with the ORM.

Django is not a CMS with plugins. It is a mvc framework that helps you begin really fast. While there are a few things that seems to make customisation a bit difficult, (auth with email instead of username ), there is always a simple solution to every problem if one digs a bit , but it requieres to understand how the framework works , like any other framework.

<comment><USER6> > I dont believe that , since you can do your own queries with Django , even > in RAW sql.

Believe what you want to believe but we have experienced the same thing just couple of months ago and have ditched it completely. Besides if I'm going to write raw SQL then why would I want to use Django's ORM? That would be another layer, too much bureaucracy.

> Django is not a CMS with plugins.

It's just one step away from CMS with plugins. I have doubts about it being a "MVC" framework.

<comment><USER5> > It's just one step away from CMS with plugins. I have doubts about it being > a "MVC" framework. You have routes, models , views and templates , like any > other MVC framework ,so tell me how does it make Django not a MVC framework > ?

> Believe what you want to believe but we have experienced the same thing just > couple of months ago and have ditched it completely. Besides if I'm going to > write raw SQL then why would I want to use Django's ORM? That would be > another layer, too much bureaucracy.

I never used Raw Sql with Django yet , i know you can , tell me a specific type of query Django cannot do ?

The problem with folks like you is either they did not wrote the doc , or they assume the framework with do everything for you for free. No framework does that.</comment></comment></comment>


Mozilla mimics Google's NaCl demo in pure JavaScript - <AUTHOR> http://www.theregister.co.uk/2010/06/25/mozilla_on_jaegermonkey_javascript_engine_extension/ <comment><USER2> I don't see the point in this. NaCl isn't about showing how slow JS is, it's about allowing people run code written in C/C++ with a recompile plus some glue code.

Totally different matters. People forget how much C/C++ code there is out there. Nobody is going to rewrite it into JS.

</comment><comment><USER3> That Chris Blizzard fellow has some interesting articles here: <http://hacks.mozilla.org/author/blizzard/> and blog here: <http://www.0xdeadbeef.com/weblog/category/performance/>

I'm glad (some) browser developers are still focusing on javascript vs native speed.

I just upgraded from a 2ghz to a 4ghz PC and damn if this isn't going to ruin my attitude about trying to make web sites faster.

The problem is NOTHING is slow on this hardware and it was less than a $150 upgrade. (It also uses less power than the 2ghz hardware!)

I'm going to have to figure out how to cut the speed in half for testing. Wish we still had "turbo" buttons!

</comment><comment><USER4> The comparison between this and NaCl is quite a stretch. NaCl has much further ranging implications -- being able to code in any language and having it display in the broswer is a true paradigm shift.

</comment><comment><USER5> If we're going to evolve web, do we really want javascript to be the standard?

<comment> loup-vaillant JavaScript is the only possible standard. Here's why:

Apparently, the world need a Turing complete Web, so it can be used for things totally out of its original scope (publishing).

Technically, it makes little sense. It often wastes bandwidth, CPU, and efficiency of interaction. (Gmail is cool, but a native version of it could be better in all three ways.)

But, because people are idiots who don't know how to install a program on their machine, we need to give them a way to use such programs without even having to point or grunt before they get started. (Well, it's not a need, actually. That's a _choice_. Idiots can be educated. And they will be, eventually.)

To this day, the only Turing complete thing that is installed by default on every computer on this planet (meaning Windows PC and Macs) is JavaScript. Unless we displace it, and until "average users" educate themselves, I think we're stuck with JavaScript.

<comment><USER6> I guess I'm an idiot user for preferring Gmail to anything else I've used while getting the additional benefit of having that exact same interface on any computer I use without having to install anything.

<comment> loup-vaillant I should have use scare quotes. I didn't want to say that users are idiots. They are ignorants, or just don't want to bother. What I _did_ want to say is that most developers do take users for idiots. Software that doesn't need a manual and takes 5 minutes to assess is made for idiots. A nice side effect is that it works very well for everyone else.

Now, using Gmail won't make you an idiot by itself. But it may be an idiocy, depending on whether you know what you are doing or not. By default, I strongly suspect that you don't. Here's why:

First, there's the obvious privacy issue. Much of your private correspondence is stored on Google's servers. Google makes semantic analysis on your e-mail, so it can send you ads. They could do many interesting things with your e-mail if they want to. They are an interesting target for internet based attacks. They could make mistakes that affect all users. Do you really trust them that much?

Second, there's network issues. Web based mail is hurting the network in two ways.

The first is that their ubiquity lead people to believe that to send e-mail, you only need the 80(http) and 443(https) ports. Thanks to that almost nobody noticed, or cared, when ISP began to block the outgoing 25(smtp) port. They pretended it was to prevent their customers to send spam. Because they took them for idiots whose Windows computers are full of botnets. They may be right, but the real effect is that their customers can no longer send e-mail by themselves, and have to rely on third parties instead. That makes web-based mail much more attractive. The loop is closed.

The second network issue is the way data flows: from Gmail to your ISP's network, and not the reverse. The effect is even more pronounced with sites like YouTube. This asymmetry, which you could have avoided if you ran your own mail server and hosted your videos yourself[1], makes hard for your ISP to get good peering agreements. And now, they invoke this asymmetry to argue that "content providers" should pay to send their data.

[1] Oh, you can't. I forgot the "A" in "ADSL". Sorry.

Anecdotally, don't you find silly that all your e-mail goes through the silicon valley before it reaches your neighbour? That's not very efficient.

As far as I know, JavaScript only serves 2 purposes: eye candy, and doing remotely what could have been done locally (meaning using web apps). Both purposes are dangerous idiocies (without quotes, this time). Using a Turing complete thing to do eye candy is idiot because of the needless potential security breaches. And using web apps is idiot because you lose control and help creating an unnecessary centre. (Note however that _doing_ web apps is not idiot at all. See Facebook.)

The current trend of webifying and centralizing everything terrifies me. If we don't pay attention, they will shut the internet down. No server at home, only clients (preferably webkit based ones). And what could have been the voice of the people will go back to the propaganda of the powerful.

I don't want that.

</comment></comment></comment></comment><comment><USER7> Clicked to see what a Sodium Chloride demo looks like.</comment>


Redis Manifesto (2011) - <AUTHOR> http://oldblog.antirez.com/post/redis-manifesto.html <comment><AUTHOR> > Code is like a poem; it's not just something we write to reach some > practical result... When writing the Redis story we're trying to write > smaller stories that will fit in to other code.</comment>


Show HN: MailgunLogger - <AUTHOR> https://github.com/jackjoe/mailgun_logger <comment><USER2> Awesome - we've slowly moved so many of the mailgun events into our own system over the years, that it probably made sense to just start with an "everything' approach to begin with!

I have asked mailgun a number of times if they'd simply charge for longer storage limits, and they said no.

Thanks for setting this up!

</comment><comment><USER3> Won't mailgun send all of the same information via event callbacks, or is there event information only available through their web interface?

<comment><USER4> Not the author, but have some experience with the mailgun api. AFAIK there's no sla/guarantee/redelivery for the webhooks, and they have to be setup for each domain. Looping the account to fetch all logs for the last 48 hours is relatively simple and robust.

<comment><USER5> OP here (actually, he is my co-founder, same company). I can confirm this experience, looping seems to work.

In our own setup, we fetch data for the last 24h twice a day and then just insert everything. We have a db constraint on the message ID mailgun sends us, so only news ones will be persisted. We aren't even bothered with filtering before inserting, the db constraint does the trick.

</comment></comment></comment><comment><USER6> This is very timely! I'd love to see the logging bits extracted out into its own library so I can use it directly in an existing Phoenix app. I don't really need the GUI bits.

<comment><USER7> You should be able to still use it. Just set `runtime: false` for the dep entry in your `mix.exs` file and only start what you need.

</comment></comment><comment><USER8> Elixir :)</comment>


The Anti-Democratic Worldview of Steve Bannon and Peter Thiel - <AUTHOR> http://www.politico.com/magazine/story/2016/11/donald-trump-steve-bannon-peter-thiel-214490 <comment><USER2> Man, I am so curious about this, but only conjecture is offered. We need to wait and see on much of this.</comment>


Ask HN: Alternative to Skype SMS Service (Linux CLI – Webservice API)? - throwaway-gone I really liked some things in the approach Skype had with SMS (started writing them, but got over the character limit). However, I've grown tired of Microsoft's constant changes to UI and TOS of Skype (I guess, due to efforts to turn it into a social network); and I'd like to part ways with Skype. So, is there a service that would function as an alternative - primarily through a Linux desktop CLI client?
In fact, if there was a web service, with endpoints like `getAccountBalance`, `getPriceForCurrentText`, `sendTextAsSMS` and `getStatusForSentSMS`, I guess I could build myself a Linux CLI (say, `bash`) client, that would also deal with plain text contact lists with mobile numbers, and save plain text "conversation" (not really conversation, since it'd only save messages I've sent) archive logs - that is all that I'd need, really. And if I can build a `bash` CLI client, I could also build a PHP client that could run on a cheap shared LAMP webserver as well. But I wouldn't mind a pre-made CLI client - as long as it's open source, so I can change it if I don't like it.
I'd expect to be paying for a service like this, and I understand I cannot be anonymous in this context - so I'd be OK with registering an account with my real email, and 2-factor SMS authentication (which is, in most other cases, a no-no for me).
So, is there such a service, that will let you sign up, and send SMS internationally/globally:
* With your own mobile number (possibly 2FA authenticated) as SMS sender?
* Supports splitting of long SMS into shorter ones, and accurately bills for that?
* With reasonable prepaid payment options (something like min 5-15 Euro per round of credit, instead of "get 10000 SMS for just 100 Euro") - where the balance is accurately deduced from, each time SMS is sent?
* With relatively stable API endpoints? <comment><AUTHOR> I have used plivo before not much so I do not fully recommend yet take a look and decide for yourself: [https://developers.plivo.com/](https://developers.plivo.com/)

<comment> throwaway-gone Interesting - never heard about plivo before; many thanks for the tip! EDIT: Though it looks like they sell virtual phone numbers ( [https://developers.plivo.com/getting- started/numbers/](https://developers.plivo.com/getting-started/numbers/) ), I wonder if it would be possible to set up my private mobile phone# as the sender...</comment></comment>


How much do you make? - <AUTHOR> http://idiallo.com/blog/2013/06/how-much-do-you-make <comment><USER2> For most people, discussing money can be a root cause of drama, so it's easier to keep their mouths shut. It's also a tradition that exists in some cultures more than others. After all, a lot of us were taught not to discuss money, politics, and religion in polite company.

A lot of people's self worth is in part tied to their material possessions and income. People don't want to risk being seen as poor or less-than their coworkers, friends, etc, so they keep their mouths shut regarding income and attempt to show off (or fake) wealth through shiny new toys and bigger houses. On the other hand, well paid people want to keep their mouths shut because it can not only alienate them from their friends and family (who may well be making less and so be jealous), but it can also pressure them to be a low interest, no-criteria lender of first resort for people that know they have money.

I highly doubt it's been a trick (at least in recent times) to underpay people because it's so easy to find out what other people in the area in similar jobs are being paid.</comment>


Men and women explore the visual world differently - <AUTHOR> http://www.bristol.ac.uk/news/2012/8981.html <comment><USER2> Anybody got access to the original paper?

I'd be interested for how they controlled for this (e.g. they talked about threat assessment in the OP - is that down to biological gender differences, or learned behaviour - e.g. would males with builds/experiences that seem to make them more likely to need to evaluate threat have similar patterns).

The "The study represents the most compelling evidence yet that, despite occupying the same world, the viewpoints of men and women can, at times, be very different." line is overstated also. There's been compelling evidence for some time that male/female visions systems are interestingly different in places. For example:

* Colour perception - <http://www.journalofvision.org/content/12/1/18.full>

* Peripheral vision - <http://www.citeulike.org/user/neilh/article/1181022>

Not seen anything on the eye tracking front before - but I'm mildly suspicious of the way it's presented since we already know that eye tracking exhibits cultural effects (e.g. the F-pattern in left-right-top-down reading cultures).</comment>


The Truth About Digital Sweat Shops (e.g Amazon's Mechanical Turk) - <AUTHOR> http://technologyreview.com/blog/arxiv/24646/

<comment><USER2> "I'll pay you ten cents if you answer a simple question. Do you think ten cents is a fair price for an answer to a simple question?"</comment>


SF Startup Microdrop Revisits Blood-Test Tech - <AUTHOR> https://sanfrancisco.cbslocal.com/2019/08/31/sf-startup-microdrop-revisits-blood-test-tech-in-wake-of-theranos-debacle/ <comment><AUTHOR> " A health care startup called Microdrop is bringing the lab to your home. Co- founder Jani Tuomi says blood collected in a small vial promises to produce test results that are as reliable as traditional lab testing ones.

It's a space made murky by Elizabeth Holmes, founder of Theranos. She had promised to revolutionize blood testing using a similar method of collection. She is now awaiting trial on charges of fraud and felony conspiracy for misleading investors about its technology. "</comment>


Ask HN: Where do you get your daily laughter quota? - <AUTHOR>

Laughter is an instant vacation -- Milton Berle.
Whether you are aiming for stars or moon or just other side of earth - you will do hard work to get it. The journey, however passionate and committed you are, will have its ups and downs. Everyone might have a different way of relaxing at the end of the day. I listen to music - but I would love to laugh out to relax. I feel it's one of the more common ways anyone can relax by. I am trying to find books, comics and other things that make me laugh. (Avoiding online videos)
I am curious about HN - where do you get your laugher quota everyday? <comment><USER2> > where do you get your laugher quota everyday?

Honestly, if you have to ask that question, then I'd say you're doing it wrong. Why do you need a _quota_ for something as natural as laughter? That's like saying you are not human or you don't identify yourself as human and see yourself as a drone.

RELAX! Let yourself go and let your brain run free. You may find yourself truly surprised at how your brain comes up with weird and funny things. Or, you can find humour talking to your colleagues in the course of work during the day. If not, of course, there are other channels if you're _really_ looking for dedicated humour topics (others have said that already, I'm not adding more to it. I just enjoy reading Calvin & Hobbes from my daily newspaper) :-)

</comment><comment><USER3> Great quote :)

For me sometimes it's the books and some times tv shows. But the idea should be to build a capacity of looking at things from a different/funny perspective. Which means developing the skill of taking an existing mundane scenario and finding something to laugh about in it and not just relying on external stimulus to do that for you.

For book recommendations gutenberg has a nice collection of humour classics ([http://www.gutenberg.org/wiki/Humor_%28Bookshelf%29](http://www.gutenberg.org/wiki/Humor_%28Bookshelf%29)) any book by pg wodehouse and three men in a boat comes with a (personal) guarantee.

</comment><comment><USER4> I've recently been listening to this BBC show called "The Infinite Monkey Cage" hosted by a physicist and a comedian. [http://www.bbc.co.uk/programmes/b011j7vc#auto](http://www.bbc.co.uk/programmes/b011j7vc#auto)

</comment><comment><USER5> [http://www.thecodinglove.com](http://www.thecodinglove.com)

Cracks me up always

</comment><comment><USER6> [http://iamdevloper.com](http://iamdevloper.com)

</comment><comment><USER7> We have an important Slack channel. #gifs

</comment><comment><USER8> The onion, cracked, mcsweeneys, imgur.

</comment><comment><USER9> Podcasts and friends

</comment><comment><USER10> Here</comment>