-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
star
An experimental programming language that's made to be powerful, productive, and predictable (by ALANVF)
-
-
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
-
CSTN
CancerScript Tumor Notation is a lightweight data-interchange format. It is annoying for humans to read and write.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
If you're interested in some of the thinking, check out the Container API in Ecstasy, which is a fundamental part of the design (and not something tacked on later). In a sense, it is the kernel of the design of Ecstasy, and its raison d'être. Related: modules and security.
I tried to distill down the most essential features of TS/JS (functional, prototypal) and then come up with new syntax and semantics that was minimal, orthogonal and hopefully easy to learn and use. The result is kesh and na.
I tried to distill down the most essential features of TS/JS (functional, prototypal) and then come up with new syntax and semantics that was minimal, orthogonal and hopefully easy to learn and use. The result is kesh and na.
The second project was a simple ruby-like syntax for creating text-based games, but I didn't work in it for a while. The plan was to make creating games using my library jQuery Terminal much simpler. The project is called Gaiman.
I also long ago was working on an AikiFramework project that had simple language that could be used with HTML, to quickly create web apps. And I was experimenting with better syntax for its language.
I don't think I'll have time to make one any time soon, unfortunately. My original plan was to write a compiler in TypeScript using Chevrotain, and see if it's possible to compile down to TypeScript's AST and feed that into its own compiler programmatically. Basically piggybacking on Microsoft's hard work (work smart, not hard). I don't know if it's possible, but it's what I'd try first.
I don't think I'll have time to make one any time soon, unfortunately. My original plan was to write a compiler in TypeScript using Chevrotain, and see if it's possible to compile down to TypeScript's AST and feed that into its own compiler programmatically. Basically piggybacking on Microsoft's hard work (work smart, not hard). I don't know if it's possible, but it's what I'd try first.
The other is a dynamic language with the same syntax. Here's a dated link to the first: https://github.com/sal55/langs/tree/master/Mosaic.
I'm working on Star because there are no languages that push the limits of what can be done by mixing OOP and FP ideas , features, and type systems.
Is called https://tablam.org, is based in the relational/array paradigm and provides a more ergonomic experience for building data-oriented applications. (so, for example, it have DECIMAL as the default floating-point type) and improvements to syntax so, hopefully, will be easier for my customers to do some quick scripts.
Regarding rewriting Electron in Rust... you should see the Tauri project ( https://github.com/tauri-apps/tauri ) which does indeed look very promising :)
The second response has to do with packing 10K apps on a machine ... I had a similar goal for the project before https://www.oilshell.org/, which was more of an OS project. This is a longer discussion but I don't think that can be solved with a new language in almost all cases, because of language and workload heterogeneity. But it looks like there are many interesting things going on in Ecstasy and I've been reading more of the blog!
The WASM group benchmarked various varint schemes (https://github.com/WebAssembly/design/issues/601), based on some feedback (https://news.ycombinator.com/item?id=11263378), and stuck with LEB-128 because apparently 90-94% of integers were encoded in 1 byte anyway, in their data sets, which makes the number of branches equal (at 1)
My recommendation is to just write something, even if it sucks. That goes for any concept. You'll learn faster and better by interacting with the machinery yourself versus trying to interpret someone else's abstract understanding of the machinery. In this case, that means choose a simple language or write your own grammar to play with, and make a parser for it. The first real parser I made is a recursive descent parser that parses a relative of JSON. If you're curious, my code is available), but I was a lesser programmer when I wrote it, so don't take it as an example of how you must do things. Regardless, it does work. I've continued to use the character stream code in every text parser I've written since, with some improvements.
Frustration. 2013. I'm doing devops. The "bash or Python" question is annoying because neither is actually a good fit. In a quest to solve my own pain and in hope to help others to suffer less and be more productive specifically when doing "devops"-y things, I have created Next Generation Shell. It's not a better language. It can be better for the intended use cases, just because of the focus on them.
Related posts
-
Show HN: We are trying to (finally) get tail-calls into the WebAssembly standard
-
Achieving nullable ergonomics with a real optional type without special compiler privileges.
-
JSR Is Not Another Package Manager
-
TypeScript Essentials: Distinguishing Types with Branding
-
Smart Contract Programming Languages: sCrypt vs. Solidity