Ask HN: Who wants to collaborate?

Thanks!

+1, to make this work you'd need a standardized schema, and well-defined, relatively stable interfaces. Github, some kind of programming ecosystem (eg: Android libraries or Python Flask server modules), or a cloud system (with the associated problems of vendor lock-in which could be mitigated via federation and open-sourcing the system) seem like the best way to distribute these.

For example, Salesforce has made this work by giving every customer a standard base schema, and then letting developers build modules on top of that: https://appexchange.salesforce.com/

The hard part is designing a core schema that is sufficiently useful and powerful such that people adopt it, while still allowing sufficient per-user customization so that the system can meet specific customer needs. And then when people start using custom extensions to the core schema, ensuring that all the plug-ins and extensions interoperate seamlessly with the huge number of possible combinations.

An interesting project!

Regarding some of the ASN.1 comparison characteristics, I'm not quite sure if I understand--there's a lot to read here, and it's likely I've missed something by a lack of acquaintance with your documents/specifications. But a couple comments:

- Cyclic data: ASN.1 supports recursive data structures.[0]

- Time zones: ASN.1 supports ISO 8601 time types, including specification of local or UTC time.[1] I'm not sure how else you might manage this, but perhaps it's not what you mean?

- Bin + txt: Again, I'm unclear on what you mean here, but ASN.1 has both binary and text-based encodings (X.693 for XML encoding rules[2], X.697 for JSON[3], and an RFC for generic string encoding rules[4]; compilers support input and output).

- Versioned: Also a little unclear to me--it seems like the intent is to capture the version of data sent across the wire relative to the schema used in its creation or else that it ties the encoding to the notation/encoding specification. ASN.1 supports extensibility (the ellipsis marker, ...[5]) and versioning,[6] but AFAIK there's nothing that forces a DER-encoded document to describe whether it's from the first release or the newest. Relative to security, it also supports various canonical encodings.

[0]: https://www.obj-sys.com/asn1tutorial/node19.html and X.680 3.8.61.

[1]: https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en (see X.680 §38 and Annex J.2.11)

[2]: https://www.itu.int/rec/T-REC-X.693/en -- X.694 governs interoperability between XSD and ASN.1 schema.

[3]: https://www.itu.int/rec/T-REC-X.697/en

[4]: https://datatracker.ietf.org/doc/rfc3641/

[5]: See X.680 3.8.41

[6]: See X.680 §3.8.95

When I chose Go for Poly it pretty much came down to Go vs. Rust and the main criteria were.

1. Fast execution 2. Strong devops ecosystem 3. Easy to learn syntax 4. Ships binaries for as many systems as possible.

Julia wasn't really considered because last time I used Julia (which granted was a while ago) there wasn't any support for binary compilation targets and it didn't have a strong devops ecosystem. Also, it's more of a scripting language than something you'd write stable, deployable code in.

Rust beat out Go on speed and tied for shipping binaries but was, way, way harder to learn and Go was still leagues ahead when it came to packages and tooling.

If I remember correctly C is typically 3x faster than Go and 2x faster than Rust. That small decrease in execution time doesn't matter in a majority of use cases but Go is way faster and easier to learn and develop in so it ultimately won.

Hey,

Posting this idea in a niche space. Not too hopeful, but inspired by other posts and trying my luck to see if anyone wants to collaborate. My email is my profile.

The niche here is Indian Classical Music. I would want to use the modern technology to uplift the domain and solve some common problems starting with sharing and distributing of music. Lyrics are usually shared in textual form in one of the languages with no accompanying swaras. As the music and inherently ragas are very structural, there is an opportunity to separate the syntax, representation, rendering, ragas, language, talas etc. and allow to distribute in a consistent way.

I already have the high level design ready. I am looking for some web developer with preferably react experience and more importantly an understanding and interesting in this domain to appreciate what is being done.

Shout out through an email and we shall collaborate!