"Freemium language" is not an option. The language is, and will be free and open source. I cannot even imagine any other option, particularly after open sourcing the codebase. Premium tools and services is the way to go for us and we don't feel that would be detrimental for Luna. It ranges all the way from simple consulting services to running a Luna based cloud environment, but there is no threat for Luna as a language in that. On the contrary, this kind of support usually helps boost the technology.
Hey, thank you! :) You can run computations on streaming data sources, and building computations on some local files and then running it as a part of a bigger, network connected pipeline is a very common workflow. As for connectors for specific services like Postgres or Cassandra, there aren't any libraries yet. All there is is bare networking, ready to be used for these. If you'd like to make that happen please let us know over the chat or at our forum, we'd love to assist you!
Thank you for the feedback! To answer your concerns:
1. Studio is actually a set of plugins for Atom, not a fork. It's just that we are shipping an Atom binary and make sure that it can work alongside a standard Atom installation, for a smoother experience. We understand how many people use Atom for their daily work and we'd rather not mess with that.
2. That's a perfectly valid point! We'll prepare a CLI distribution, but for the first release we wanted to make sure that Studio works well (the visuality is one of the strongest points we're trying to make after all). For now there's an option to build a command line client from sources, but a bundled version is coming soon :)
Hey! There isn't any out-of-the-box support for distributing Luna programs over the network or any library for that yet. We'll get there eventually, but this is too early a release. As for integrating with Hadoop and others: the networking libraries are already there, so there is always a way to integrate. There aren't any adapters yet, so creating one is as hard as wrapping the necessary network calls. If you'd be interested to get deeper into that, I'll be happy to assist you. Just let me know over our chat or forum and we'll make that happen :)
We don't have a webserver library yet, but a simple one is coming soon (probably this or next week). As for package management – well, we figured it's to good have some packages to manage first and not to rush into that. It is also a nice effort for the community, if there would be anyone interested in contributing such a system (thus earning eternal fame ;))
Hey! For now the best way to interact with Postgres is, I think, using an HTTP wrapper server. A better way to do this needs to be created. Maybe as a community effort? ;)
Some things look best in text and it's fine. However, "programming" is a very broad category, and definitely does not boil down only to algorithms and data structures. I'd even say that most programming tasks in the world right now are much less about complex algorithms and much more about everyday systems plumbing. Sure, at some point you'll need to fire a complicated linear algebra kind of algorithm, but before you get there, you need to get the data out from some source, do some reformatting, decide which algorithms to run and when and then send the results somewhere else. And for that, seeing what is happening with your data the moment you try a solution, and deciding the next step based on immediate feedback is great.
This is pretty much why we've gone with interchangeable representations instead of going "visual only". The choice of the proper tools / representations highly depends on the context, and we want to leave that for the programmer's decision.
Why don't we have both? And then some more.
It is an awesome REPL with a bit of Excel feel. Runs the code whenever you change it and displays the results in real-time. It is also great for interactive data sources (like web services), where you get the results as soon as they appear upstream.
The whiteboard part is super important too. Visual representation is great for design and brainstorming. Even more so, when it provides runtime feedback about your designs. And it gets even more important with collaboration. So at this point we've got a collaborative whiteboard that actually runs the computations.
There is, however, one more part to the story. Neither whiteboard, nor a REPL are well suited for implementing the final, production software. We aim to blur the lines between the design and implementation phases, allowing to deploy whatever has just been "sketched".
For starters we've made sure to make git diffs as readable as possible. The visual data is kept at the end of text file (hidden when using our editor), usually in a single line. So if you just move nodes around, one line gets changed and it is clear what to ignore when scanning the diff, while making sure to retain the changes in the repository.
For later stages, we envision much deeper integrated version control, including viewing git diffs in the visual editor.
The standard library is 3-ish kLOCs (written entirely in Luna) and growing, the biggest use cases we've created so far were around 500 LOCs. Performance-wise, we are letting the GHC compiler infrastructure do most of the heavy lifting. As for the more complex applications, it may be tricky to create a compiler or a web browser in Luna in its current state, but we are constantly working on on improving the performance, with the goal to match Haskell's. Web applications (particularly microservices) are among our main focuses now, so that's entirely within our reach.
I wouldn’t say it’s bogus, and there definitely wasn’t any malicious intention behind it, it’s just that finding a name for such a property is super difficult. As I’ve written above, it’s about having fine-grained control over the data (object) constructors. It turns out most words synonymous to “type”, “kind”, “category” etc. (as understood in the wide sense) are already taken by mathematical / programming concepts. We will, however, change the name, as it causes way too much confusion :).
This feature is a bit of a misnomer, as it immediately brings up discussions about category theory. That being said, the idea behind it is pretty simple, yet powerful. Our typechecker will be able to track the shape of data on a deeper level than usual types. Basically will be tracking the exact constructors used to construct data, not just types – something that is a huge pain in most existing typed languages. If you for example take Haskell, you can have a data type with multiple different constructors, and even though you may be certain that some of those are impossible to occur at some points in your program, it is difficult to express that certainty on typelevel – other than repacking to a different datatype, with less constructors, which then need to be named differently and need repacking even if you're just calling a function that expects a wider range of constructors, and thus is definitely safe.
However, due to the amount of work with more foundational layers of the language, we've had to postpone implementing this feature until further down the line. It is coming at some point for sure, though :)
We needed to design everything from scratch to make sure the two representations are truly interchangeable. Every design decision in the textual language needs to be backed by its visual counterpart, and we found this way of thinking impossible with any other existing language.
Then there is the problem of complexity of existing, typed, functional language. We aim to make things as simple as possible, while not sacrificing the power of types, in order to make the language accessible for a much broader audience.
I'm super happy to hear that you like it, make sure to sign-up for our newsletter, so we can stay in touch once Luna is out :).
We store them in a separate section in the source file, which is hidden by default when editing. So a bare .luna file is a readable text file, containing some metadata at the bottom, which is not shown when editing with our editor. This way we achieve clear representation and full portability of the source files.