ptarjan

HN Frontpage in Ingglish: https://ingglish.com/?url=https%3A%2F%2Fnews.ycombinator.com...

https://www.vimgolf.com/ is what taught me to VIM

The metric system seems like a similar analog to geometric algebra vs vector calculus. You are saying the same thing but the language you are using is much more internally consistent.

Adoption has been bumpy given the US resistance but I think in the long run it (or something even more consistent) will win out. Similarly I think geometric algebra will be adopted. Maybe not in our lifetimes but eventually.

> As for detecting gravitational waves, except for violent events like black hole mergers, we don't detect any; what few such gravitational waves there are are far too weak for us to detect.

I thought LIGO and VIRGO had been detecting gravitational waves for the last 4 years pretty regularly (i.e. once a week).

My favorite time I had to do this was for a real-life situation. I wanted a script that was both a bash script (for speed) and a ruby script (if you installed it the default way).

I came up with: https://github.com/sorbet/sorbet/blob/master/gems/sorbet/bin...

The parser for Sorbet was actually entirely given to us by GitHub. They were fabulous partners early on in the project and we're grateful for their contributions.

Nice spelunking! Yeah, this word means nothing really. Sigil, pragma, directive, typed comment, whatever. Feel free to call it "dohicky" if you'd like.

We believe that the main goal of a typechecker is to give you nice error messages. We've found giving names to things makes it easier for folks to reason about their errors, and introducing names for interfaces isn't that onerous at Stripe or with our beta testers.

We aren't opposed to eventually support it, but we'd like to see how it goes with the current form first.

Thank you! Ruby has been kind to us, we'd like to be kind back.

Thanks for the idea.

We used `params` because Method#parameters was what they called it in the standard library. I actually had it as `args` originally until someone pointed this out. https://ruby-doc.org/core-2.6.3/Method.html#method-i-paramet...

As for the syntax change, we are actually on our 8th iteration of the syntax. We really wanted this to NOT be a fork of Ruby so finding something compatible was very important. For example that's why it has the weird `sig {` syntax too, we didn't want to have to cause load-time and cyclic dependencies from adding type signatures.

Thanks for pointing that out. It can be called all of those. We liked sigil from its connotation:

> Google defines sigil as, “an inscribed or painted symbol considered to have magical power,” and we like to think of types as pretty magical

https://sorbet.org/docs/static#fn1

Great find! Fixing now, thanks.

Sorbet supports both formats. You can see the inline syntax on https://sorbet.run/

Hi and thank you for working on RDL! We do love the project and spoke with Jeff Foster a few times last year.

We did use your standard library annotations for Sorbet and have many fixes to them sitting in your pull request queue: https://github.com/plum-umd/rdl/pull/68 https://github.com/plum-umd/rdl/pull/72 https://github.com/plum-umd/rdl/pull/57 . We stopped submitting more since these weren't being upstreamed.

Before we started our project, I evaluated rolling out RDL instead of building our own typechecker. Trust me, I would MUCH rather use an existing project than have to build our own, but sadly it just didn't scale to our millions of lines of code.

I'm more than happy to chat about the details of why we didn't use RDL if you'd like to email me at sorbet@stripe.com. Thanks again for your great project, we're standing on the shoulders of giants.

Thank you so much for all the interest! We're flattered and excited to see all the discussion about the project.

Try it out: https://sorbet.run

If you would like to get in touch with us about anything, please email us at sorbet@stripe.com.

In the presentation at RubyKaigi (which will be available online soon) we explicitly mentioned we'd like to chat with folks trying to scale Ruby into the millions of lines of code, or folks also working on similar typechecking projects. Of course feel free to email even if you aren't in those groups, but I wanted to get your attention if you were.

It is a similar idea, yes.

(one of the authors here)

We'd love that too! We're chatting with the Ruby folks to see if anything like that is feasible. We experimented with lots of other syntaxes (comments, yarddoc, .rbi files, monkey-patching stdlib classes to be callable) and the `sig` syntax seems to be the easiest for folks to use inside Stripe.

After writing sigs for the past few months, I don't dislike it as much as I thought I would. You get the syntax highlighting and autocomplete of your editor, while `sig` and `T` are short enough to not feel like too much boilerplate.

We're very open to other suggestions if you have any for other syntax suggestions. Just email us at sorbet@stripe.com.

(author of the demo site here)

I just was looking for a quick editor for the demo, and ace seemed to work well for this. Thanks for the pointer to manaco, I'll look at that for next time.

Using an editor in the browser won't be the final product. We're planning on integrating into your editor of choice instead.

Thanks! The buckets are already done per-user so it is very simple to make the constant factors be user-dependent.

For my example in https://gist.github.com/ptarjan/e38f45f2dfe601419ca3af937fff... you would just set REPLENISH_RATE to be a different value for different users.

In a token bucket algorithm you don't actually have a separate replenish step, it is baked into the next check you do. Similar to how in the example you linked the removal of the old entries is baked into the check step.

Check out my example: https://gist.github.com/ptarjan/e38f45f2dfe601419ca3af937fff... on line 23 with

    local filled_tokens = math.min(capacity, last_tokens+(delta*rate))

that adds in any tokens that should drip into the bucket since the last check.

This can be done either way, and is really infrastructure dependent. There are pros and cons on both sides. We opted to bake it into the web stack instead of in front so that we get all the benefits of existing infrastructure like log aggregation, exception tracing, HTTP error response formatting and tracking, user-specific gating, auto service scaling, etc.

Thanks so much. I'm really glad you liked it.

Both should work. Token buckets only have to store two things (count and timestamp) where a timestamp set has to store all N timestamps. I like the simper approach since I don't actually need access to all the timestamps.

If you look at the concurrent request limiter I do indeed keep all the timestamps there in a Redis set. That one was more error prone to write in practice as I often would accidentally hit Redis storage limits.

We actually use the LUA scripts on Redis to guarantee the atomicity that the token bucket algorithm needs. Then the Ruby middleware does the HTTP 429 response logic. The code samples I provided are pretty close to what we use in production.

So yes, our Redis traffic is strictly higher than our whole API requests per second. This is actually pretty easy since Redis scales pretty well horizontally (the keys shard well) in addition to being able to handle many orders of magnitude more traffic than a normal web stack per machine.

Thanks for linking to your blog post. I like the simplicity of not having to enter the web stack at all. I'm not very familiar with varnish, how do you end up doing the actual rate limiting algorithm? I see you making a hash but not dripping tokens into a bucket.

We do have rate limits on some of our more crucial services (we don't use microservices per se, more like macroservices).

One difference for internal rate limits is we set alerts whenever they fire so that we can track down the client and see what they were doing. It is much easier to do that when you own both sides of the pipe.

Hi! I'm the author of the post and am happy to answer any questions you have.

There is also a corresponding set of code examples at the bottom that might be of interest to you: https://gist.github.com/ptarjan/e38f45f2dfe601419ca3af937fff...

Could you open source your code?

I'm sorry to hear about your experience contributing to HHVM. Which commit(s) were you talking about? I'd rather stop doing whatever got in your way so others don't have the same experience.

> Are you planning a Windows build ?

Yes. auroraeosrose is working on it (the same person who did the port for php) https://github.com/auroraeosrose/hhvm/tree/win32_start

I'd be interested in what feedback you get, so I can make sure all the top ones run well on HHVM. Can you email me your results?

Thanks (email at the top of http://paultarjan.com/ )