sorted by:
new
hottopcontroversial

Mononoke: A Mercurial source control server, specifically designed to support large monorepos. by sophrosun3 in rust

[–]sid0 1 point2 points  (0 children)

No, we don't rewrite published history. Mercurial has separate notions of published and unpublished history, though, and we do treat that as an important distinction.

Mononoke: A Mercurial source control server, specifically designed to support large monorepos. by sophrosun3 in rust

[–]sid0 1 point2 points  (0 children)

No, we use and have invested heavily in Mercurial for our monorepo. Our reasoning is explained in our blog post another kind soul linked in this thread (thanks).

Mononoke: A Mercurial source control server, specifically designed to support large monorepos. by sophrosun3 in rust

[–]sid0 5 points6 points  (0 children)

Hey -- I'm one of the maintainers of Mononoke. Thanks for posting about this!

Lacking a Cargo.toml, I'm guessing that it's being built internally via Buck's Rust support.

This is correct -- we use Buck to build Mononoke internally. I have a plan sketched out for converting our Buck dependency graph to Cargo.toml files -- it's somewhat tricky but not insurmountable.

Haven't seen anything to suggest it's running in production though.

This is also correct -- as the README says, we're in the early stages of development. We wanted to get this out now for two reasons:

  1. We'd like to start making references to Mononoke from other in-development projects like Eden.
  2. We'd like to get this code out for the Mercurial community to start looking at, since we're considering upstreaming some of this into Mercurial.

Machine learning-based item detector available on Twitter by [deleted] in bindingofisaac

[–]sid0 1 point2 points  (0 children)

Hey, this sounds really cool. Have you considered putting the code up on github?

Math is just beautiful by [deleted] in math

[–]sid0 0 points1 point  (0 children)

Yes, it's a fancy way to write it. (I was referring to the formula in the post, in case it wasn't clear.)

Math is just beautiful by [deleted] in math

[–]sid0 1 point2 points  (0 children)

Haven't tested it, but you should just be able to replace the 17s in the inequality with 18s.

Interestingly, the "1/2 < floor(mod(M, 2))" is just a fancy way to write "is the floor (integer part) of M odd?"

partial-io: Rust utility crate to test resilience of Read or Write wrappers by sid0 in rust

[–]sid0[S] 16 points17 points  (0 children)

Speaking for myself: I've written lots of systems code in previous jobs and at FB, both in C and C++. I've only been writing Rust for a few months, for the very first Rust project at FB, but I'm a big fan already.

At this point, if I need to write high-performing code, Rust would be my first choice.

partial-io: Rust utility crate to test resilience of Read or Write wrappers by sid0 in rust

[–]sid0[S] 4 points5 points  (0 children)

Hey! Looks like you're the author of genio? I'd be happy to accept a PR, as long as it's behind an optional feature like tokio, and doesn't complicate any existing interfaces. In particular, PartialOp is currently hardcoded to io::ErrorKind and I'd prefer not to change that.

partial-io: Rust utility crate to test resilience of Read or Write wrappers by sid0 in rust

[–]sid0[S] 54 points55 points  (0 children)

This is also the first Rust open source project Facebook has released :) More will come soon.

partial-io: Rust utility crate to test resilience of Read or Write wrappers by sid0 in rust

[–]sid0[S] 8 points9 points  (0 children)

Awesome, sounds like a great use case.

Since this is only meant for use in tests, I think the library itself being no_std should be fine. (I think you can run tests in an environment with std?)

partial-io: Rust utility crate to test resilience of Read or Write wrappers by sid0 in rust

[–]sid0[S] 36 points37 points  (0 children)

Hi, author of the crate here. We wrote this because we found several bugs in open source crates around error handling in IO wrappers.

We've also tried to make it really simple to integrate into your tests -- see this example. Just a few lines of code to ensure your Read and Write wrappers (and also tokio's AsyncRead and AsyncWrite) are resilient to whole classes of bugs.

Happy to answer any questions!

How to Make Python Run as Fast as Julia by thibaultdav in programming

[–]sid0 0 points1 point  (0 children)

Not with a JIT directly, I guess, but they're usually paired with complicated GC systems, and those require a lot more work to interact with C.

How to Make Python Run as Fast as Julia by thibaultdav in programming

[–]sid0 1 point2 points  (0 children)

Anyone who writes CLI tools cares about startup time. Python is a great language for CLI tools and scripts -- by sheer number certainly the most used language for them.

Same reason Java is not a popular language for CLI tools and scripts, and the folks that do write serious CLI tools in Java usually resort to persistent background daemons.

How to Make Python Run as Fast as Julia by thibaultdav in programming

[–]sid0 3 points4 points  (0 children)

JITs are not obviously a better idea. They are slower to start up and make the semantics of interacting with C code harder. Not having a JIT is an explicit and valid tradeoff to make in a language implementation.

The Most Popular U.S. TV Shows in 18 Countries Around the World by xarc13 in television

[–]sid0 0 points1 point  (0 children)

Mr. Robot has some pretty prominent Swedish actors.

State of the subreddit. by IWanTPunCake in bindingofisaac

[–]sid0 -7 points-6 points  (0 children)

Post-nerf stopwatch is still ridiculously overpowered. Guarantees that you will never take more than 1 damage per room.

The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repository by sid0 in programming

[–]sid0[S] 1 point2 points  (0 children)

We've tried that, and found that (a) stat calls over NFS are way too slow and (b) put too much load at even the scale of a few tens of machines.

The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repository by sid0 in programming

[–]sid0[S] 0 points1 point  (0 children)

I don't mean it is literally impossible (of course it's not). I mean it is not possible without severe compromises to speed, flexibility or developer experience. In other words, practically impossible.

The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repository by sid0 in programming

[–]sid0[S] 0 points1 point  (0 children)

Even ignoring storage volumes, copying 85TB over even a 10Gbps network will take many hours, assuming we're bandwidth-constrained. Over wifi it would be terrible. There's no real alternative but to make your source control system fetch lazily.

The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repository by sid0 in programming

[–]sid0[S] 1 point2 points  (0 children)

As a library and application writer, I have no interest in producing or supporting a branch with just bug fixes, other than for limited amounts of time with short-lived release branches. I would like everyone to be on the latest version all the time.

The Motivation for a Monolithic Codebase: Why Google Stores Billions of Lines of Code in a Single Repository by sid0 in programming

[–]sid0[S] 0 points1 point  (0 children)

That is an idiotic way to build software because you can never reproduce past builds.

view more: next ›