Storyscript is a language to express how data moves between microservices, functions, and everything else in the middle while generating architecture.
Let's discover the top questions the developer community asks about Storyscript to shed light on our decision to design and develop a new programming language from scratch.
Top 3 questions from the developer community.
- "Developers are resistant to learning new languages, right?"
- "Is this replacing other languages?"
Let's break these down.
Developers resist new languages.
A programming language is a vocabulary and set of grammatical rules for instructing a computer or computing device to perform specific tasks.
Configuration is language. Kubernetes and Docker are languages. They have vocabulary, grammatical rules, and perform specific tasks. These technologies have been widely adopted in the market and enterprise.
Frameworks are languages. Angular, React, VueJS, Rails, Django are languages. They have vocabulary, grammatical rules, and perform specific tasks. Developers stay cutting edge and adopt new languages to build the same thing more efficiently.
There have been over 25 languages created (excluding framework and configuration languages) in the last 8 years including Swift, Rust, Kotlin, Julia, and TypeScript; many of which appear in the "top 10 languages to learn in 2019" articles.
The developer is eager to learn new languages that amplify their ability to create and deploy software more efficiently. Developers love to learn.
Just fork it.
- Unlearning is harder than learning something new.
- Inheriting the dev-tools and their accrued technical debt would be awful.
- Hack your own features into the compiler/runtime... No, thanks.
- "Hey Support, StackOverflow says I can just import this package".
- You still have to install all the forked dev-tools.
- Our library is different.
- Our runtime is different.
- Our goals are different.
Replacing other languages.
Let's be clear. Storyscript does not replace other languages. It amplifies them.
Storyscript strings together microservices and serverless functions; dynamically producing architecture in Kubernetes. Some call it glue-code, some low-code, we call it Storyscript.
We believe Storyscript is the missing language of microservices and high-level business logic.
Create your own microservices in any programming language by following the Open Microservice Guide, then call upon your service in just one line of code.
# this is your service written in any language handlers = serviceA action foo:'bar' key:value # >>> handlers = 'eric,andy,joe' # now we can mutate the output of your microservice names = handlers split by:',' then sort then apply method:String.capitalize # >>> names = ['Andy', 'Eric', 'Joe'] # call upon a microservice found in the Asyncy Hub serviceB search terms:names
That's not all. Microservices are highly-reusable, domain-specific, and are responsible for their own metrics, logs and more. With just one line of code to call the service, you will get all the metrics, scaling and insights out of the box as your service is entirely managed by the Asyncy Platform.
Languages have feelings.
One could argue that Python and Ruby, in many ways, do the same thing yet they feel different from one another. The communities behind these languages share different values and have strong pride in their language.
"Ruby is sexy".
"Python is clean".
"Ruby is beautiful".
"Python is zen."
We intentionally designed Storyscript to have a certain feeling when programming with it; a feeling that other languages did not capture. When you explain an application or feature to your friend you don't "show them the code", instead you use spoken language to abstract the goals from the code; the story of your code. Storyscript has a native, natural feel to it. The way you read, write and share Storyscript is nearly the same as the story of your code.
Storyscript is MIT licensed. Contributions are welcomed with love ❤️ on GitHub.
Learn more about Storyscript in our documentation 🚀