Viewing last 25 versions of post by byte[] in topic Philomena open beta / breaking API changes

byte[]
Verified Pegasus - Show us your gorgeous wings!
Preenhub - We all know what you were up to this evening~
An Artist Who Rocks - 100+ images under their artist tag
Artist -

Philomena Contributor
"@Angius":/forums/meta/topics/philomena-open-beta-breaking-api-changes?post_id=4630684#post_4630684
[bq]Paradigm, as in from OOP (with some procedural and functional sprinkled in) to a fully functional language.[/bq]Oh, that kind of paradigm. I thought you were talking about MVC vs MVVC etc. It might surprise you then to hear that we were basically writing Ruby in almost functional style anyway. Most of the method calls in our code (the stuff that does "actual work" as opposed to just database interaction) are to "Enumerable":https://ruby-doc.org/core-2.6.5/Enumerable.html and to "ActiveSupport::CoreExt":https://edgeguides.rubyonrails.org/active_support_core_extensions.html. There are vanishingly few class structures we have, and only one or two actually _use_ inheritance or true polymorphism, because it basically isn't needed. (There's also some broken "STI":https://github.com/derpibooru/philomena/blob/54be9dfa5d2e75b7b288a0ff61614d0bbba7c344/priv/repo/structure.sql#L164-L190 that I aim to fix... uh, at some point, but that doesn't really count.)
[bq]Not sure what you mean when it comes to Ecto and being tied down by schema. Not quite sure how it works with Django, but most modern ORMs let you design the schema code-first and use migrations[/bq]"If you read my post on why I decided to do this rewrite":https://www.patreon.com/posts/booru-on-rails-29380128, it sets out my reasoning. Basically the ORM structure provided by ActiveRecord ended up slowing us down considerably after schema changes _where we should have been getting faster_, and I had at that point just had enough of it. The reason for this slowing down was due to Ruby object creation overhead. Neither Python nor Ruby are particularly well-known for being fast at object creation, so I can't see Django being much better here. C# (or even F#, in fact) could potentially be viable, for sure. But Ecto stood out to me because of its fantastic query API support for PostgreSQL, which is the database we use.

I've also had Elixir on my mind as a Ruby replacement for a very long time, on the order of several years, as I had more or less anticipated this becoming a problem after the Postgres migration. Discussions I had with Rails core developers years ago in IRC had significant sway in my early opinion of the Phoenix framework, and there was a lot of excitement surrounding the framework (Jose Valim even occasionally showed up in those channels discussing it).

Earlier this year, someone paid me for and I wrote a "scratch project" (a video hosting site) to get used to Elixir and Phoenix, and by late July I felt that I had the experience with the language and framework that I needed to pull this off. I also of course have gained a lot of experience over the past few months as it takes quite a lot to run an modern imageboard.

To be perfectly honest, I did not even consider ASP.NET as a replacement framework. It would certainly work, though. My personal objection is that it's not really "built" for PostgreSQL the way Ecto clearly is. In addition, ASP is what I was doing at my job over the summer, and I was not having a great time picking through what had been left for me, though I admit that was mostly to do with the code being untouched for about ten years.
No reason given
Edited by byte[]
byte[]
Verified Pegasus - Show us your gorgeous wings!
Preenhub - We all know what you were up to this evening~
An Artist Who Rocks - 100+ images under their artist tag
Artist -

Philomena Contributor
"@Angius":/forums/meta/topics/philomena-open-beta-breaking-api-changes?post_id=4630684#post_4630684
[bq]Paradigm, as in from OOP (with some procedural and functional sprinkled in) to a fully functional language.[/bq]Oh, that kind of paradigm. I thought you were talking about MVC vs MVVC etc. It might surprise you then to hear that we were basically writing Ruby in almost functional style anyway. Most of the method calls in our code (the stuff that does "actual work" as opposed to just database interaction) are to "Enumerable":https://ruby-doc.org/core-2.6.5/Enumerable.html and to "ActiveSupport::CoreExt":https://edgeguides.rubyonrails.org/active_support_core_extensions.html. There are vanishingly few class structures we have, and only one or two actually _use_ inheritance or true polymorphism, because it basically isn't needed. (There's also some broken "STI":https://github.com/derpibooru/philomena/blob/54be9dfa5d2e75b7b288a0ff61614d0bbba7c344/priv/repo/structure.sql#L164-L190 that I aim to fix... uh, at some point, but that doesn't really count.)
[bq]Not sure what you mean when it comes to Ecto and being tied down by schema. Not quite sure how it works with Django, but most modern ORMs let you design the schema code-first and use migrations[/bq]"If you read my post on why I decided to do this rewrite":https://www.patreon.com/posts/booru-on-rails-29380128, it sets out my reasoning. Basically the ORM structure provided by ActiveRecord ended up slowing us down considerably after schema changes _where we should have been getting faster_, and I had at that point just had enough of it. The reason for this slowing down was due to Ruby object creation overhead. Neither Python nor Ruby are particularly well-known for being fast at object creation, so I can't see Django being much better here. C# (or even F#, in fact) could potentially be viable, for sure. But Ecto stood out to me because of its fantastic query API support for PostgreSQL, which is the database we use.

I've also had Elixir on my mind as a Ruby replacement for a very long time, on the order of several years, as I had more or less anticipated this becoming a problem after the Postgres migration. Discussions I had with Rails core developers years ago in IRC had significant sway in my early opinion of the Phoenix framework, and there was a lot of excitement surrounding the framework (Jose Valim even occasionally showed up in those channels discussing it).

Earlier this year, someone paid me for and I wrote a "scratch project" (a video hosting site) to get used to Elixir and Phoenix, and by late July I felt that I had the experience with the language and framework that I needed to pull this off. I also of course have gained a lot of experience over the past few months as it takes quite a lot to run an modern imageboard.

To be perfectly honest, I did not even consider ASP.NET as a replacement framework. It would certainly work, though. My personal objection is that it's not really "built" for PostgreSQL the way Ecto clearly is. In addition, ASP is what I was doing at my job over the summer, and I was not having a great time picking through what had been left for me, though I admit that was mostly to do with the code being untouched for about ten years.
No reason given
Edited by byte[]
byte[]
Verified Pegasus - Show us your gorgeous wings!
Preenhub - We all know what you were up to this evening~
An Artist Who Rocks - 100+ images under their artist tag
Artist -

Philomena Contributor
"@Angius":/forums/meta/topics/philomena-open-beta-breaking-api-changes?post_id=4630684#post_4630684
[bq]Paradigm, as in from OOP (with some procedural and functional sprinkled in) to a fully functional language.[/bq]Oh, that kind of paradigm. I thought you were talking about MVC vs MVVC etc. It might surprised you then to hear that we were basically writing Ruby in almost functional style anyway. Most of the method calls in our code are to "Enumerable":https://ruby-doc.org/core-2.6.5/Enumerable.html and to "ActiveSupport::CoreExt":https://edgeguides.rubyonrails.org/active_support_core_extensions.html. There are vanishingly few class structures we have, and only one or two actually _use_ inheritance or true polymorphism, because it basically isn't needed. (There's also some broken "STI":https://github.com/derpibooru/philomena/blob/54be9dfa5d2e75b7b288a0ff61614d0bbba7c344/priv/repo/structure.sql#L164-L190 that I aim to fix... uh, at some point, but that doesn't really count.)
[bq]Not sure what you mean when it comes to Ecto and being tied down by schema. Not quite sure how it works with Django, but most modern ORMs let you design the schema code-first and use migrations[/bq]"If you read my post on why I decided to do this rewrite":https://www.patreon.com/posts/booru-on-rails-29380128, it sets out my reasoning. Basically the ORM structure provided by ActiveRecord ended up slowing us down considerably after schema changes _where we should have been getting faster_, and I had at that point just had enough of it. The reason for this slowing down was due to Ruby object creation overhead. Neither Python nor Ruby are particularly well-known for being fast at object creation, so I can't see Django being much better here. C# (or even F#, in fact) could potentially be viable, for sure. But Ecto stood out to me because of its fantastic query API support for PostgreSQL, which is the database we use.

I've also had Elixir on my mind as a Ruby replacement for a very long time, on the order of several years, as I had more or less anticipated this becoming a problem after the Postgres migration. Discussions I had with Rails core developers years ago in IRC had significant sway in my early opinion of the Phoenix framework, and there was a lot of excitement surrounding the framework (Jose Valim even occasionally showed up in those channels discussing it).

Earlier this year, someone paid me for and I wrote a "scratch project" (a video hosting site) to get used to Elixir and Phoenix, and by late July I felt that I had the experience with the language and framework that I needed to pull this off. I also of course have gained a lot of experience over the past few months as it takes quite a lot to run an modern imageboard.

To be perfectly honest, I did not even consider ASP.NET as a replacement framework. It would certainly work, though. My personal objection is that it's not really "built" for PostgreSQL the way Ecto clearly is. In addition, ASP is what I was doing at my job over the summer, and I was not having a great time picking through what had been left for me, though I admit that was mostly to do with the code being untouched for about ten years.
No reason given
Edited by byte[]