Back

Looks like there was a #Babel plugin I missed which is a bit better integrated into the JS toolchain.

https://www.npmjs.com/package/babel-plugin-melody

I do love JavaScript, but I think integrating this into multiple languages would be really powerful given that the problem space is not unique to JS.

@develwithoutacause Rust, Node and Deno are also supported, any other environment/ languages you have in mind? The compiler compiles to WebAssembly so support is pretty flexible

@yoavlavi @develwithoutacause Definitely want to put maturin and pyo3 to work on this and have a python binding. Did something similar with rs_chardet and chardet-ng!

@emattiza @yoavlavi The challenge with competing against #regex is that the concept is so ubiquitous as to have direct support is basically every modern programming language. It's either in the standard library or has a carve out in the language syntax. Getting someone to choose an alternative to that is a big ask.

To be a viable alternative, I think Melody needs to:
1) Be as available as regex in basically every major language and environment: Java, C#, Python, Swift, SQL, PHP, Ruby, etc.
2) Take up enough "developer mindshare" such that people recognize and conceptualize Melody as a viable alternative to regex.

The first is necessary for the second and the second is *really* hard. Melody needs to get to the point where universities, Stack Overflow, and ChatGPT say "You could solve this problem with regex, but you should use Melody because the community generally agrees it's better".

This is as much a marketing problem as a technical problem.

@emattiza @yoavlavi Also given the scope and scale necessary for this project to truly succeed, I think you'd need to write a proper language specification, independent of any single implementation.

This way other developers can contribute their own implementations and tooling for whatever environment they are in. Supporting every programming language is a nigh impossible task for a single team, so you need to be able to shard some of that burden.

Also it helps technically because:
1) It's more teachable to focus on an open spec with multiple implementations, as opposed to one library/tool with a DSL that supports a lot of common environments.
2) It's a selling point over regex, which traditionally has a lot of competing implementations and standards, leading to "quirks modes" like PCRE which fragment the ecosystem.

Anyways, these are just some random product strategy thoughts. Hopefully that's interesting or useful for you!