Cool point it is not about comparing run-kit with ipython and they are different things. Ipython is about python and mine is about different languages. And btw I am adding variables between different languages
TBH, my plan was not to replace any of the previous ones, and the name polygot is from my idea of many languages in with a single command, and as simple as run 'code' or run lang code
TBH my plan was not to replace any of the previous ones and the name polygot is from my idea of many languages in with a single command and simple as run 'code' or run lang code
You're right—Kotlin can be used as Kotlin/JS for web development, and as a compiled language when we're talking about Android development.
Context matters
You're right—and the same applies to Kotlin. Swift is more like Rust, C, and C++ in that it compiles directly to machine code. So yes, Swift is currently listed under the wrong category.
As for Kotlin, it could reasonably be placed under either "Web & scripting" or "Compiled," depending on how it's used. Since Kotlin can also compile to JavaScript, its classification depends on the context. If we're talking about Android development, then Kotlin is clearly a compiled systems language.
To clarify: Swift is a compiled, statically typed systems language, much like Rust, C++, or Go. Its core toolchain (swiftc) compiles code into native binaries.
This is a quirky response. Kotlin might be able to compile to JS the same way C++ can compile to WASM but I don't think that's it's primary purpose. Either put them in their idiomatic category or don't bother categorizing at all.
Yes, that's exactly the point. What I'm trying to do is:
1. Use Rust because it's fast.
2. Make REPLs universal, so we don't need separate REPLs for different languages.
3. And third—though not a new idea—is to create better abstractions, like allowing print statements without requiring a main function, and accessing variables without explicitly printing them.
That makes a lot of sense to me! I imagine that a lot of the logic you'll define will be fairly independent of the language itself, so you won't need to do quite as much work as if each one were implemented separately.
How do you download and manage the various language toolchains though? At least in my experience, the ease of doing this varies quite a bit by language and OS. Some distros have better package managers than others, and some of them don't have first-party ones at all. If I want to install Python on MacOS and haven't been using it enough to know which of the half dozen or so tools that are recommended by various people for it (or might have a sense of what to use but lack interest in learning the specifics of yet another tool for a language I need to do something fairly basic in), having a single tool that I'm already using for a bunch of other languages that I can also use for Python might be pretty nice.
The idea is similar to IPython, which provides an interactive interface for programming languages. The motivation isn't about building a massive CLI tool—it's about questioning why we need a separate REPL for each language when we could use a single command-line interface that lets us switch between languages on the fly.
