Flexible Feature Control at Instagram

engineering.instagram.com

11–12 of 12 posts

Re: Flexible Feature Control at Instagram

#11

Post by shivawu » Fri, Oct 02, 2015, 4:34 AM UTC

mikerg87 wrote: post #4

rbranson wrote: post #2

I was part of the team that designed this. AMA.

what advice would you give to someone who would be looking to implement this in a less dynamic language such as C# or Java? In your opinion is this only successful due to the dynamic and special language features of Python?

That's a very good question. It depends on your usecase. You can certainly do it in a more straightforward way, just design the language and write an "interpreter" to execute the language. But if performance matters, you'll have to generate native VM bytecode instead of the bytecode interprets the language.

I believe Java/C# both have this kind of tool to hook into the compiler and generate bytecode, either official or 3rd-party. For Java it might be asm, don't know a lot about C#, but since Microsoft has open-sourced their compiler, I think that's possible.

A lot of dynamic languages do provide native interpreter interaction, like Python AST, I'd say it makes things a lot easier, but totally doable in other "not-so-dynamic" language.

Might be hard with total compiled languages like C++ though, otherwise we have to distribute gcc/clang to the production machine :-p

Re: Flexible Feature Control at Instagram

#12

Post by shivawu » Fri, Oct 02, 2015, 4:54 AM UTC

mshang0 wrote: post #10

rbranson wrote: post #2

I was part of the team that designed this. AMA.

The systems that I've seen of this nature have been rules-based, like this: if A allow, else continue to next rule if B deny, else continue to next rule if C allow, else continue to next rule deny all For example, ufw rules have that form. I see a few advantages compared to Boolean operators: 1. Easier to diff and version control. 2. Easier to build UI for, for example, to show which rule fails for a particular user.…

I think this is all about trade off.

I do agree with your point 1,2,3, rule-based is better in some cases, but it's not as expressive, sometimes you have to express the logic in a non-straightforward way to satisfy your need, when the logic get complicated. We're trying to make the system flexible from the backend, and improve the usability at the UX level. For example, the constants inside the language will go to a separate section in the UI and will have various components of tuning them.

If the DSL code is organized well, it's going to look as clean as the rule based one.

Post reply on HN