3 ms·

I think at one point you said you’re working on a rust rewrite? Is that still in the cards?

by lifty 21d ago

sillywalk 21d ago
https://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/ Fish 4.0: The Fish of Theseus (fishshell.com) 906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments https://news.ycombinator.com/item?id=42535217 https://news.ycombinator.com/item?id=42535217
mikemcquaid 21d ago
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches). The lessons learned were instead used to make the Ruby frontend much faster.
- clumsysmurf 21d ago
  I don't know anything about homebrew, but have a question ... I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance. There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete. I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy. I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
  - robertlagrant 21d ago
    > I suspect that the number of people that use and know Groovy is steadily declining One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
  - hn8726 21d ago
    Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need
  - mikemcquaid 21d ago
    Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language. That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API. This will likely get extended over time to eventually allow package definitions to themselves be in JSON.
reaperhulk 21d ago
They experimented with it but ultimately decided to focus on perf with their existing ruby codebase. https://github.com/Homebrew/brew/issues/7755#issuecomment-5145260312 https://github.com/Homebrew/brew/issues/7755#issuecomment-51...

I think at one point you said you’re working on a rust rewrite? Is that still in the cards?

by lifty 21d ago

I think at one point you said you’re working on a rust rewrite? Is that still in the cards?

https://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/ Fish 4.0: The Fish of Theseus (fishshell.com) 906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments https://news.ycombinator.com/item?id=42535217 https://news.ycombinator.com/item?id=42535217

mikemcquaid 21d ago

I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches). The lessons learned were instead used to make the Ruby frontend much faster.

clumsysmurf 21d ago
I don't know anything about homebrew, but have a question ... I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance. There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete. I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy. I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
- robertlagrant 21d ago
  > I suspect that the number of people that use and know Groovy is steadily declining One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
- hn8726 21d ago
  Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need
- mikemcquaid 21d ago
  Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language. That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API. This will likely get extended over time to eventually allow package definitions to themselves be in JSON.

reaperhulk 21d ago

They experimented with it but ultimately decided to focus on perf with their existing ruby codebase. https://github.com/Homebrew/brew/issues/7755#issuecomment-5145260312 https://github.com/Homebrew/brew/issues/7755#issuecomment-51...