angelbob

And even if you think "not the fediverse," Twitter is still dead. Let's get to "long live" something.

What do our oldest still-living langs have in common? What would it take for a programming language to make it to 100 years?

Disclaimer: I'm on the YJIT team.

In general it's not a big change. You should only turn on YJIT for long-running jobs -- the prod Rails server, plus probably background workers if you have them. YJIT does nothing unless you turn it on with the --yjit flag.

YJIT's going to affect memory usage, so it'll change your optimal number of processes and threads for your Rails server - play with it for your app specifically, because the percent speedup and mem expansion vary a lot from app to app. YJIT works fine with Puma and Webrick. I don't think anybody's tried it seriously with less-common servers like Falcon or Thin, but I'd expect it to work -- file a bug if it doesn't, because it should.

YJIT does speed up Rails - we're seeing about a 20%-25% speedup on little "hello, world" Rails apps (see: https://speed.yjit.org/), and about 11% on Discourse for a single thread. We don't have good multithreaded or multiprocess numbers yet, but it's in the works. YJIT scales with multiple threads/processes just like existing CRuby.

(All speed numbers are accurate as of right now, but may change over time.)

I would probably not use it in dev mode. While YJIT has pretty good warmup numbers, Rails throws away all existing application code for every request in dev mode. That's going to make YJIT a lot less useful. Play with it -- maybe I'm wrong for your app, especially if you use a lot of non-reloaded code (e.g. methods inside gems.) But I wouldn't expect great results in the development RAILS_ENV.

For deployment the short version is: add --yjit as a command line parameter in production mode and (probably) for your background workers. You can do this with "export RUBYOPT='--yjit'" or use your local preferred way.

Where I give weaselly-sounding qualifiers like "probably," that's because it can depend on your config. If you have plenty of memory but are often CPU-bound, YJIT is usually good. If you have really limited memory and your server CPUs are mostly idle, YJIT is usually bad. YJIT is also currently x86-only and runs on Mac and Linux but not Windows.

There has been a lot of historical demand for a Ruby config for servers: something that uses more memory to get faster operations, and that is optimised for long-running processes. YJIT is aimed directly at that. Non-JITted CRuby is mostly the opposite: fast startup, modest memory requirements, doesn't get significantly faster over time.

At least as of Ruby 2.6 I tried that and it really didn't work: http://engineering.appfolio.com/appfolio-engineering/2018/4/...

It may work a bit better now, but it's still very much not tuned for that. The result would probably still be slower than not JITting, for the same reasons mentioned for 2.6 in that link.

Earlier 2.6 versions of Ruby used 5 as the threshold. For a variety of reasons, that was way too low.

Nope, that's not what Bootsnap does. Bootsnap caches the pre-parsed .rb files as ISEQs (bytecode buffers.) It's conceptually a bit similar but not the same.

Weekly one-on-ones are pretty common in companies I've been part of, and GitHub has a lot of remote workers. Weekly one-on-ones seem more likely than not, in general.

This is very cynical, but not basically wrong.

Consider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.

Where are you at geographically? I've never had good luck with the local recruiters in Silicon Valley, but maybe they're better in places with less info about market rates?

That's a very solid list of submissions. Every fourth-or-so submission has hundreds or thousands of points. If you feel that's not great... Dunno. You're using a different yardstick than I am. That looks a lot like people consider his name to add credibility.

I got a raise of around $30,000 as a result (ish, hard to measure) of writing my technical book. I'm also sufficiently well-known that I'm unlikely to ever have trouble getting a Ruby job. That's hard to quantify exactly, but I think it's fair to say it's worth $5,000-$10,000 annually, as a rough equivalent.

(My book sells for around $30-$40 rather than $15, but the math is similar.)

At his price point, he'll probably get a continual trickle of customers. I sell a book called "Rebuilding Rails" -- not as successful as his, but I've also made a few tens of thousands of dollars, so not nothing. And I reliably make a few more thousands of dollars yearly, years after I wrote it.

After Ruby is a "hot" language (years ago), it becomes a legacy language where companies will pay money for assistance with their products. In the $10-$15 niche, you need individual engineers to think a language is neat. In the $40-$10,000 niches, you need companies to think they can save some engineering time.

Both can be very valuable.

I got a 1099-K from Gumroad this year, as did my wife. I think they're changing that.

If they've prepared a counter at $140, there's a decent chance they're (quietly) allowed to haggle up to some larger number, say between $145 and $160 depending on how much they want you and how much they expect you to negotiate.

They won't tell you what this higher number is under any normal circumstances, and may lie about it, but it probably exists.

They do. But separating those two roles and having two different people make those decisions tends to result in less-than-optimal decisions. It's the same kind of problem as "let's have the tech done by engineers and the business done by business people," and then your business gets bulldozed by a competitor whose CEO does understand engineering.

Patrick had already spun down his consulting business before this happened -- I think before Starfighter started, even.

It was lucrative, but not pleasant, and he made more enjoyable money working for himself.

Call/cc is actually used by Sinatra for its error handling. There's not a good way to get its syntax without doing it that way.

(Is the syntax worth using call/cc? Eh, good question. But Sinatra's killer feature is, literally, its syntax, so I don't think I get to tell them "don't do it that way." Rails has an ugly workaround for not using call/cc that bites many, many app programmers who forget to return after calling render().)

If you read the article, there are a number of characteristics of Zika that make it a lot easier to vaccinate against. Also, apparently they do have vaccines against some strains of Dengue.

Cassandra, for instance, makes it possible to query your join-type tables in relatively manual chunks using slice queries. You have to do a lot more of it in the application so you wind up with weird partial failures...

But at scale, weird partial failures, results as they are found and eventual consistency are usually preferable to a really long DB query that never returns.

Above a certain scale, big joins are simply not usable. NoSQL's manage-it-yourself approach is good for getting partial results where full results are too expensive.

You can think of it as applying a heuristic approach where an exact approach is too expensive, if it makes you feel less like NoSQL sullies the purity of databases :-)

Sometimes this is very hard to do. This is in effect Twitter's core use case as well, with the list of accounts you follow.

And it's a hard problem. Twitter spawned a huge wave of NoSQL to deal with this, and it's still not really dealt with.

You're not wrong. But mostly we haven't collectively agreed that relational databases aren't great for highly-indexed rapid-update join tables.

I think we will at some point. That's the primary original use case for a lot of NoSQL, and the reason Twitter had so much trouble with relational databases.

But these are cultural understandings, and those move slowly. Also, we're poorly (collectively) equipped to handle subtlety in these discussions, so mostly we're trying to move from "relational databases are perfect for all use cases" to "NoSQL databases are perfect for all use cases" -- which is even less true, not more true.

Culturally, this is a hard thing to keep in our collective brain.

Right, but they need criminal or treasonous intent, or gross negligence. "Broke the law" isn't enough, in the same way that old jaywalking charges don't generally get brought up against you, even if somebody can prove it with security camera footage. The bar gets higher when you're digging up old stuff.

This story has a ridiculous amount of integrity. You did what was right, even when convention went the other way.

Future investor reaction to it will tell us what they think of actually bucking convention to do the right thing.

Some of that is related to the article talking about differing nausea when synthetic imagery was different distances away -- it depends a lot on what you're looking at.

He's certainly right that in AR (where you literally don't mess with a lot of the scenery, sometimes most of it, because you use a transparent visor), these problems are often less severe.

It's less of a "sufficiently smart compiler" argument and more of an "if you only touch 5% of the scene, the other 95% is just looking through glasses, and people do that just fine" argument.

But then AR's going to have a similar motion problem when you're up close to synthetic imagery instead of only having a little bit of it as an overlay.

I do kind of wonder whether sock-puppet accounts were a significant factor. I wouldn't necessarily expect them to follow the same gender distribution as the folks abusing.

Presumably the highly unfair treatment of a whistleblower. Snowden gets a lot more publicity, but Manning's case wasn't well handled either.

I think Ruby may still have a few under-recognized advantages for small teams :-)