
Facebook puts bounties on bugs in the D programming language implementation - andralex
http://forum.dlang.org/thread/l65mvq$du0$1@digitalmars.com#post-l65mvq:24du0:241:40digitalmars.com
======
0x0
The author of the post also had a Reddit AMA recently, related to Facebook's
usage of D:
[http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_o...](http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/)

Among other things, he wrote the book "The D Programming Language".

~~~
zerr
I believe you're not very much into C++, I mean Andrei is a real celebrity
here [as well] ;)

------
thepumpkin1979
Google supports Go. Mozilla supports Rust. Facebook should actively support D.

~~~
jnbiche
Looking back over the D forums, D implementers have been promising to support
shared libraries since at least 2006, and as far as I can tell, none of the
major D compilers support it yet. D is a very nice language, but without
shared libary support in Linux or Windows, its use to me as a low-level
alternative to Python or Lua is limited.

Go clearly is interested in static-only compilation, and they've said as much.
Rust is still too alpha to use for serious projects, and to be frank I find it
carries much of the complexity that turns me off from C++ (I _really_ wanted
to like Rust).

Meanwhile, I've found Nimrod can happily handle shared library support,
meaning I can easily make nice extensions for Python and Lua. Nimrod is just
as fast as D, and probably a bit faster than Go and Rust. Syntax is very nice
for Pythonistas, and it has a very full standard library.

I've also noticed that Nimrod is getting some very good exposure here on HN,
and people smarter than I am are starting to play around with it (in addition
to the people smarter than I am who invented it and brought it to this level).

In the end, the only new low-level language without big company support may
turn out to be the winner here.

~~~
pcwalton
> Rust is still too alpha to use for serious projects, and to be frank I find
> it carries much of the complexity that turns me off from C++ (I really
> wanted to like Rust).

Could you elaborate? I personally think that Rust carries no complexity that
we didn't need to get the job done, and we're still simplifying the language
(for example, removing conditions and glob imports), but I'm certainly open to
hearing other ways that the language could be simplified.

> Nimrod is just as fast as D, and probably a bit faster than Go and Rust.

I think that for numerics all four languages will be roughly on par (although
Go will be a bit slower if you're using 6g/8g, as they don't do much
optimization), but for memory management the performance characteristics are
quite different. Rust doesn't rely on garbage collection or reference counting
for safe memory management, unlike all the others (although you can opt out in
D, at the cost of safety). So I don't think you can really make an unqualified
statement like that in all cases.

~~~
jnbiche
>Could you elaborate?

A major source of complexity, in my opinion, are the different pointers: owned
pointers, managed pointers, borrowed pointers (mutable and immutable), each
with its own syntax and rules for use. And all three seem to be everywhere. I
actually understand pointers in C (mostly!), yet I struggle to remember all
the use cases for pointers in Rust. Here's the tutorial on just borrowed
pointers: [http://static.rust-lang.org/doc/master/tutorial-borrowed-
ptr...](http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html) I'm
sure I could understand learn the rules given some time, but now that I've
played around with D and Nimrod, I'm wondering why I should. I can get
excellent performance without using pointers, yet I can access a pointer if I
absolutely need one.

>So I don't think you can really make an unqualified statement like that.

I agree that unqualified statements about the relative performances of
language implementations are tenuous, and so I retract that statement. But
it's clear that Nimrod can reach ballpark C++/Rust/Go speeds, even without GC
specifically turned off, based on both my own usage and this benchmark:

1\. [http://togototo.wordpress.com/2013/08/23/benchmarks-round-
tw...](http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-
go-rust-d-scala-and-nimrod/)

Now, it's quite possible that we're not getting optimal performance out of
Rust because we're not writing idiomatic Rust, but this hurdle is at least
partly a function of my first point.

EDIT: I should add that I think Rust may well find itself in a very strong
position among systems and embedded programmers, given the fine control and
safety it offers. But for your average programmer just looking for a faster
language to use when Python or Ruby won't suffice, Nimrod (and D with shared
library support) is a very nice alternative.

~~~
pcwalton
> I'm sure I could understand learn the rules given some time, but now that
> I've played around with D and Nimrod, I'm wondering why I should. I can get
> excellent performance without using pointers, yet I can access a pointer if
> I absolutely need one.

Because they let you avoid garbage collection and data races while remaining
safe.

If you're just starting to use each language, then having just one, globally
garbage collected type, will seem to make everything simpler. And benchmarks
of numerics will show that hey, it doesn't seem to matter what your memory
story is. But in my experience those who have struggled with garbage
collection pauses or data races come to appreciate the ability to declare the
ownership semantics at a fine-grained level. Large, production-quality,
performance-critical software in Java, for example, very frequently starts
running into issues with the garbage collector. And I don't think I need to go
into the headaches of sorting out data races.

Last I looked, Nimrod in particular loses all memory safety once you share
objects between threads. (I hear this is changing though; I'm interested to
see what they come up with.) Go loses some memory safety around maps and
slices if GOMAXPROCS>1\. D remains memory safe in @safe code, but at the cost
of concurrent, stop-the-world garbage collection. None of these languages
offer support for avoiding data races at compile time. Those decisions have
real costs (as well as benefits; they're all tradeoffs).

It's very easy to brush off features like safe manual memory management with
"I don't need that feature in some other language, why would I need it here?"
But everything you've posted has not indicated any understanding of _why_ Rust
has smart pointers. If you think GC, data races, or safety are not worth
solving at a language level (which, to be clear, is a position that reasonable
people can take!) then argue that instead of handwaving around pointer type
complexity. I don't mind if you like Go/Nimrod/D better than Rust—they're all
fine languages and I have great respect for their creators—but be informed
with your criticisms.

> But it's clear that Nimrod can reach ballpark C++/Rust/Go speeds, even
> without GC specifically turned off, based on both my own usage and this
> benchmark:

This is a perfect example of how single benchmarks can be misleading. First of
all, that benchmark was found to be mostly testing the performance of the
random number generator, which is cryptographically secure by default in Rust
and not in other languages. Second, that benchmark probably never even
triggers the GC in any of the languages. It's totally numeric-bound. Try a
benchmark of arena allocation, for example. Or compare max pause times.

~~~
jnbiche
>Because they let you avoid garbage collection and data races while remaining
safe.

Yes, and as I wrote, I think there's a very significant place for Rust among
embedded and systems programmers. But for someone who's just looking for a
fast alternative to C, Nimrod has been quite nice.

> ...handwaving...handwave....

I was trying to give you the specifics you asked for, not handwave. I don't
think I could have answered your question any clearer. And I don't think
pointing out the complexity inherent in 3 different pointer types _is_
handwaving. It's a very specific statement.

>...but be informed with your criticisms

You asked me to elaborate on my criticisms, and then you criticize my
criticisms? Look, I understand that Rust is your baby, and apologies if I've
treated it unfairly, but why ask for why I found Rust complex if you're just
going to discount it?

To be clear, I'm talking from the perspective of an intermediate-level
programmer, with a couple years of experience, who taught himself to program
in his 30s. I can certainly see the value of the design choices you've made
for an expert programmer like yourself, with many years of experience, who can
benefit from the kind of fine control Rust provides. But to someone like me,
who's just looking for some caveman-level (but very significant) speedup from
Python, and something I can call from Python, Nimrod has proven more than
adequate and a whole lot easier to use than C/++.

>This is a perfect example of how single benchmarks can be misleading

So to be clear, are you saying Nimrod can't reach ballpark C/Rust/D/Go speeds?

EDIT: Wow, I've made comments critical of Apple and Google and not gotten as
many downvotes as I'm getting here. But just to be clear, I'm not at all being
sarcastic when I say "expert programmer". I'm aware of that pwalton is a very
talented programmer and language designer.

~~~
pcwalton
I don't disagree with you that if you're looking for a fast language that
integrates well with Python, then Nimrod may be a great choice. Pervasive GC
certainly makes the language easier, with a performance cost that can be
totally reasonable in many scenarios.

I do think that there are applications for which GC will always be slower than
alternative systems such as arena allocation that Rust provides safe support
for. (As an extreme example, the binary-trees shootout benchmark.) A language
that does not provide safe manual memory management will lose in either
performance or safety for these applications. I prefer not to make statements
like "GC is slower than manual memory management", since there are many
applications for which this is not true (for example, the level generation
benchmark). Rather, I'd say that manual memory management provides a level of
_control_ that can allow skilled programmers to write applications that
outperform those in languages with a "one size fits all" memory management
scheme.

~~~
sandGorgon
you may choose to go the C++ STL way for a wildly usable subset.

what I mean is this - we all knew that the rb tree implementation of stl
wasn't that hot, neither was its sort (note - this is 7 years back), however
that library enabled a c++ project to be jumpstarted in significantly less
time than building everything from scratch.

as a language creator, you may not want to touch the design choices you made
and make it more "accessible" for a simpler use case - as the previous poster
wrote, upgrading from python.

however, you could potentially expose an accessible subset of the language as
a standardised library. of course, this may lead to language rust (!!) at
scale, but I would argue that its a good problem to have then.

I would be in your target market then - significantly better than python,
inherently memory safe, easy to use, worse than c++.

~~~
pcwalton
> what I mean is this - we all knew that the rb tree implementation of stl
> wasn't that hot, neither was its sort (note - this is 7 years back), however
> that library enabled a c++ project to be jumpstarted in significantly less
> time than building everything from scratch.

It's not that simple. You can't start with a language that lacks memory safety
and add it later. Nor can you start with a language that uses global
concurrent GC and try to reel it back in without losing safety. C++ is in the
former category and I think there is no way for them to add memory safety at
this point. Languages in the latter category really have no way of going back
on global concurrent GC; the entire ecosystem is built around garbage
collection.

Safe manual memory management is balanced on a very delicate precipice. You
must carefully design your language around it for it to work. It is not
something that can just be added later, like a faster red-black tree
algorithm.

~~~
sandGorgon
actually - I'm proposing the other way. In fact, what you just wrote above
(about the RNG being cryptographically secure in Rust) makes me really,
really, really excited to try out the language.

For a large portion of my career, I was building EDA (silicon design
automation tools), so I have worked with trying to optimize one bit at a time
with unsafe pointers biting my back constantly. IMHO partitioning an EDA
netlist is a NP-hard problem, so there have been lots of very interesting
startups that tried to solve that problem and failed.

I now work with Ruby and Python.

Trust me I do know the value of everything you wrote: I am just wondering -
requesting even - if there is a way to bridge the "accessibility" gap. Is
there a way (anything - a "quickstart" library or a safe-but-suboptimal-
subset, etc.) that enables me to start hacking with Rust in a matter of
minutes ?

------
mixmastamyk
Good for them. I was a bit surprised by the amounts though. Is it enough to
motivate?

Also, I notice the BountySource site is blank without javascript on. I'm not
one who demands that every site work w/o it. But, they should at least show
their banner and message that it needs to be turned on. The noscript tag is
twenty years old, no?

~~~
simendsjo
I noticed this too. But I wouldn't single them out. A _lot_ of sites I visit
has problems without js. It's even worse when the site isn't blank - _some_
things just doesn't work or show as they should...

------
yeldarb
And when can we put bounties on Facebook bugs?

~~~
lacker
Good question. What Facebook bug would you put a bounty on?

(ps I work on Facebook platform so this is not an idle question)

~~~
yeldarb
Wish I would have seen this earlier. I run a game on Facebook platform and we
oftentimes have bugs that you guys likely consider corner cases because they
only affect a very small subset of your users.

These tend to happen to our heaviest users who account for a large portion of
our revenue. These power users either use obscure edges of the platform or act
in unique ways to other users.

For instance, many of our top players have been completely unable to access
their friends list for the past 2 weeks now. Playing with friends is a hugely
vital component of our game and this bug makes it completely unusable for
these players (many of whom have been active, paying users of our game for
several years now).

See Bug 1420634571501183 (recently marked as a duplicate of 681781621832581
which I have no way of verifying since that user didn't post an error message
and was using FQL rather than the graph api.. I'm hoping this bug doesn't just
get lost now that it's been marked as a duplicate).

This isn't the first time we've had a bug like this happen. Allowing
developers to put a bounty out would be a strong signal that it's an important
bug to fix. It's not necessarily about the bonus revenue to Facebook, it's
about giving developers a way to get truly important bugs prioritized.

Or heck, being able to buy 5 minutes of a real Facebook engineer's time would
be valuable as well.

See also:

Bug 1394861264086269 which is a bug marked as Invalid but has to do with the
(relatively obscure) "Game Groups" Graph API not matching what's actually
shown on the web interface.

Bugs 177435992460351 and 242967435851521 which will probably be closed in 5
months because "We are prioritizing bugs based on impact to the developer
community. As this bug report has not received much attention from other
developers, we are closing it so as to better focus on the top issues." even
though they've been confirmed by FB just like countless other bugs I have
reported over the years.

------
pera
oh another of those bounties programs... but maybe this one is different from
the rest?

If you ever find any security issue don't expect to obtain a bounty from the
big corps easily, and not even a "thanks". Once, the co-founder of one of the
most important security companies told me "do not expect to receive a bounty
without sending a minimum of 10 emails explaining the same thing in 10
different ways... average 20". It's a sad truth, and I think this means that
usually legit critical security issues reports will not be properly rewarded
because most people get tired quickly.

One year ago I discovered a session hijacking vulnerability on Facebook, the
guy who respond my messages didn't even know what secure flag is. After asking
me how to solve the bug (the solution was actually pretty simple) they never
replied to me again.

With Google was the same thing: last year I found leakage of sensitive user
information because of bad cookies configuration, 0 bounties 0 thanks.

Another bad experience I had with Google, but maybe a bit of topic (sorry):
almost two years ago the gmail's cert changed for apparent no reason using a
new CA, and it seemed that nobody else was having this issue (ie no mentions
of this new cert on the web, googling the fingerprint returned 0 results)
except me. I accepted this new cert on my laptop in my home; but then the
"funniest" thing happened: when I connected to gmail from my university the
previous cert appeared again, "it's ok.. nothing strange is happening here",
but then when I went back to my home the new cert showed up again! my paranoid
level went to over 9000 and immediately I connected through Tor to gmail (yup,
the old nice cert was there again) and sent an encrypted mail to google's
security team explaining everything, with the fingerprints and certs info,
_including_ at the end of my message my pgp pubkey. One week and a half
latter.. I received an email from the "security team": they replied my message
in plain text, my message was quoted unencrypted (!) and they asked me how I
discovered this, I told them that my browser checks for every new cert. I also
told them if it would be possible to not quote in plain text encrypted mails.
Then, after two days I got a new email from them, again plain taxt, and it was
pretty minimalistic "We checked out and the new certificate is ok" EOF no
digital signature no nothing, wtf! oh well... at least on the next day I
connected to gmail in my home and the old good cert was there again :) (and
the strange new cert never appeared again). A late Halloween story.

~~~
CJefferson
Did you even read the article? Did anyone who update you read the article?

This has nothing to do with security issues. It is to do with fixing specific
bugs in the D compiler and libraries.

~~~
pera
I did, but I think that although my examples are about security issues this is
another bounty program by the same company, why would they have a different
behavior?

~~~
qznc
You example is about bugs in Facebooks own application. This D bounty program
is more like Facebook throwing some money around to support an Open Source
project they use.

------
mkramlich
surface interpretation: they want them fixed

sneaky possible reason: recruitment strategy that's more likely to suss out
the more "elite" devs

likely: my bet, a mix of both

~~~
simendsjo
The sneaky possibility has already begun. You just have to follow the depths
of the newsgroup :)
[http://forum.dlang.org/post/l54orn$tn3$1@digitalmars.com](http://forum.dlang.org/post/l54orn$tn3$1@digitalmars.com)

------
hawkharris
Maybe they'll put a bounty on getting 13-year-olds to make wall posts instead
of sending self-destructing photographs.

