Hacker Newsnew | past | comments | ask | show | jobs | submit | more codonaut's commentslogin

Take out the "ivy league" part and that post describes me pretty well. In school(just graduated in May) I excelled at the algorithmic and mathy side of computer science, but was horrible at the technological side. This really bit me in the ass when I got to a class like Operating Systems where I had to do a lot of C programming.

Anyway, from what I can tell there's really no substitute to doing a hell of a lot of programming. I've also had the thought of, "I know I'm smart, but I think I might be just inherently bad with technology", but now that I've been working full time for 6 months, and have stubbed my toes on more technologies than I did in all of school that thought comes less and less. There are still gaps in my technological knowledge, but by reading hackernews, digging more into Linux, and making projects from the ground up I've been steadily filling in those gaps. Go code and prosper!


9hr battery life is not accurate at all. I bought one recently and while the build quality is very nice, the battery life isn't as long as advertised, and there have been issues connecting to wireless networks as well(need to repeatedly sleep/wakeup to connect to a new network). Apparently the network issues are widespread with this model, and while the newer ones(like I have) don't suffer from low speed I'm still getting poor connectivity.


They do have a history of that, but AppEngine has a huge footprint right now, and Google is only expanding it's cloud platform with Compute Engine, redoing UI, etc. They're clearly investing a lot here, I don't think they'll close this as easily as Google Checkout or others


I thought Google Reader was too big to be shut down too. It had a small % of all users but a large % of power users.


Free services are not guarnateed to remain open. Paid services can continue to live for a long time until market share shrinks so low. GAE can't. It has a deep root in the market.


I supposed, but would you risk your business by locking yourself in to their platform?


Peter Magnusson from the App Engine team recently wrote about the lock-in argument: http://venturebeat.com/2013/07/25/google-app-engine-lock-in-...


I recently discovered this project as a replacement if you're using Java on App Engine:

http://www.jboss.org/capedwarf



Nobody seems to be addressing the author's recommendation about specializing instead of being "just" a software engineer. Is specialization really the road to less boring coding? As a recent entrant into the working world I find myself thinking that may be the road to more interesting work, but don't have much of an idea about what the day-to-day work of a specialist is.


Specialization leads to the big bucks, it's also easier to dodge crap code that is outside your specialty.

It has nothing to do with boring/exciting, that depends on the project/company/coworker.


Loving it! Keep doing what you're doing. One thing I just noticed-- I clicked the Like button which then prompted me to sign up. After doing that I was returned to the same page, but had to click the like button. It's a small thing but applying the action that prompted the signup automatically instead of having to redo it would be a bit of a usability enhancement. Also, an edit button on an already submitted review would be good instead of having to delete and retype.


Nice catch, noted.


Seconded-- Any and all advice that can help lead to a low-cost, low-earning travel lifestyle would be much appreciated!


Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?


Without actually be able to see either script, I would assume that his Go implementation took advantage of some of Go's more natural concurrency features.

The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.


A completely different implementation would seem likely to have been made.


> Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't?

It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time).

As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.


It's funny how people who learn evented programming in scripting languages like Python feel like they've discovered some new hidden concept. No competent systems developer fails to understand what select() does. Suggesting that the author was't "acquainted" with select says more about this comment than about the author of the post it comments on.


>It stalls in Python because the author is not acquainted with non-blocking system programming

Citation needed.

How about "he is acquainted but can't be bothered to use it retrofitted to a language not tailor made for it"?

>As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.

And why you think you're any better than him based on a short blog post (and especially one in which he does not delve into why the Python version was slower or says it would be impossible to make it faster, just mentions it's speed in passing), is beyond me.

Maybe cut down the snark?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: