Hacker News Reader

Comment by graetzer | Hacker News Reader

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...

View on HN

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.

Reply on news.ycombinator.com