anp

I use this word the way we did when I worked as a PC technician and help desker, where there's a lot of automation but then we sneak a bit of manual labor in to make it actually useful. Like how user accounts would be maintained in the correct state automagically.

I currently do something pretty similar by using the perf subsystem in the Linux kernel to track the behavior of each benchmark function. In my early measurements I found concurrent benchmarking to introduce unacceptable noise even with this measurement tool and with cgroups/cpusets used to pin the different processes to their own cores. Instead of trying to tune the system to account for this, I chose to build tooling for managing a single runner per small cheap machine.

Each benchmark result is only compared against values from running on literally the same machine, actually. I agree that good results here would be extremely difficult to produce on virtualized infra, so I rented a few cheap dedicated servers from Hetzner. I'm glad that I decided to pin results to a single machine, because even between these identically binned machines from Hetzner I saw 2-4% variance between them when I ran some phoronix benches to compare.

I go into a little bit of detail on this in the talk I link to towards the bottom of the post, here's a direct link for convenience: https://www.youtube.com/watch?v=gSFTbJKScU0.

Thanks!

Not yet, but I am tracking this as a desired feature: https://github.com/anp/lolbench/issues/9. The benchmark plan generation, storage keys, and results presentation will at a minimum need to be extended to support a matrix of inputs to each benchmark function. Right now there are a number of implicit assumptions that each benchmark function is tracked as a single series of results.

hi! author here if you want to ask questions or (nicely pls) let me know where I've made mistakes!

I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+rust/c++ is interesting in part because you can get so much more predictable performance out of the box. When the performance comes from language features instead of VM-specific optimizations the performance might be easier to maintain across revisions and hopefully will be less subject to regression from VM changes.

Can you be specific about which languages you include in the category of "fast and SAFE"?

> No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol.

This also involves a marshalling cost at the ABI boundary, which may be lower overhead than parsing JSON, but is significantly more brittle. And it's less ergonomic for many plugin/editor authors. And it can't be spec'd with a schema that isn't just "read the headers."

I'd wager that using C prevents large classes of errors that would be common place in assembly.

That said, colloquial history seems to say that there were plenty of languages which did a better job at that than C.

By default rust doesn't allow out of bounds indexing (indexing and iteration are checked, although bounds checks are often optimized out), you have to explicitly write unsafe code to read off the end of an array or vector.

As a general reply to a variety of the complaints in this thread: don't underestimate the task that triplebyte has in selling you to companies, especially since they have focused on candidates who might not even get an onsite interview at companies on their own. Their process also involves helping candidates skip a lot of the interview pipeline at several companies at a time, so that you can get better offers. This means that companies have to place a lot of trust in their assessment, and my personal experience (having gone through the process and gotten a job through them) is that they have to be very very rigorous to sell companies on their model.

My interviews with triplebyte were definitely some of the hardest ones I had during my search, but they also focused on things I consider important in developing software in a way that no other interview pipeline I've been through has. It may be that my overwhelmingly positive experience with them is not reflective of most, but I think that's unlikely given the amount of work they put into standardizing their process.

Being on the side of engineers in the hiring process does not mean they can take it easy on interviews, and my experience would suggest that whatever personal intensity you may feel in an interview with them is very likely to be outclassed by any decent sized sample of interviews at a big company.

I'm definitely bullish on their model, and while the process isn't perfect I'm really excited to see them moving the needle on interview quality in the industry. I sincerely wish them the best with the expansion.

My personal experience with Rust (vs. Go and other languages) is that there is something really magical that all the sigils and syntactic complexity give you: once you've internalized Rust's approach it's ridiculously easy to build an accurate mental model of what's happening in almost any piece of code. From the high level constructs down to generated assembly, Rust produces the most predictable code I've ever written. While not the same kind of simplicity you're describing, my experience is that the value of Go's simplicity is to give you a low overhead mental model. While Rust has some complexity, I personally find it to have the lowest overhead mental model of anything I've worked with, due to its predictability, explicitness, and strong conventions.

Granted, it definitely took some time for me to gain the experience necessary for this magic to occur. It's not really a "hack a quick thing together once every 10 years" kind of language.

It's hard to convey this without getting you to actually learn Rust for a few days/weeks/months, but it's certainly been my experience and I hear it all the time from other Rust developers.

Anything involving asynchronous operations has historically been painful with Django. I know that new versions are improving on this, but I think for now it's limited to web sockets.

> But most likely - you simply do not need a language without a GC.

Absolutely. That doesn't mean I can't want predictable performance or deterministic destruction. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up (i.e. on the overhead of managed runtimes and GCs). Before, I'd have argued that it was just necessary. Having spent a bunch of time with Rust, I don't think so any more, and I'm really excited to see non-GC languages build on Rust's ideas in the future.

> Hadoop stack with especially Cassandra, Elasticsearch? Java. Prometheus and InfluxDB? Go.

Cassandra has a drop-in-ish C++ replacement (Scylla, IIRC?) which supposedly blows the Java implementation away in performance. A magic JIT (and HotSpot is really magic) doesn't make everything better all of a sudden.

In a somewhat recent panel (https://www.infoq.com/presentations/c-rust-go), the CEO of InfluxDB basically admitted that if Rust had been more stable when they started they would have been able to use it instead of Go and would have had to do far fewer shenanigans to avoid the GC penalty.

> Just face it: there is an need for something intermediate to fill the gap of a script-like, native compiled, low-overhead, modern language, and a GC is part of this.

Indeed. I'm not in denial of this. I made an offhand remark about my personal preferences and what I'd like to see from future languages. I still write a ton of Python for things where speed really doesn't matter.

> "oh no, a GC!" knee-jerk reaction

I don't think having a refreshing experience without a GC counts as a "knee-jerk reaction." I've thoroughly enjoyed not having to tune that aspect of performance, and I remarked on it. I think Crystal shows great promise, and certainly has the potential to offer easier ergonomics than Rust.

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now.

But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go away.

EDIT: I should also say that if you want to bash on Rust's lack of these things, 3 out of the 4 items I cited have solutions being actively worked on (either at planning, RFC, or implementation phase). I don't think Rust's sigils are going away any time soon, but I have no idea how you'd do that and preserve semantics anyway.

Nitpick: GC is technically optional in Rust, because you can stick pretty much anything in a reference-counted box or an atomically-reference-counted box (Rc<T> or Arc<T>). It's not the default by any means though.

I'm definitely a Rust fanboy, but the single-quote syntax for lifetime annotations can be irritating. Several editors I've used automatically insert a second quote to match, and I am frequently unable to disable that behavior without losing all paired delimiter insertion (like for parentheses or braces).

It's a minor quibble to be sure, but it's the only language symbol that bothers me when writing Rust. Not sure what I'd suggest replacing it with...backtick, maybe? Pipe? @? ~?

There aren't many other special characters on a QWERTY board that aren't already used in Rust. Which I think gets at one of the stumbling blocks that I see in the various Rust syntax bikesheds among those who haven't worked in the language. It's just alien until you've used it a bit, especially if you're writing a lot in pseudocode-y dynamic languages.

Thanks very much for the detailed and thoughtful answers!

I've read before (somewhere, I think) that Dropbox effectively maintains a large internal "standard library" rather than relying on external open source efforts. How much does Magic Pocket rely on Rust's standard library and the crates.io ecosystem? Could you elaborate on how you ended up going in whichever direction you chose with regards to third-party open source code?

steveklabnik also pointed out on the Rust subreddit that there's a Dropbox blog post covering a few more technical items:

https://blogs.dropbox.com/tech/2016/03/magic-pocket-infrastr...

Only responding to one element of your comment -- but I think that Rust's safety features are over-marketed in my experience. The safety Rust offers is only part of a package that provides high-performance high-level abstractions over functionality that is normally very bit-twiddly in C. So far, my favorite thing about Rust is not its safety, but how easy it is to write good performance software using abstractions that are as convenient as Python (or another high-level language). The safety is just icing on the cake at that point (for me at least).

EDIT: Re: pointers -- Rust is a lot easier to write if you just ignore pointers. Really. Either pass small structs by value or pass references (either immutable or mutable), and let the compiler handle the actual pointer manipulation.

Re: low-level Rust, I've been really enjoying following this series:

http://os.phil-opp.com/

It shows a variety of ways to safely wrap unsafe code and then provide strongly-typed safe interfaces to the hardware, no pointer twiddling required. A particularly good example is the section "Some Clever Solution" in the "Page Tables" post.

I haven't used it yet, but apparently Rust's FFI with C (in both directions) is quite good:

https://doc.rust-lang.org/book/ffi.html

I get the impression that this is a purposeful misunderstanding, mostly for kicks and giggles. Maybe I'm wrong? But it certainly seemed tongue in cheek to me, aimed at bringing a fresh perspective to a work that's already been picked over a billion times by fans.

This is addressed in the article:

"Now, in his conversation with Frodo, Bombadil implies (but avoids directly stating) that he had heard of their coming from Farmer Maggot and from Gildor’s elves (both of whom Frodo had recently described). But that also makes no sense. Maggot lives west of the Brandywine, remained there when Frodo left, and never even knew that Frodo would be leaving the Shire. And if Elrond knows nothing of Bombadil, how can he be a friend of Gildor’s?

What do we know about Tom Bombadil? He lies."

The only word we have is Bombadil's. Not that I buy this interpretation, but your complaint is addressed there.

I've seen this sentiment a few times: "don't try to replicate native apps in the browser." Which makes sense from the standpoint that the browser is just getting ridiculous, like a mini-OS unto itself.

However, web apps also allow organizations to write once for many platforms in a much more seamless way than most cross-platform native toolkits I've seen. It's the same reason that desktop Java was in vogue for a little while: you only have to write one UI, and you can run it from a HTTP connection with almost no local permissions. Of course, this was (and still is) a security nightmare, but browsers now do a pretty good job of sandboxing individual code blobs, and also do a pretty good job of abstracting away the native UI. Web apps also provide low or zero installation overhead (low friction to getting a user onboarded/working/monetized/whatever).

It would be nice to see some progressive enhancement folks address how to resolve these pain points on the native side, rather than just saying web shouldn't be like native.