thomasdziedzic

I believe Stripe and Shopify only use RBI in production since Stripe develops Sorbet [0] and Shopify develops Tapioca [1]. Both tools work exclusively with RBI files instead of RBS files afaik. I haven't heard of anyone using RBS in production.

[0] - https://sorbet.org/

[1] - https://github.com/Shopify/tapioca

From the release notes, it looks like it only supports x86-64.

From the bug report [0] it sounds like they may also support ARM64 in the future.

[0] - https://bugs.ruby-lang.org/issues/18229

Gives me a "Page Not Found".

Unfortunately snowflake doesn't have a generate_series function equivalent. The closest thing it has is a generator function which only accepts constants: https://docs.snowflake.com/en/sql-reference/functions/genera...

I could probably have written my own javascript udf equivalent of generate_series though.

I use Squarespace to host my site.

Unfortunately it doesn't have native support for code highlighting besides html/css/js. I ended up using prism.js https://prismjs.com/ to highlight my code. The graphs are just screenshots that I've uploaded as pictures.

Snowflake's preview app called Snowsight provides a way to both query and visualize the data. https://docs.snowflake.com/en/user-guide/ui-snowsight-visual...

This is a great question and something that I probably should have at least mentioned in the blog post. I'm currently using the free trial since I signed up for it around Jan 15th. I am using the standard plan on AWS (US East Ohio).

Snowflake charges $2 per credit in compute costs on their standard plan and $40/TB/month in storage. See https://www.snowflake.com/pricing/ for more details. Since the beginning of my trial, I have used 9 credits and 40GB of storage. So I have used about (9 * 2) + ((40 / 1000) * 40) = $19.60 worth of resources so far. This isn't terrible but I must caution you that Snowflake costs could balloon pretty fast. That's why I also set up a resource monitor on my account to stop all warehouses when the number of credits reaches 20. https://docs.snowflake.com/en/user-guide/resource-monitors.h...

I would recommend if you were going to go my route, to setup resource monitors, and only use XSMALL warehouses which consume 1 credit / hour. Snowflake sizes warehouses in t-shirt sizes, and the credits consumed doubles each size up. So XSMALL = 1 credit per hour, SMALL = 2, MEDIUM = 4, LARGE = 8, XLARGE = 16, 2XLARGE = 32, 3XLARGE = 64 and 4XLARGE = 128.

Thanks for the suggestion. Added a rate_limit parameter to my script to play nicely with the api :) https://github.com/thomasdziedzic/hackernews-etl/commit/6dff...

According to https://unix.stackexchange.com/a/108605 it looks like only a logout and login was required for the changes to take effect. I didn't know this at the time which is why I initiated a reboot.

Ah thanks for mentioning this. I looked at the blog post and I seem to have prefixed an extra 1 to the number of requests done by my python script. I updated the post to include the actual calculation of 402 requests per second which is a lot less impressive but still much faster than my original approach on half the hardware.

Former archlinux developer here (maintained the haskell stack, coq, built an aur git repo, math packages, created 100s of packages, etc.), I think that this is a good thing:

I never used i686 even though I built for it.

The way I built packages was on my local laptop (clean chroot). Building for 2 separate architectures involves building 2 separate packages. This doubles the time it takes for a developer to build. This might not be that bad for smaller packages, but ghc (haskell compiler) took a long time on my computer. This means that if it takes an hour to build ghc, it would take 2 hours of my time to actually build ghc for both platforms. When you're talking about 100s of packages built many times over several years, this quickly adds up.

The other benefit from removing i686 support is that the packages built for that architecture were never really tested by developers. I ran x86_64 10 years ago, tested the x86_64 version of my packages, and most of the time pushed them directly to the main repositories if everything checked out. For more critical packages, I would push them to testing, let people report any issues, and then move them after a couple of days. This means that I never knew if i686 broke or not. This was the case with most of the developers at the time.

Link to code: https://github.com/symphonyoss/plexus-interop

The latest commit in the github repo has an example of an irc client: https://github.com/octaspire/dern/commit/fab2f5a2766a16fffc7...

> Children are seldom useful in the first 13-21 years of their life

[Citation Needed]

Dupe of https://news.ycombinator.com/item?id=14169797

Note:

"this example no longer appears in the documentation at all" - latest comment by steveklabnik

Not sure if you're joking or not but it does return a result for me. Try again more carefully.

This is an official migration. Here is a link to an actual source since I was originally skeptical because I know vim uses mercurial and that there have been unsuccessful discussions in the past.

http://article.gmane.org/gmane.editors.vim.devel/49968

Looks like as a result, vim is also switching to git for development.