From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.

I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.

Comments URL: https://news.ycombinator.com/item?id=47157974

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44084317

Points: 3

# Comments: 1

Yes, we hope for the packages.atopile.io to become a place where you can share your designs and explore what other people have built.

Ultimately we do love electronics. This is one of our attempts to contribute back to the field.

To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits:

- you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of changes.

- If someone actually does want to pickup your design and wants to contribute to it, code makes it easier for them because more information is captured in the code, so they get a better sense of what the design requirements are.

To your last point, we don't really see the code becoming the documentation of the implementation of the module. Actually the goal is to do something similar to the IC space or the software space, where the code becomes the implementation of something but the documentation lives somewhere else, perhaps in a datasheet-like document. Currently the schematic forces you to have both the documentation and the implementation baked into the same document, which forces you to find a middle ground between adding information relevant to those two objectives.

The point we would like to move towards is one where atopile enables you to generate high quality documentation about your design in a similar fashion to a datasheet but not entangling the documentation with the source design, which is what a schematic forces you to do. There are some features we'd want to build that could enable that like a visualizer for important parts of a schematic, a fan out view of the consumed interfaces around a chip, the results of a spice simulation...

Counterintuitively, I do agree with your points. We didn't end up designing the ato language because we actively wanted to end up there but rather because we tried everything else before and none of the solutions we tried worked out.

The problem we wanted to solve was: "how does git look like in hardware?". Another way to phrase it is: "How can groups of people coordinate and share their work in hardware?".

The first solution was simply to put KiCAD on GitLab. That solves the version control part of the problem but doesn't solve consistency of design outputs, coordination and reuse problems. The we tried to add automation on top (namely with KiBOT) to generate manufacturing outputs automatically. That was pretty cool for consistency of manufacturing outputs but it didn't solve the coordination and sharing aspect of the problem. And so at that point we kind of had ran out of ideas of things to try. And that's when we started developing the ato language.

Schematics are definitely a great medium to share a design with your peers. But we've found that for those other aspects I mentioned, code is more suited.