I have been experimenting with Motoko in #2020. The whole setup gives me the notion that there is much more to come. Especially, the concept of #SmartContracts or #Defi is still in the early stages and I find Dfinity’s setup simply more comprehensive than the infrastructure developed by others.
Hi,
I worked on it with the aim of getting an opinion and a state of readiness and the realities of progress and promises. I also chose to study Holochain with the same objective.
As an engineer I find the subject exciting and promising but I also have to make a report for the government for which I work and in which I will mention these two technologies. Governments have particular needs and constraints, and I think it will take some time for politicians to adhere to these kinds of concepts.
Hi,
For the functional part I think that yes, on the other hand the implementation and deployment strategy is quite different. It seems to me that Dfinity has a much more long term strategy and thought upstream, for example the Motoko language, the way to deploy and how to deploy the network. Dfinity seems to me to have a more solid foundation. But history has already shown us that it is not the best who wins but the slyness, so keep following …
I downloaded the SDK in 2020. Last week I reinstalled it and am exciting about building on the internet computer this year.
However, there are a few enablers missing, such as:
-Recommended IDE environment
-Libraries of functions
-Alternative to ICAN
-Example apps with source code
Long term, will JS be the main front-end language or will Motoko also be suitable for front-end development.
Lastly, I’m torn about whether I should learn Motoko or Rust given that there will be APIs for deploying on the internet computer. Understandably, there will be advantages to native coding, however in the short/medium term, Rust’s big community and support. will be advantageous.
Javascript has the most support and examples at the moment but other web based frontends can work, there are some WebAssembly frontend frameworks beginning to come out that look promising. While Motoko compiles to WebAssembly it isn’t really placed for this though.
For backend, Motoko is very easy to pick up and learn and the strong typing (and seriously impressive type inference @claudio ) makes it very fast to build and refactor code safely. But you’re right, the ecosystem is still small, certainly compared to Rust. Some language features overlap, so things would feel familiar if you started with Motoko then tried some Rust later.
I have not downloaded the SDK. I have been asking questions here all year, and frankly, haven’t been impressed with some of the answers or lack of answers I got, although I appreciate the patience of those folks who have corrected the misconceptions or misunderstandings I had.
I don’t see IC as a serious platform for serious work at this time, not until they make a better case for why IC is so much better for app developers, specifically in the context of real world problems such as demand scaling, data privacy regulations, and customer dispute resolution. Also, showing, with long-promised papers and code, that what is say is true, and providing robust tools and libraries to provide platform support for features that devs shouldn’t have to reinvent ad hoc such as profiling, logging, storage, payment etc.
I think the number of visitors to this forum and the level of activity are very low compared to other platform technologies, blockchain or no. The fact that the Dfinity organization is a closed shop with little public documentation works against it here - engaged, informed community devs are a necessity for a platform tech.
For that to happen they need either killer apps they develop themselves, attracting end customers, or devs like us to choose their platform over alternatives. One followed by the other is what could happen - I’d love to see even one app that might be considered “killer” from the Dfinity team.
As for me, the SDK lacks too much I would consider essential for the things I’d like to try, which are actually getting honest timings, throughput calculations etc. For example, how many size in KB writes can be processed by one actor in a minute and how does that depend on other actors competing for subnet resources? How fast (and how much) to initialize a memory structure that has to have size in MB of data in it before it can be used for anything? Is it possible to cause the IC non-obvious problems with common design choices? Once some of that comes in I can then add the SDK to the pile of excuses I need to get an M1.
I appreciate your criticism @ohmi. I agree that there is still much work to be done before the platform can be taken seriously by wider audiences. Your previous post on the Scalability of update calls in a common scenario underscores some important considerations for building scalable applications. Though perhaps our perspectives still differ. I concur with my colleague that there are many use cases where horizontal scaling is not only possible, but also easy and effective. Please create separate threads for data privacy regulations and customer dispute resolution. Those are great topics for further discussion.
Management was recently given the green light to put all documentation and source code into the public domain, including the Public Specification, the Haskell Reference Implementation, the Production Rust Implementation, the Motoko Compiler, amongst many other things. I cannot guarantee this will include the benchmarks you are looking for, but hopefully it answers more questions than it creates. I think the lack of public materials has certainly contributed to less interest and lower traffic here.
Respectfully, it is highly disingenuous to assert without evidence that the organization is running a Ponzi scheme of sorts. I would not work here if that was the case.
Shipping killer apps that attract end customers is a top priority for the SDK team, and me in particular. We had some success last year with LinkedUp and CanCan, and I was greatly inspired by projects from the Tungsten Demo Day. We are working hard to set the groundwork for what comes next as more features become available and existing features become more reliable.
I apologize wholeheartedly for that reference, I did not intend to imply anything malicious. The entire paragraph was pointless and I removed it. Thank you for your interesting response and I will look forward to more positive news in the days to come.
I am a Founder of a startup in the collaboration software space. We have an app built with traditional tools on a cloud server, weact.chat. I have been looking at DFinity IC as an option for WeAct in the future but finding developers who are comfortable with this kind of port has not been easy. My team is focused on getting the current app out on IOS and Android so they lack the bandwidth to test DFinity.
We also have three other projects being planned for this year (if folks are interested) around disinformation detection, hate speech control, and a fun project to help local businesses/coaches/teachers move online in a Zoom world. ray@oblivion.io.
What is the best way to get an app port idea evaluated by the DFinity team in terms of the preparedness of the platform for said app (weact.chat). We have IOS and Android betas done but we are intrigued by DFinity’s potential. The question - is it too soon to start work on the platform and should we just be doing programming examples? We are also interested in the VC fund setup to fund early DFinity projects. I will work that angle through the website.
That said we are looking developers and or a CTO to help drive this work. ray@oblivion.io