Algunas reflexiones.
Si la premisa de tu pregunta es si puedes pasar de ser un desarrollador de Python a desarrollar cosas para Discourse, entonces la respuesta es un poco más matizada.
Como has descubierto, el paso de Python a Ruby es relativamente trivial. Puedes hacer que Ruby haga lo que puedes hacer en Python simplemente aprendiendo las diferencias semánticas.
Sin embargo, como tuve que dar el mismo salto hace unos años, si simplemente intentas hacer con Ruby lo que puedes hacer con Python, te perderás algunas de las cosas que hacen que Ruby sea “Ruby”.
En segundo lugar, ese matiz de Discourse.
Si bien el backend está basado en Ruby, una gran parte de la “complejidad” de crear cosas para Discourse radica en desarrollar tanto el backend (Ruby) como el cliente (JavaScript/Ember) para que funcionen en armonía.
Incluso con una comprensión profunda de cómo usar Ruby, también necesitas invertir tiempo en comprender cómo funciona el backend de Discourse. Existe un excelente ecosistema que el backend proporciona a los plugins, como acceso a datos / estructuras de datos, registro, mensajería entre procesos, trabajos asíncronos, etc. Encontré que obtener una buena comprensión de esto era importante.
Me resultó muy gratificante echar un vistazo a Ruby, pero encontré que las cosas del frontend, JavaScript, eran demasiado desafiantes para mis necesidades. Soy un programador aficionado con algunos años de experiencia, así que lo atribuiría a eso y a la falta de una mente ágil.
Dicho esto, he podido entender otros frameworks de JavaScript, como Svelte, por ejemplo. Los detalles específicos de Ember y el flujo de instanciación rígido / la coordinación y las estructuras de carpetas fueron un poco complejos para mí y mis necesidades.
Mi solución fue usar el excelente Custom Wizard Plugin para capturar la interacción del frontend y luego pasarla a mi código Ruby del backend. Esto funciona bien con procesos por lotes, pero es menos útil en entornos interactivos.
Buena suerte.