Announcing algorithm development support for Python 3, JavaScript, Rust, and Ruby
blog.algorithmia.com
blog.algorithmia.com
I might pay to use a service that allowed an implementation not in my projects language (and it's faster, I can't be bothered to write it, etc), but close sourcing or licensing of algorithms seems to go against the entire ethos of the community.
Especially in the wake of Oracle v Google and the implications that it could have on APIs, I really think to purposefully close off algorithms is just another step in a really bad direction.
[1]: https://www.reddit.com/r/ruby/comments/4k4fpr/algorithmia_no...
As a firm believer that knowledge -- particularly theory -- should be free, Algorithmia is repulsive. As a developer their black-box model (and not simply giving me source) is a no-go.
That said, over 75% of algorithms on the site are open source. Perhaps that's not obvious enough?
[disclaimer: I'm an engineer at Algorithmia]
Would anyone who upvoted this mind explaining the significance of Algorithmia in general? The marketing itself seems to misuse the idea of an algorithm.
I remember the last time they popped up on HN someone pointed out how the licenses Algorithmia uses are one-sided. Has this situation improved at all, so developers aren't at a legal disadvantage?
The idea behind algorithmia is to expose algorithms, functions and ML models through an API so that they can be adapted from any language you as the developer feel comfortable in. Today we added a number of different languages our platform supports - expanding the number of developers that can contribute to our platform. The larger the library the more you can do with it.
Regarding the licenses. We support 4 types of licenses currently 3 FOSS and 1 Algorithmia Platform. The Algorithmia Platform takes no rights other than giving us permission to run your code on our platform and provide it as a service. At no point do we take ANY ownership of your IP. The only thing that can be seen as a restriction is that once you put an algorithm in our platform that version will always be there - this is just to guarantee to anybody building on top of our API that the code will always be there for them.
Regarding upvotes - HN has serious voting ring detection behind it and this climbed the ranks naturally since posted this morning. We are avid participants in this community with no intention of manipulating what is of interest.
That being said, I agree with thee other posters here. If I could downvote article submissions I would downvote this one.
OP, the world doesn't need this. Please stop. Thanks!
I'd just softly suggest to make sure that the problem you're solving doesn't get lost in the marketing. Often I'll visit the sites of startups and not be able to quickly discern what it is they're doing, even after clicking their "about" page. Don't feel like it's repetitive to keep explaining this when most people aren't your customers yet.
Shouldn't they support c an c++ over rust ?Shouldn't they support c#, coffeescript and go before scala or ruby ?
All the latter programming languager are more mature, more used than the supported languages.
For coffeescript: you can use JS, so just compile before uploading. C#: they'd have to start using mono, or host on windows with .net - neither one may be a good solution for them.
When they added Java, they get Scala "for free" in a way. I don't think there's much difference in supporting architecture.
</speculation>
That's a fair question.
Rust was a personal itch, but it also provided a good test for supporting native compilation while providing an excellent dependency management story. We learned a lot from Rust that will apply to C/C++ and we're talking about how we want to address the dependency management story of that ecosystem (and we still need to build a C/C++ client library).
Scala support came alongside Java (and because we're a Scala shop). Ruby was low-hanging fruit because the client already existed. Coffeescript support would be pretty easy to add on top of Javascript pending some demand and interest. C# (on mono) and Go are both interesting languages for us to reasonably land that didn't make this round.
We definitely have more to announce on this front soon. And by all means, we love hearing our users request their favorite languages. :-)
c/c++ are legacy. c# is an m$ thing, coffeescript and go are beginner languages. scala and ruby are used in production.
> All the latter programming languager are more mature, more used than the supported languages.
I wouldn't call c#/coffeescript/go more "mature" than scala. And popularism is unrelated to the topic.