3 ms·

We're comparing just to the original consumer product, which is about the same as Mastodon is today. That's why we said "original consumer product" and not "Twi

We're comparing just to the original consumer product, which is about the same as Mastodon is today. That's why we said "original consumer product" and not "Twitter's current consumer product". Mastodon actually has more features than the original Twitter consumer product like hashtag follows, global timelines, and more sophisticated filtering/muting capabilities. Some people argue it's not so expensive to build a scalable Twitter with modern tools, which is why we also included the comparison against Threads. That's a very recent data point showing how ridiculously expensive it is to build applications like this, and they didn't even start from scratch as Instagram/Meta already had infrastructure powering similar products.

ehutch79 3y ago
Are you sure about that. With things like twitter, the ui is not the hard part. Things like moderation are the secret sauce. All the corner cases and support for devopsy stuff likely account for a lot. Routing to specific instances for celebrities and such.
- justrealist 3y ago
  Nathan worked at Twitter so while he might be wrong, I don't think it's reasonable to assume he's just naive http://nathanmarz.com/blog/leaving-twitter.html http://nathanmarz.com/blog/leaving-twitter.html.
  - ehutch79 3y ago
    I misread the parent. I originally read it as it's easy to clone twitter. My response is it's easy enough to build a micro-blogging platform/service. it's all the other shit like moderation, regulatory/legal compliance, making a profit, keeping advertisers happy, etc that's hard.
doctorpangloss 3y ago
I work in gaming, so I cannot speak to your specific experiences. Entity Component Systems are extremely performant, really good science, and shipping in middlewares like Unity. However, in order to ship an ECS game, in my experience, you have to have already made your whole game first in a normal approach, in order to have everything be fully specified sufficiently that you can correctly create an ECS implementation. In practice, this means ECS is used to make first person shooters, which have decades of well specified traditions and behavior, and V2 of simulators, like for Cities Skylines 2 and Two Point Campus. So this is not meant to diminish the achievements of what you have built at all, it is more intellectually honest to say that "any high performance framework is most suitable for projects that are exact clones of pre-existing, mature things with battle-hardened specifications and end user behavior." While this might cover some greenfield projects, including the best capitalized ones that may matter to you, it does diminish the appeal of a framework for the vast majority of success stories from small & poorly capitalized teams. Those small & poor teams are very innovation and serendipity driven and hence rarely copying a pre-existing thing. And even if they try to become well-capitalized, they are almost always doing so by having worked on the thing they are copying already (i.e., already shipping version 1.0 for years).
- syntheweave 3y ago
  Yes, this is along the lines of what I'm suspicious of too, as an also-gamedev that has done some ECS. It's too easy to study an existing system and, given the resources, create a perfect demo for how to dramatically improve it in certain ways. You can go on to ship the demo, but the demo wasn't made by the same kind of organization, with the same kinds of goals, as the original system builders. The extreme example of this is, of course, the demoscene and its hardware-bending tricks that achieve the impossible through a significant modification to the design of a "production" equivalent. So it's better by performance metrics, better by codesize, but unknown on other metrics. Like, "do I know how to start building new things with this?"
  - moate 3y ago
    Asking “what are you optimizing for/building towards” and getting different answers for different products isn’t proof that either is inferior, just that they may be better at different things. Your comment makes it seem like their post is misleading, when it isn’t it just might be that what they do best isn’t useful to you (or possibly anyone).
- tacotacotaco 3y ago
  I only hobby in game dev. I have read some basics of ECS and IMO it seems a lot more intuitive than the “normal approach”. I think this is a case of using familiar tools we are comfortable with, not necessarily better. Unity’s ECS implementation is a hot mess though. I am looking forward to seeing what Bevy delivers as it matures. I agree that copying an existing product will be easier and is usually cheaper and more performant because you can leverage your competitor’s R&D and lessons learned. I presume this is why some tech companies’ product lines are full of clones.
- danbolt 3y ago
  I can’t go into specifics due to NDAs, but I’ve been a developer on a game that was designed and programmed with the EnTT library from the ground up. [1] I don’t know if I’d suggest ECS for every team as you need the right tooling, culture, and leadership to pull it off. That said, I think the paradigm has unrecognized benefits when it comes to greenfield gameplay programming. Or, your data structures become a way for sub-teams to communicate and share state without stepping on one another’s toes. A group handling pathfinding and a different one handling scenario/mission logic can both pay attention to the position data without needing to be highly coupled. It becomes easy to “just add a system” or “an extra component” to build on existing functionality. The Fred Brooks quote about “showing me your tables” comes to mind. [1] https://www.minecraft.net/en-us/about-legends https://www.minecraft.net/en-us/about-legends
deltree7 3y ago
[dead]
reissbaker 3y ago
I worked on a previous iteration of Threads at Instagram, and I don't think the 25 person-years number you're estimating spent on the project was spent primarily on backend engineering. They concurrently launched native iOS and Android apps, and I think you're also factoring in the IC count from the linked article to mean full-time ICs dedicated exclusively to Threads, which is probably not how it worked. (Although TBH I'm not sure how you arrived at 25-person-years from the article, which said the project started with "dozens" of engineers and peaked at 50, and was 7 months long in total — a simple average of 24-50 engineers for 7 months, even if you assume they're all full time, would be about 21 person-years). When I was at IG, my team was 20-something ICs full-time on our project, bursted to maybe double that as necessary in part-time help from ICs in the wider org. We had a total of three backend engineers, of which I was one, as well as a backend intern for a few months, although we bursted the backend team for a couple of months to four for some ML help. Your project sounds pretty cool! But I don't think the comparison to Threads productivity is quite right. The majority of IG engineering is focused on building polished native clients, not generally on backend infrastructure. It's true that Meta already has a lot of the backend infra built — if Red Planet Labs can come close to what you get at Meta, that's pretty amazing. But I don't think the numbers you're quoting are apples-to-apples, or mean quite what you think they do. I don't know if this version of Threads operated exactly like the one I worked on (a Snapchat competitor), but I'd be pretty surprised if there was a product team at IG that was majority backend. (Edit: I also think it's worth keeping in mind the experience levels of who works on these projects — at IG it's usually a smaller number of E6/E5s guiding a larger number of E4/E3s. Person-years are not all equivalent! If you spent ten years building the Red Planet Labs infrastructure based on your time at Twitter, nine person-months of your team's time building a product on your infra might not be the same as nine person-months of someone else's.) Anyway — I don't mean to downplay your product, and really, if it's anything like the backend productivity I experienced at Meta, that would be pretty groundbreaking. Curious to see what you launch :)
dpweb 3y ago
Built some log databases and back end frameworks myself with some of the same concepts. I applaud the creativity in rethinking how back ends should work. Please now do frontends next! :) "But it's not a fully functioning 2023 Twitter!!!" I think some people miss the point. This is not about hey we built a Twitter clone. This is about a POC for a novel app architecture. We need to be constantly examining and re-examining our thoughts about the best way to deal with distributed systems, scale, developer workflow. Even inventing new ones.
- philipwhiuk 3y ago
  > This is not about hey we built a Twitter clone. Then they shouldn’t have titled it “we built a Twitter clone”

ehutch79 3y ago

Are you sure about that. With things like twitter, the ui is not the hard part. Things like moderation are the secret sauce. All the corner cases and support for devopsy stuff likely account for a lot. Routing to specific instances for celebrities and such.

justrealist 3y ago
Nathan worked at Twitter so while he might be wrong, I don't think it's reasonable to assume he's just naive http://nathanmarz.com/blog/leaving-twitter.html http://nathanmarz.com/blog/leaving-twitter.html.
- ehutch79 3y ago
  I misread the parent. I originally read it as it's easy to clone twitter. My response is it's easy enough to build a micro-blogging platform/service. it's all the other shit like moderation, regulatory/legal compliance, making a profit, keeping advertisers happy, etc that's hard.

doctorpangloss 3y ago

I work in gaming, so I cannot speak to your specific experiences. Entity Component Systems are extremely performant, really good science, and shipping in middlewares like Unity. However, in order to ship an ECS game, in my experience, you have to have already made your whole game first in a normal approach, in order to have everything be fully specified sufficiently that you can correctly create an ECS implementation. In practice, this means ECS is used to make first person shooters, which have decades of well specified traditions and behavior, and V2 of simulators, like for Cities Skylines 2 and Two Point Campus. So this is not meant to diminish the achievements of what you have built at all, it is more intellectually honest to say that "any high performance framework is most suitable for projects that are exact clones of pre-existing, mature things with battle-hardened specifications and end user behavior." While this might cover some greenfield projects, including the best capitalized ones that may matter to you, it does diminish the appeal of a framework for the vast majority of success stories from small & poorly capitalized teams. Those small & poor teams are very innovation and serendipity driven and hence rarely copying a pre-existing thing. And even if they try to become well-capitalized, they are almost always doing so by having worked on the thing they are copying already (i.e., already shipping version 1.0 for years).

syntheweave 3y ago
Yes, this is along the lines of what I'm suspicious of too, as an also-gamedev that has done some ECS. It's too easy to study an existing system and, given the resources, create a perfect demo for how to dramatically improve it in certain ways. You can go on to ship the demo, but the demo wasn't made by the same kind of organization, with the same kinds of goals, as the original system builders. The extreme example of this is, of course, the demoscene and its hardware-bending tricks that achieve the impossible through a significant modification to the design of a "production" equivalent. So it's better by performance metrics, better by codesize, but unknown on other metrics. Like, "do I know how to start building new things with this?"
- moate 3y ago
  Asking “what are you optimizing for/building towards” and getting different answers for different products isn’t proof that either is inferior, just that they may be better at different things. Your comment makes it seem like their post is misleading, when it isn’t it just might be that what they do best isn’t useful to you (or possibly anyone).
tacotacotaco 3y ago
I only hobby in game dev. I have read some basics of ECS and IMO it seems a lot more intuitive than the “normal approach”. I think this is a case of using familiar tools we are comfortable with, not necessarily better. Unity’s ECS implementation is a hot mess though. I am looking forward to seeing what Bevy delivers as it matures. I agree that copying an existing product will be easier and is usually cheaper and more performant because you can leverage your competitor’s R&D and lessons learned. I presume this is why some tech companies’ product lines are full of clones.
danbolt 3y ago
I can’t go into specifics due to NDAs, but I’ve been a developer on a game that was designed and programmed with the EnTT library from the ground up. [1] I don’t know if I’d suggest ECS for every team as you need the right tooling, culture, and leadership to pull it off. That said, I think the paradigm has unrecognized benefits when it comes to greenfield gameplay programming. Or, your data structures become a way for sub-teams to communicate and share state without stepping on one another’s toes. A group handling pathfinding and a different one handling scenario/mission logic can both pay attention to the position data without needing to be highly coupled. It becomes easy to “just add a system” or “an extra component” to build on existing functionality. The Fred Brooks quote about “showing me your tables” comes to mind. [1] https://www.minecraft.net/en-us/about-legends https://www.minecraft.net/en-us/about-legends

deltree7 3y ago

[dead]

reissbaker 3y ago

I worked on a previous iteration of Threads at Instagram, and I don't think the 25 person-years number you're estimating spent on the project was spent primarily on backend engineering. They concurrently launched native iOS and Android apps, and I think you're also factoring in the IC count from the linked article to mean full-time ICs dedicated exclusively to Threads, which is probably not how it worked. (Although TBH I'm not sure how you arrived at 25-person-years from the article, which said the project started with "dozens" of engineers and peaked at 50, and was 7 months long in total — a simple average of 24-50 engineers for 7 months, even if you assume they're all full time, would be about 21 person-years). When I was at IG, my team was 20-something ICs full-time on our project, bursted to maybe double that as necessary in part-time help from ICs in the wider org. We had a total of three backend engineers, of which I was one, as well as a backend intern for a few months, although we bursted the backend team for a couple of months to four for some ML help. Your project sounds pretty cool! But I don't think the comparison to Threads productivity is quite right. The majority of IG engineering is focused on building polished native clients, not generally on backend infrastructure. It's true that Meta already has a lot of the backend infra built — if Red Planet Labs can come close to what you get at Meta, that's pretty amazing. But I don't think the numbers you're quoting are apples-to-apples, or mean quite what you think they do. I don't know if this version of Threads operated exactly like the one I worked on (a Snapchat competitor), but I'd be pretty surprised if there was a product team at IG that was majority backend. (Edit: I also think it's worth keeping in mind the experience levels of who works on these projects — at IG it's usually a smaller number of E6/E5s guiding a larger number of E4/E3s. Person-years are not all equivalent! If you spent ten years building the Red Planet Labs infrastructure based on your time at Twitter, nine person-months of your team's time building a product on your infra might not be the same as nine person-months of someone else's.) Anyway — I don't mean to downplay your product, and really, if it's anything like the backend productivity I experienced at Meta, that would be pretty groundbreaking. Curious to see what you launch :)

dpweb 3y ago

Built some log databases and back end frameworks myself with some of the same concepts. I applaud the creativity in rethinking how back ends should work. Please now do frontends next! :) "But it's not a fully functioning 2023 Twitter!!!" I think some people miss the point. This is not about hey we built a Twitter clone. This is about a POC for a novel app architecture. We need to be constantly examining and re-examining our thoughts about the best way to deal with distributed systems, scale, developer workflow. Even inventing new ones.

philipwhiuk 3y ago
> This is not about hey we built a Twitter clone. Then they shouldn’t have titled it “we built a Twitter clone”