Posted
by
timothy
on Friday January 29, 2016 @10:30AM
from the parse-this dept.

itwbennett writes: In a blog post yesterday, Facebook announced it is shutting down the Parse developer platform as of Jan. 28, 2017, giving developers a year to move off its hosted services. This comes as a bit of a surprise, considering that just last month, Parse launched a set of new tools to help developers work with Apple's watchOS and tvOS last, and at the time, Parse Product Manager Supratik Lahiri promised more updates in the future. Developers who don't want to rewrite their applications to work with a new back-end service provider can follow a migration guide from Parse to make their applications work with an independent MongoDB instance and a new open-source Parse Server that's running on Salesforce-owned developer platform provider Heroku.

... another web API bites the bullet and all the kids will have to go learn yet another flash in the pan interface to connect to some moronic social site to scrape bullshit data to pass to an app they can sell to idiots.

This is why you should avoid corporate controlled APIs and languages. Things like Rust, etc can just get pulled away at the last moment, leaving you without any future path and support. Lesson learned.

Everything important today is written in C++. LOL! Even Rust's implementation depends on C++, since it uses LLVM which is written in C++! LOL!

It's the same for pretty much all of the other major competitors to C++ out there. The JVM, the.NET CLR, the major JavaScript engines, Ruby, Python, Perl, PHP, Lua, etc., etc., etc., all use C++ or C. C, of course, is just a stripped-down version of C++ these days.

The future has never looked brighter for C++. It's improving at an astound

Rust will be dead in 5 years, just like Ruby and a long list of other tossed away ridiculous languages. C++ forever! Rust is about as Open Source as Android is (meaning "not really" in practical terms).

Put your rabid fanboyism aside for a moment and actually use your brain: Rust fills a very different niche from C++. It is for writing safe code, whereas writing safe or secure C or C++ code damn near impossible.

So within the next decade, you will find Rust popping up anywhere where you need high peformance with strong safety guarantees -- automobile and aviation electronics, high-frequency trading, medical devices, etc.

On the other hand, using Rust for code that doesn't need to be especially safe is a fad

It is for writing safe code, whereas writing safe or secure C or C++ code damn near impossible.

What the fuck? Are you writing C++ code like it's 1987? You do know that the language has evolved, right? If you use RAII and modern C++ techniques, you can develop massive software systems without dealing with raw pointers even once, for example. You get the safety of Rust, but without the many downsides of Rust.

Rust is a lot like Ada. It's all hype, and much less substance. Whatever small amount of safety you mi

People keep bringing up RAII as if it's some kind of panacea. It's a useful tool, but it is no panacea. Sure, you allocated an std::vector on the stack to take advantage of RAII, but if the memory allocation in the constructor fails, it will throw an exception. Are you handling that exception? Because I've literally never seen C++ code that handled std::bad_alloc exceptions.

Do you do a push_back() operation later on? Because that can also throw an exception, and if you have a bunch of push_back() statements

Rust is a product of Mozilla, which as we know has had some tough times lately. They lost their Google sponsorship, and have had to settle for Yahoo instead.

Wrong, wrong, wrong... Moziila chose Yahoo over Google, presumably the deal was better. And looking at it form the standpoint of the Mozilla mission it might just enable more competition on the search market.

I was forced (by a "hip" development director) to try and implement a simple small web application using Facebook's "React" javascript library, and after toiling for three days with it I decided that the only thing you can easily implement with React is something that looks and acts just like Facebook, not surprisingly. I abandoned it and created the site framework-less in four hours. I have no idea what "Parse" is, but I am very wary of these corporate frameworks/APIs/languages since that experience.

It ends when the hipsters are kicked out of the industry. They've ruined everything they've touched. They ruin UIs that were good. They create awful frameworks. They prefer to use the absolute worst programming languages, like JavaScript, for everything. They took git and centralized it on GitHub. They're too lazy and/or dumb to learn SQL, so they use persistent hashtables for storing data, and query it using imperative JavaScript code. It's nothing but idiocy and disaster when it comes to these people. It doesn't matter if it's an 18 year old hipster or a 30 year old hipster or a 55 year old hipster. They all need to find a different occupation.

It's not so bad as long as you stay close to the intent, where you want to do something like facebook, or a blog, with frequently added/updated items and comments and such. So if you're writing a little half-assed blog type thing it would be pretty easy to make it "reactive" to people adding new posts and comments and things. But try and apply it to something like what I was tasked with, which was a little search/modify/create/delete thing it was a complete disaster. YMMV

Parse is/was a service that allowed people who knew next to nothing about server programming to cobble together a backend for a mobile app (or other app that can make http requests).

So in other words it was a tremendously useful or harmful service depending on your level of cynicism. It is of course hard to monetise a solution like this, since any app that becomes highly profitable will attract developers that know how to build a proper backend and then that app will migrate away and stop paying monthly fee

Parse is hugely useful as a way to "assume" a back end. Any good NoSQL database does most of the association work during the write task; in this case on mobile client. With a few housekeeping tasks running on the parse server you can actually make a clean, fast, scalable service but obviously it's also great for prototyping.
I think Facebook dropped Parse because they are not one of the big four making $$ in the cloud and Parse is a SaaS; it runs great on Google cloud.