Objective-C in the Cloud | Hacker News Reader

Objective-C in the Cloud

objective-cloud.com

38 pointsLinaLauneBaer27 comments

I'm torn how to feel about this. I've been developing with objective-c on iOS for several years now, and to say this as gently as I can ..it's not my favorite language. I want to play devil's advocate for a moment and ask some tough questions (these may go away in a request/response scenario where the app isn't running continuously):

* How does Objective-Cloud handle circular references (will memory leaks be a problem?)

* Is there a way to cut down on boilerplate (having to declare member variables, accessors, synthesize them, and understand the differences between var = _var, self.var, static class vars, etc?)

* Any plans to port to other platforms (Android) and if so, will it still use objective-c?

* How do you sandbox binary code (will security be a problem?)

* Will you allow third party binaries/libraries to be uploaded with the code (or will everything be open source/code only?)

To be fair, I believe that this style of development may be the future. Perhaps we need a wrapper around pure C because it doesn't do enough to promote inter-module communication, and C++ dropped the ball on that.

I'm just concerned because objective-c is ideologically different from, say, Boost, D, or Go. It focusses more on patterns than abstractions and simplicity over correctness. I've found it nearly impossible to build an app in obj-c above a certain size that's guaranteed to run indefinitely, stably and without leaks. And I've found that large obj-c projects often lead to spaghetti code and repetition, because of a lack of understanding about things like delegates, inheritance, using notifications instead of nesting code, etc. Some aspects of obj-c are quite brilliant (like queuing tasks on the main run loop) but others like manual memory management are antiquated.

But kudos for this effort. I'm curious how this plays out.

Well, it only helps, right? Many people think Apple invented Objective-C and that it's part of their wall garden. Creating a slightly larger ecosystem of Objective C will hopefully help grow cross platform support.

It would really be nice to reuse some of that iOS code...

I know you don't think Apple invented it but ... Brad Cox and Tom Love did, their company Productivity Products International (PPI) developed Objective-C way back in the early 1980s. PPI became Stepstone, their biggest customer NeXT licensed ObjC in 1988, then in 1995 acquired the trademark and rights to ObjC from Stepstone. And then finally Apple bought NeXT in 1996.

Interestingly, this is not the first time ObjC has been used for web stuff, WebObjects/EOF was originally an ObjC web framework but was later ported to Java.

I'd agree with many of your concerns about Objective-C as a language for writing cloud services. The best thing about it as a language vs. more modern alternatives is that the lack of GC makes worst-case memory allocation times predictable, which is important in a client app but not so much on a server.

The most interesting thing about this to me is that it makes the Apple frameworks (especially the multimedia ones --- CoreImage, CoreAudio, etc) available to cloud services.

I wonder about using RubyMotion or Mono with a service like this. It might address some of your concerns about the language.

> Is there a way to cut down on boilerplate (having to declare member variables, accessors, synthesize them, and understand the differences between var = _var, self.var, static class vars, etc?)

Yes. Objective-C no longer requires most of this.

I happened to be at a presentation the creators of this gave a few months ago

* I think ARC helps with most of the problems, of course you'll have to understand where to use weak or strong etc.

* You don't have to write @synthezize anymore, literals remove a lot of boilerplate too: http://clang.llvm.org/docs/ObjectiveCLiterals.html

* As far as I know the protocol between server and client is just HTTP + JSON

* They use the BSD sandboxing facility https://developer.apple.com/library/mac/documentation/Darwin...

It's still pretty trivial to mess up memory management and segfault and die. Speaking as a full-time iOS person, I don't think I want to write a backend in Obj-C.

When I flub a strong/weak reference on a phone, my app crashes. The user is mildly inconvenienced as they launch the app again.

When I flub a strong/weak reference on a server, my app crashes. That server is now down and my ops guy (probably me) will have some unkind words for me, particularly if it's in the middle of the night.

It's tempting to say at this point "well, don't flub references, n00b", which is much easier said than done. Bear in mind that we did use to write webapps in C - we moved to higher-level, more resilient languages for a reason.

I don't mind Obj-C/Cocoa. I'm a graphics guy at heart, so the closer-to-the-metal implementation makes me happy and lets me spin all kinds of neato magic with custom UIs... none of this is necessary serving data off a server.

Your server crashing can also be a mild inconvenience if your ops person sets things up properly. An occasional crash should lead to an automatic restart + an email to investigate later. A single process crashing is not a good reason to wake anyone up in the middle of the night.

Indeed, the cloud apps are restarted automatically after a crash.

Objective-C has nothing to do with UI. BTW: The first web server has been developed in Objective-C.

Sure, and Amazon.com used to be served from a monolithic C code base - that we did it before (or had to do it before) doesn't make it the best tool now.

All of this reminds me a little of the whole "let's do EVERYTHING in JS!" trend - while technically impressive I simply don't see the point of hammering a square peg into a round hole when there's a round peg nearby you can use.

Re: Obj-C and UI. Obj-C makes it really easy to write highly performant UIs because it's reasonably close to C. You can hit up OpenGL and other extremely fast drawing libs in a really performant way, without invoking any cumbersome hooks or wrappers (see: writing and interfacing native code in .NET). Writing insanely fast and visually complex UIs in Obj-C is a breeze. Its proximity to C is a strength in client-side dev, but it's a liability on the server.

ReRe: The ability to write UI code in Objective-C easy is connected to its late binding. For the same reason it is easy to write services. On Objective-Cloud you have to do /no/ configuration about your service's APIs in external files in a different syntax and so on. You simply define that in your Objective-C code as usual. (= As you would do with classes and protocols in your local code.) I think that this sounds like a good tool for the job.

Use the actor model to design your code. Include a supervisor tree in your design so that the supervisors will notice when a piece has segfaulted (or is leaking memory) and deal with it, This is not rocket science and really has nothing to do with ObjectiveC. Any kind of serverside app could segfault or use up all available RAM. People have solved this problem in other languages and it is easy enough to solve the problem in ObjectiveC as well.

There are bindings for ZeroMQ http://zeromq.org/bindings:objc which is all you really need to deal with stability issues.

Personally for me, most of my frustration comes from iOS's UIKit and especially their entire UIViewController container class set. It's very fragile and picky. Simple Objective-C is far less of a headache to deal with.

Also as a side effect of practically being an apple hardware only environment and it being a compiled language, you don't have the option to create a 2 or 4 socket CPU beast to compile programs with.

I'm in the same boat as you, and I was really excited to remove a tool from my already heavy tool belt, but I'm not sure where this one fits in. In my mind, I'm comparing it to Sinatra, and how quickly can I go from an empty file to a running service, and this seems to have a lot more steps than I would have considered necessary. I still want to play with it some more, but I'm not sure it's the right tool for my web needs.

One mitigating factor is that a properly written cloud app would have lots of small/simple services loosely coupled by a database and/or some kind of message queuing service (AMQP).

That would limit the complexity in comparison to the way that a monolithic IOS app is built.

So this is still pretty mac-centric, right?

I tried using Obj-C on Linux as a "better C", much like people use C++, D, Rust...

The language is... acceptable. The ecosystem is just, mac, mac, mac.

We made the service completely non-mac-centric. One of the basic ideas is, that you can develop a service on the mac that uses all the frameworks of OS X, but the client can be written in C, C++, Java, … Anything that knows HTTP and JSON.

This looks very awesome! I like what this is providing. I really like coding in Obj-c (not my most used language but love the syntax and feel) and being able to make a backend using code that could be shared with an iOS/Mac client is a very attractive feature to myself.

I'm already sold on your service. I can't wait to get started and I'm really looking forward to the iOS and Mac SDKs.

WebObjects 4.5 anyone? For those not familiar WebObjects was the Objective-C framework created at NeXT for developing Web Apps in the 90's.

It was then later on ported to 100% Java.

WebObjects 4.5 was the latest ObjC version and was cross platform even at the time: NeXT, Windows, Solaris and HP-UX.

I've been playing around with the API and tools for the last hour. Seems pretty cool. Very easy to understand and very straightforward. It sure is nice to be able to share code/language between the client and the server. If not for immediate full blown production usage, this can still be a very effective tool for an iOS/Mac developer who might not know their server's language and frameworks. The developer will be able to get a useful, functional prototype up and running very quickly. It does seem like a very enabling tech for iOS/Mac developers.

Edited for style.

I currently use Parse but I could definitely benefit from not having to switch between Obj-C/Javascript(Parse Cloud Code) when writing my backend. As well it would be nice to copy/paste logic between client/server. However, I think I'd have to see Push notifications and another layer of abstraction added to the database layer before I considered switching to Objective-Cloud.

If Apportable delivers on its promises you could theoretically never leave Objective-C land.

This definitely looks very interesting. I think I'll give it a try later this week. It would be awesome to do some coding in Obj-c for HTTP services for a change. Also, the name works out perfectly (Objective-C)loud, hah.

The client SDKs will be published next week.

Very cool. Looking forward for the iOS SDK

objcloud.com is available, why not go with that?

Because I just bought it for no real reason.

Reply on news.ycombinator.com