Of course, there are only a finite number of possible names, especially when you limit yourself to names that are brief and meaningful, which makes name collisions almost inevitable. And maybe the above items are all obscure enough that it doesn't matter (I had heard of the first before, due to my past life as a PHP developer, but the other two I only found by searching)
This is a great product and Stripe seems to be a good actor...but to me this looks like an acquihire with an eventual "our incredible journey" post in the future. Or frozen development while the team moves on to other Stripe projects.
Agree. But I think they made the right call. Monetising Tonic seems quite difficult, and this will give them time to not worry about fund-raising, burn rates, etc. and continue building their product for a while at least.
After their two years at Stripe are up, they can go back to working on it if it still makes sense.
This might not be the feedback you were hoping for, but the new name is similar to a very juvenile word in Swedish (and possibly/probably in Norwegian and other Scandinavian languages). I guess it's too late, but I would probably recommend changing it if possible.
Edit: Not sure why this is getting downvoted. I'm only pointing this out to help.
Ah, first I thought this was about TonicDev, didn't recognize Tonic and part of Stripe didn't make sense. Then it turned out to be what I thought anyways. Good to hear news from you, I think the idea is amazing and it's easy to write explanations with RunKit.
I have two questions for you.
1) Offline mode, please! I've opened the feedback on uservoice at October 27, 2015 (https://tonicdev.uservoice.com/forums/273722-general/suggest...), there should be some self-hosted version for us to use. Which kind of leads me to what I think is blocking the offline mode
2) module-fs < is this planned to open source at one point? Sounds like a interesting solution, what I've done before is to hook up require to be async and then download the packages when they are being used, but not very friendly
Offline mode is an interesting problem. For example, module-fs is 1 part code, 99 parts infrastructure really. We have 3.5TB of installed packages, stored internally in a content-addressable way, and then exposed as a file system through FUSE. module-fs seems to be something that only becomes powerful when you have ALL packages, thus really having similar performance characteristics of having already installed the packages. The solutions I've seen that try to download packages in the background, etc. don't quite provide this magical "I only need to require it" feeling. Its similar to the issue we have with providing real time-traveling locally: in my experience "time-traveling" has never taken off because its eternally stuck in demo-mode, as all code eventually interacts with the outside world. By snapshotting the entire computer, I think we've pushed this feature over the edge to the point that people use it without realizing it on RunKit, it is of course natural that going back in a REPL also goes back to a previous state. But locally, this feature once again doesn't seem to immediately make sense. At that point the question becomes what part of RunKit would we offer locally? Just the object viewers? I ask this non-rhetorically btw, I am happy to hear what you imagine a "local" RunKit to look like, and if it makes sense we'd certainly consider pursuing it.
Do you plan on branching out to other languages with Notebook (Ruby!)? Also any plans to open-source any of your stack? In particular, I would love to have an on-prem version, then I could reach internal resource and store sensitive data.
hook.io supports something similar to TonicDev ( albeit with no reverse or rewind ), but with a lot more features and 13+ programming languages. It's also open-source.
Here is a simple multi-language scratch pad that can be saved to a URL endpoint: https://hook.io/editor
Tonic is seriously cool and the long-term vision would be amazing for Node development however...
> Stripe decided to take a bet on our vision and our team
I feel confident to make a prediction that Tonic will eventually ride off into the sunset.
After seeing what happened to Parse, I sadly feel this is going to end the same way. If a company as large as Facebook could not keep Parse going, how will Stripe manage.
This is a good acquihire for Stripe, and a new opportunity for someone else to make a web repl.
First time I've heard of RunKit. I've used Jupyter in the past to do a similar thing (minus the API stuff which is very cool). What does RunKit provide that Jupyter doesn't?
You might have not heard of us because we used to be named Tonic ;) There are a number of different factors that differentiate us from Jupyter, but we have of course taken a ton of inspiration from them. The data science crowd including iPython, Mathematica, etc have pioneered a development style that I hope see make its way into "normal" programming. One of the best resources is a pretty in-depth blog post we wrote about what's going on under the hood here: http://blog.runkit.com/2015/09/10/time-traveling-in-node.js-...
But, to give a quick overview:
1. One of the original driving goals when we started working on RunKit was to completely eliminate friction in using other people's code. So what we did was install every permutation of every version of every package for node. You can even require two versions at once and compare them: https://runkit.com/tolmasky/api-diff-example . This has lead to many interesting uses that aren't possible with other notebooks. For example, many people use us for filing bugs, because its kind of the dream: you're not filing a bug, you're filing a computer and environment with an undeniable reproduction, that the reviewer can easily test (what happens if I change node version? what happens if I change module version, etc etc).
2. As listed in the blog post above, we've spent a tremendous amount of time on the problem of determinism, in an attempt to "unify" the REPL and file environments. Basically, RunKit notebooks read top to bottom, just like a file, and we guarantee that if you take the contents of a notebooks and run it in normal node, it should behave exactly the same. For example, no asynchronous events should be first in-between consecutive cells - this is really important in asynchronous programming. To be able to deliver on this guarantee we invested heavily on "time traveling" -- when you edit a cell in the past, the ENTIRE virtual machine is rewound, files you had deleted are restored, etc (again, more info in the blog post if you find this interesting).
Happy to answer any other questions, apologies for the rambling, haven't gotten much sleep!
If someone wants to see a runnable demo, I've created one about one year ago, that maps the bicycle stations of Barcelona https://runkit.com/victorb/bicing
I can't begin to tell how wonderful is the thing you've come up with. However, I would really like to be able to
a) host it on my own server as an open source app
b) pay for it
I think it's in the human nature to ignore the users who doesn't explicitly pay you and I'd be rather protected by an off-the-cloud version or being able to say "you have a responsibility towards your customers" if and when the time comes for a post titled "so long and thanks for all the fish".
edit: Or... Well... You know, if and when the site is down. It's not just me, right?
* a PHP module - http://php.net/manual/en/book.runkit.php
* a Swift wrapper for Grand Central Dispatch - https://cocoapods.org/pods/RunKit
* an Objective-J animation library - https://github.com/austinsarner/RunKit
Of course, there are only a finite number of possible names, especially when you limit yourself to names that are brief and meaningful, which makes name collisions almost inevitable. And maybe the above items are all obscure enough that it doesn't matter (I had heard of the first before, due to my past life as a PHP developer, but the other two I only found by searching)