4 ms·

If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older project

If this experiment ends up resulting in a real migration path, I think that would be completely awesome. Maybe it means we have a chance to revive older projects such as ngspice [0], but with modern affordances and better safety properties. From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair? [0] https://ngspice.sourceforge.io/ https://ngspice.sourceforge.io/

bsder 5mo ago
[flagged]
- eqvinox 5mo ago
  +1, a project presenting at FOSDEM certainly does not need a "revive".
  - etimberg 5mo ago
    The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
    - eqvinox 5mo ago
      That's not a revive though, revive (at least to me) implies it's dead.
    - bsder 5mo ago
      > The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance. I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you might stand a chance of producing something that would outperform it. Or, perhaps, if you had particular knowledge of modern high-performance numerical libraries that you could apply to the problem, then you might be able to beat it. However, circuit simulation is remarkably difficult to get right (stiff systems with multiple time constants are not uncommon) and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). If, however, the legacy of ngspice bugs you that much, go look at Xyce and see if that is more to your taste.
      - pkolaczk 5mo ago
        That code was optimized for performance for 1980s hardware. It’s very far from optimized for modern CPUs.
      - nextaccountic 5mo ago
        > and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). Solving sets of differential equations is something that's parallelizable though See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.
        aragilar 5mo ago
        Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable). Mechanics is generally linear, and for game physics engines fast is more valuable than correct (fast inverse square root being the obvious poster child). Add viscosity and you're in for a bad time.
        ycui7 5mo ago
        The type of people who need spice is dead serious about accuracy. 1ppm error sometimes is not tolerable. So, an optimization in a game engine is definitely not suitable for engineering simulation.
        NavinF 5mo ago
        Dude these are incredibly oversimplified models of real components. How are you getting 1ppm when basic shit like tempco and self heating are missing from pretty much every vendor provided spice model?
        ted_dunning 5mo ago
- gobdovan 5mo ago
  As an amateur in the space: I download on Mac, run `ngspice`, "Error: Can't open display: :0". I look in the code - hardcoded X11-era assumptions. Not exactly modern affordances... Then I try to understand and extract the actual formulas, and there isn't a clean formula layer anywhere. All is procedural, e.g. in `b4v6temp.c` formulas are tangled with branching, caching, model-state mutation. Extracting the computation, embedding cleanly and exposing through a sane API feels hair-pulling. So yeah, maintained, but not as in 'modern, embeddable, understandable software component' I'd be looking forward in a rewrite. Maybe not even touch the simulation core, just rewriting Embedding/API layer and the UX would already be a big deal.
  - bsder 5mo ago
    > As an amateur in the space Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. And you are complaining about tangled code but that code is almost certainly hyper-optimized since performance actually mattered a LOT to people running spice simulations. ng-spice (and Spice3 and Spice2) were not written for programming ease; they were written to get a real job worth real money done. In addition, any change you make to that code needs to be run back through numerical regression tests to make sure you didn't break things since this is software that people expect to get correct answers. However, if the legacy seems to bother you so much, perhaps you should look at Xyce from Sandia?
    - dwattttt 5mo ago
      > Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. They sound like an amateur at circuit design, not software engineering (which is how I'd describe myself too).
      - ted_dunning 5mo ago
        KiCad is still the preferred interface. The original point stands. Ngspice shows its heritage from the days of Fortran far more than a modern code base would or should. It's sole great virtue (from my point of view) is that it integrates with KiCad and only falls over with no reason about 5% of the time. I would suspect that some of the simulation systems coming out of the Julia community or Xyce would be a better base.
- skeledrew 5mo ago
  I see "sourceforge" and immediately I think "this project is way behind time and is going to pose a lot of issues to new users, if it's still active".
  - gobdovan 5mo ago
    I could have linked Github repo which has been abandoned for 11 years and ranks higher on Google than the sourceforge page, but that would have maybe been disingenuous. (https://github.com/ngspice/ngspice https://github.com/ngspice/ngspice)
    - LtWorf 5mo ago
      I moved to codeberg and google still insists on linking SOLELY the old archived project on github. While of course snyk and such awful scanners mark them as abandoned because they don't know codeberg exists.
- the__alchemist 5mo ago
  I think this is highlighting the problem the poster you're responding to laments!
deleted 5mo ago
[deleted]
therealpygon 5mo ago
I hear your suggestion without feeling the need to remark the far too common Linux/Deveoper response of “but if you just do all this other stuff and run it this special way and install 15 dependencies and compile XYZ lib from source then clearly it works fine and you’re mistaken”. That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modernization efforts or forks don’t exist. That said, I suspect this rewrite went so quickly and so optimally because it had the benefit of (effectively) 100% test coverage already in place in a really well defined system. Most open source project spawn from efforts of a single developer who frequently never waste time writing tests for a little side project. Later as it grows, they rarely stop and go back to implement testing. So if you’re truly working with an old dead project, there is a really good chance there are zero tests to be found. That is far more difficult to reach the same completeness unless the goal is simply to port all of those same problems to a new language and hope type safety fixes them. (Not specific to ngspice, just mean generally.)
- eternal_braid 5mo ago
  You can instruct an LLM to improve the test coverage.
  - pryelluw 5mo ago
    You are absolutely correct!
tracker1 5mo ago
I've found Rust to be pretty enjoyable to work with in terms of Agent assisted development. Easier still if you have something you're trying to port or recreate in Rust for various reasons. There are definitely some rougher edges around a few things as you get more general purpose in terms of app targets. Some of the DB engines can use some work or may be missing interfaces you use in other supported languages/platforms... There's a somewhat limited set of UI options, and no clear winner. Lifetimes can get pretty hard in very complex code bases... even if other aspects of burrow checking may be more common, this is where I've had and seen the biggest gaps in understanding in practice. That said, you can usually do inefficient things to work around these issues with the opportunity to come back later. Often inefficient Rust with lots of clone operations is still faster, smaller, lighter than the same services in Java or C# as an example.

bsder 5mo ago

[flagged]

eqvinox 5mo ago
+1, a project presenting at FOSDEM certainly does not need a "revive".
- etimberg 5mo ago
  The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
  - eqvinox 5mo ago
    That's not a revive though, revive (at least to me) implies it's dead.
  - bsder 5mo ago
    > The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable That code is also hyper-optimized for performance. I sincerely doubt you are going to match the performance easily with any random rewrite. Now, if you had a very clear idea of why the code was making assumptions from the 1990s that are no longer valid, then you might stand a chance of producing something that would outperform it. Or, perhaps, if you had particular knowledge of modern high-performance numerical libraries that you could apply to the problem, then you might be able to beat it. However, circuit simulation is remarkably difficult to get right (stiff systems with multiple time constants are not uncommon) and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). If, however, the legacy of ngspice bugs you that much, go look at Xyce and see if that is more to your taste.
    - pkolaczk 5mo ago
      That code was optimized for performance for 1980s hardware. It’s very far from optimized for modern CPUs.
    - nextaccountic 5mo ago
      > and generally resistant to parallelization (each device can have its own model which are a unique set of linear differential equations). Solving sets of differential equations is something that's parallelizable though See for example how there's physics engines running on GPU. That's mechanics and not electric circuits, however it's differential equations all the same.
      - aragilar 5mo ago
        Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable). Mechanics is generally linear, and for game physics engines fast is more valuable than correct (fast inverse square root being the obvious poster child). Add viscosity and you're in for a bad time.
        ycui7 5mo ago
        The type of people who need spice is dead serious about accuracy. 1ppm error sometimes is not tolerable. So, an optimization in a game engine is definitely not suitable for engineering simulation.
        NavinF 5mo ago
        Dude these are incredibly oversimplified models of real components. How are you getting 1ppm when basic shit like tempco and self heating are missing from pretty much every vendor provided spice model?
        ted_dunning 5mo ago
gobdovan 5mo ago
As an amateur in the space: I download on Mac, run `ngspice`, "Error: Can't open display: :0". I look in the code - hardcoded X11-era assumptions. Not exactly modern affordances... Then I try to understand and extract the actual formulas, and there isn't a clean formula layer anywhere. All is procedural, e.g. in `b4v6temp.c` formulas are tangled with branching, caching, model-state mutation. Extracting the computation, embedding cleanly and exposing through a sane API feels hair-pulling. So yeah, maintained, but not as in 'modern, embeddable, understandable software component' I'd be looking forward in a rewrite. Maybe not even touch the simulation core, just rewriting Embedding/API layer and the UX would already be a big deal.
- bsder 5mo ago
  > As an amateur in the space Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. And you are complaining about tangled code but that code is almost certainly hyper-optimized since performance actually mattered a LOT to people running spice simulations. ng-spice (and Spice3 and Spice2) were not written for programming ease; they were written to get a real job worth real money done. In addition, any change you make to that code needs to be run back through numerical regression tests to make sure you didn't break things since this is software that people expect to get correct answers. However, if the legacy seems to bother you so much, perhaps you should look at Xyce from Sandia?
  - dwattttt 5mo ago
    > Why are you not using this through KiCad? That's what I would expect an amateur to do; especially since they handle the UX that you are complaining about. They sound like an amateur at circuit design, not software engineering (which is how I'd describe myself too).
    - ted_dunning 5mo ago
      KiCad is still the preferred interface. The original point stands. Ngspice shows its heritage from the days of Fortran far more than a modern code base would or should. It's sole great virtue (from my point of view) is that it integrates with KiCad and only falls over with no reason about 5% of the time. I would suspect that some of the simulation systems coming out of the Julia community or Xyce would be a better base.
skeledrew 5mo ago
I see "sourceforge" and immediately I think "this project is way behind time and is going to pose a lot of issues to new users, if it's still active".
- gobdovan 5mo ago
  I could have linked Github repo which has been abandoned for 11 years and ranks higher on Google than the sourceforge page, but that would have maybe been disingenuous. (https://github.com/ngspice/ngspice https://github.com/ngspice/ngspice)
  - LtWorf 5mo ago
    I moved to codeberg and google still insists on linking SOLELY the old archived project on github. While of course snyk and such awful scanners mark them as abandoned because they don't know codeberg exists.
the__alchemist 5mo ago
I think this is highlighting the problem the poster you're responding to laments!

deleted 5mo ago

[deleted]

therealpygon 5mo ago

I hear your suggestion without feeling the need to remark the far too common Linux/Deveoper response of “but if you just do all this other stuff and run it this special way and install 15 dependencies and compile XYZ lib from source then clearly it works fine and you’re mistaken”. That’s exactly the type of thing that is needed is to optimize projects for modern compatibility, portability and safety when other modernization efforts or forks don’t exist. That said, I suspect this rewrite went so quickly and so optimally because it had the benefit of (effectively) 100% test coverage already in place in a really well defined system. Most open source project spawn from efforts of a single developer who frequently never waste time writing tests for a little side project. Later as it grows, they rarely stop and go back to implement testing. So if you’re truly working with an old dead project, there is a really good chance there are zero tests to be found. That is far more difficult to reach the same completeness unless the goal is simply to port all of those same problems to a new language and hope type safety fixes them. (Not specific to ngspice, just mean generally.)

eternal_braid 5mo ago
You can instruct an LLM to improve the test coverage.
- pryelluw 5mo ago
  You are absolutely correct!

tracker1 5mo ago

I've found Rust to be pretty enjoyable to work with in terms of Agent assisted development. Easier still if you have something you're trying to port or recreate in Rust for various reasons. There are definitely some rougher edges around a few things as you get more general purpose in terms of app targets. Some of the DB engines can use some work or may be missing interfaces you use in other supported languages/platforms... There's a somewhat limited set of UI options, and no clear winner. Lifetimes can get pretty hard in very complex code bases... even if other aspects of burrow checking may be more common, this is where I've had and seen the biggest gaps in understanding in practice. That said, you can usually do inefficient things to work around these issues with the opportunity to come back later. Often inefficient Rust with lots of clone operations is still faster, smaller, lighter than the same services in Java or C# as an example.