Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

* Shell script replacement language that will also be useful as a production language.

* Build system that people will actually love. (I hope.)

* Init system that is easier to use than systemd, while also building distributed systems.

* All-in-one VCS, like Fossil, but it can track changes to binary files.



I think you should definitely get some feedback on the details and specifics of the language before going further if you want it to make it to real production use.

Will you have a GitHub equivalent? Git is dominant I think because it's the standard all the tools are built for, no matter how good a competing system is, I'd probably choose on ecosystem. What's the use case list for binary file tracking? That seems pretty interesting!


Yeah, I need feedback on the language. But to do so, people kinda want to be able to try it. I'm still getting it into a demo-ready state.

Since my VCS will be all-in-one, yes, it will have a GitHub equivalent. In fact, it will be more of a Gitea equivalent because anyone could spin one up.

But I'm not worried about beating git (yet) because the use case for binary tracking is assets for movies and games, and movies and games generally use Perforce. Once my VCS has replaced Perforce, I'll think about conquering git.


Do you have a random bullet points lost or example code for what the language should look like?

Taking on perforce seems more reasonable than git at first for sure.


Old version of the example file is at https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/exa... .

It's old because I had to stop pushing new commits to that repo until I got my new license approved by a lawyer. I have almost 700 commits since then, several of which update the example file.

But the gist of the language is still the same.


My initial thoughts(I'm not a "language guy" so I don't pay much attention to languages outside the billion dollar ones).

* Is it gonna stay AGPL? Will people use it? * I like the integration with shell. Largely because I hate actually coding in shell and this could be a cool replacement. * Overall it looks pretty cool. I'd probably enjoy coding in it more than C * it seems to have a handwritten lexer and parser? * The mutator operator is cool * I'm not the biggest fan of englishlike "push x onto y" * I like the context stacks, I don't quite like having special builtin one with no distinguishing feature or namespace in the name * Function suffixes are neat but a bit too odd for me But I don't think I'd want to use anything "Indie" in production anywhere, and AGPL might scare off people so it never becomes a mainstream corporate backed thing, right?

Seems like you'd have to really carefully make sure it fits the audience who enjoys using indie stuff if you don't plan to get corporate backing. AI free seems like a good thing for that!


Those are really good thoughts! Here are a few answers and thoughts.

* No, it won't stay AGPL. It will be just my license once a lawyer approves that license. And I have actually four licenses; it will start on the most restrictive, but I will move it to the most permissive over time as this repo becomes established and recognized. In essence, I will explicitly follow the process in [1] that tends to happen over time.

* Yay!

* Double yay! Thank you!

* Yes. This is necessary to implement DSL's in it. (My build system will use a DSL.) Also, it will have better error messages.

* Great! This is one thing that Rust is right on: mutation should not be default.

* I'm not the biggest fan of it either; that syntax will change to something better. Maybe just `push <expr>: <stack>`. I don't know. Any suggestions?

* Technically, they are not built-in; they are a part of the standard library, but point taken: there needs to be a better namespace for those standard library ones. (By the way, this means that yes, your own libraries can add context stacks for client code.)

* Function suffixes are weird, yes. I don't know what to do about that. I've waffled a bit between them and having implicit name mangling (as in C++), but that leads to ABI and interoperability issues. But I acknowledge the issue. What can I say? Language design is hard!

And to answer, your claim that you're not a language guy, you are. As a user, you are more right than me as to what is good; actual users matter more than the language designer. If you are a user, you know what's good for you, and it is my job to hit that.

Someone somewhere said that new projects can only spend a few points on "novel" things; maybe I'll have to spend one on function suffixes, or maybe it would be better to spend them somewhere else.

> But I don't think I'd want to use anything "Indie" in production anywhere, and AGPL might scare off people so it never becomes a mainstream corporate backed thing, right?

Well, I am running a business behind it, an actual real business, so it may not be corporate-backed, but it's as close as I can make it. Because I don't want a corporation controlling it.

> Seems like you'd have to really carefully make sure it fits the audience who enjoys using indie stuff if you don't plan to get corporate backing. AI free seems like a good thing for that!

Thank you! That is actually part of my plan (though I do hate LLM's).

Here's my plan: you have people at companies that write shell scripts for small tasks, right? Over time a few of those scripts get passed around, tweaked, and turned into pseudo-blessed company-wide tools.

Well, maybe one of those programmers writes Yao scripts because Yao is just better than shell. If one or more of those scripts becomes a pseudo-blessed tool, then the company now depends on Yao, and they would be wise to pay me a few grand a year for support.

IOW, you nailed my plan: target the indie audience and use it to snare the corporate one. :) You figured all of that out from the language design! You're sharp!

Thank you for the comments!

[1]: https://writing.kemitchell.com/2020/03/07/No-Posse.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: