Capitalist Soul Rises as Ho Chi Minh City Sheds Its Past - <AUTHOR> http://www.nytimes.com/2015/07/21/world/asia/ho-chi-minh-city-finds-its-soul-in-a-voracious-capitalism.html <comment><USER2> I have a passion for history. I love reading biographies and hanging out on history forums.

As we're getting to the 50-year mark past the American involvement in Vietnam, things are progressing in ways not anticipated at the time. Vietnam, like several other Asian countries, is embracing capitalism and entrepreneurs. Old enemies hug and pose for photographs.

This seems to be a pattern, at least among American conflicts (I have not studied others very much). As the combatants grow into old age, it's not worth carrying a grudge around. Things that were worth dying and killing for 50 years ago are still important, but they're fights for young people. It becomes easier to see things from the other side.

I'd argue that by simply having a huge presence of Americans in Vietnam for so many years, the two countries have become joined for the next century or so, much the same as having kids in a marriage joins the two partners together even if they can't stand one another. I also note that things may end up turning out better for Vietnam in terms of economic development than if South Vietnam had won the war -- which would have only institutionalized worse corruption than they currently have.

This is all speculative, of course, but I seriously doubt anybody in the mid-70s would have guessed that this is where we'd all be 40 years later. It's been an interesting journey for both countries.

<comment><USER3> > _Things that were worth dying and killing for 50 years ago are still > important, but they 're fights for young people._

So what was behind the Vietnam War that was worth dying and killing for? What would _you_ have died and killed for, when young?

<comment><USER4> Protecting your country, friends and family from an aggressive, invading force?

Ridding your country of a brutal, corrupt puppet dictatorship propped up by said aggressive, invading force?

I think most people would see that as a valid reason to kill and die for. Hell, said aggressive, invading force even convinced _their_ young it was worth to go kill and die to do the invading, should be a piece of cake to convince those being attacked

<comment><USER3> I meant that from the American perspective, but alright.

> _Protecting your country, friends and family from an aggressive, invading > force?_

And on the invaders' side? What exactly were the American soldiers dying and killing for?

> _Ridding your country of a brutal, corrupt puppet dictatorship propped up by > said aggressive, invading force?_

How about just going for the dictators specifically? The Vietnamese people declaring that they _will_ kill any dictator the US installs there might have done the trick, as opposed to dying by the millions fighting the vastly superior American military.

But it's not that simple either. Think of something like North-Korea. Any sane person there sees that what's going on is totally. fucking. fucked. up.

But even if someone thinks freeing people from the insanity there is worth dying for, what if his death didn't actually result in the insanity ending? .. Fear, is sadly what keeps mass-murdering tyrannical regimes in power.

<comment><USER5> Many people truly believed at that time that countries re-forming into Communist states could build a kind of momentum, like a row of dominoes tipping over, and that allowing Vietnam to fall would inevitably lead to the US fighting off a "Red Dawn" invasion from the rest of the world that had gone Communist.

As with other wars, the justification was "fight them there, so we won't have to fight them here."

This works, because young military recruits are not often skilled at the skeptical, rational questioning of authority. Many of them _literally_ believe that the invasion and occupation of foreign territory makes the US safer. It isn't until much later, if ever, that they face down the cognitive dissonance and accept that they were just pawns in the game of global politics.

<comment><USER3> Sure, but now you're just describing the _propaganda_ that was used to get ordinary people to die and kill for their rulers.

<comment><USER5> Every step backward along the chain of causality is an equally valid reason.

Someone believing the propaganda is as much a reason as someone writing it, or someone ordering that it be written, or someone inventing the _casus belli_ behind it.

It is a fallacy to assert a _true root cause_ in anything, because no event is so cleanly disconnected from the rest of history that you can definitively say that a deciding event is truly independent of all those that came before.

<comment><USER3> The root cause for _any war_ is psychopath rulers wanting more power and more wealth for themselves. The rest follows from that. Of course, the rulers will be spewing bullshit propaganda to get their peons to go die for them.

The commenter I originally responded to seemed to suggest that there would be a "good" reason for people to go die or kill people in a war.

But enriching his rulers is not exactly a _good_ reason for an ordinary person to kill or die trying. What's in it for him? Wouldn't he much rather not do it?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> No mention of Cuba in the article but I think we can all agree that increased engagement could very well lead to the same results - increased freedom and wealth for all Cubans.

Interesting note on that topic: only 20 years after Bill Clinton normalized relations with Vietnam it's now "one of the most pro-American countries in Southeast Asia, with 78% of Vietnamese people viewing the U.S. favorably in 2015" according to Wikipedia: [https://en.wikipedia.org/wiki/United_States–Vietnam_relation...](https://en.wikipedia.org/wiki/United_States–Vietnam_relations)

<comment><USER7> Cuba does better than Vietnam by all measures. Education (literacy rate is 80% in Vietnam vs 100% in Cuba), healthcare, nominal GDP (2k in Vietnam vs 6.9k in Cuba per capita), Human Development Index etc.

Being pro-American (whatever that means) is not the holy grail or something like that. Besides, the notion that Cubans hate the US is just wrong.

<comment><USER8> "By all measures..." No, not by all measures. By some statistics, sure. But Cuba is an oppressive police state. Sure, humans can live long, healthy, literate lives in captivity. Yet what value is literacy when the state regulates what you can read and what you can say?

<comment><USER9> > But Cuba is an oppressive police state.

So, like Vietnam? [1]

1: [http://www.ibtimes.com/vietnam-police-state-where-one-six- wo...](http://www.ibtimes.com/vietnam-police-state-where-one-six-works- security-forces-1401629)

</comment></comment></comment></comment><comment><USER10> Hello Saigon! I'm curious what other tech entrepreneurs/nomads we have out here. I've met many interesting, passionate technology people here, some expats and some locals. It's great to see the diversity in the scene here, just like you would expect from a major US city.

There's a lot of raw talent here, thanks to the outsourcing industry, university system, professional schools and huge number of young people looking to exceed their parents' standards.

If you're in Saigon - what are you doing here? I have a US company and am building the product with a relatively small team. Web focused, microservices/React stack.

<comment><USER11> I'm a programmer who just left Saigon after ~ 6 weeks.

Excuse the language, but it's kind of a shit hole, even a lot of the "nice" D1 parts... One of the most polluted cities in the world, swarms of motorcycles everywhere, always trouble walking from A to B, permanent hearing damage from crappy vehicles' shrieking breaks or the constant honking.

The expats I met (and let's not kid ourselves, a lot of them are straight up 'sexpats'... and there are infamous bars in town for that) wanted out. YMMV.

The good parts... Vietnamese people are amazing, very friendly. There are tons of cafes to work from. You can live in a 4 star hotel on the cheap.

Even so, I wouldn't move to Ho Chi Minh. Has a long way to go.

<comment><USER10> The experience you get out of something largely depends on how you approach it.

I live in a wealthy, quiet neighborhood - where most of my neighbors are Vietnamese and a majority of them are wealthier than me. Because of this and good networking I've met many successful business people, startup entrepreneurs and consulate generals. I'm also committed to here. I speak the language, have an office and team here. That level of commitment opens more doors than if I was just passing through. When I'm ready to move on to my next project, it will be hard to say no to many of the opportunities here.

There are a lot of expats who are unhappy here, though you'll find that in any expat community. A lot of them like to complain. I avoid those types if possible - more fun to be around future oriented people than past. (And that's one of the best things about Vietnam - it's so young. I'm sure you've read the statistics before, 70% under 30 years old. And most of them are excited for the future.) As for the sexpats maybe I don't see them - maybe I'm happily married with kids and don't hang out in the backpacker areas or bars.

Completely agree with you about the pollution. It's the hardest thing for me, which is why I live on the edge of town across from a jungle and a river and not in District 1. (View from my office [https://goo.gl/photos/wuMnNcKFFnAMUNsn9](https://goo.gl/photos/wuMnNcKFFnAMUNsn9))

Had my approach to Vietnam been different my opinions would be completely different. No way is the right way, just different.

</comment></comment></comment><comment><USER12> Totally agree. Never felt so free to go about my life and business as in Saigon. Watch out with physical businesses however, foreigners can get scammed out of their stake.

<comment><USER13> Do you have any personal experience you can share with foreigners getting scammed?

<comment><USER12> There was a French accountant in his late 20s who came here with 50K EUR of life savings and opened a French restaurant with a local partner. Worked 7 days a week for 6 months, restaurant was losing money, one day he gets kicked out by his partner with the help from some of his gym friends.

That guy is now back in France in a job. He somehow managed to find a girlfriend while starting his restaurant though. He's now engaged to the girl but she's still here.

</comment></comment></comment><comment><USER14> Also a good place for digital nomads & bootstrappers: [https://medium.com/digital-nomad-stories/bootstrapping-in- sa...](https://medium.com/digital-nomad-stories/bootstrapping-in-saigon- fc9744367386)

<comment><USER15> I'm about to try the same thing in Mexico but reading that made me really home sick [sic] for Vietnam. Almost looking forward for when my visa in Mexico runs out and I have to leave...</comment></comment>


IBM says Swift is ready for the enterprise - <AUTHOR> http://www.computerworld.com/article/3122994/apple-mac/ibm-says-swift-is-now-ready-for-the-enterprise.html <comment><USER2> When I recently interviewed at Apple I was told my position would primarily be coding in Java, but the team would be open to other languages as the project progressed and needs changed. I asked if they would consider Swift. Then was told that Swift wasn't production ready in their eyes.

(I didn't get the job)

I guess every team is different, but this attitude to dog fooding isn't great.

<comment><USER3> I interviewed at IBM for a position making Enterprise template apps for iPad working directly with Apple, and the main reason they said they passed on me was while I had a good amount of Objective-C experience, I had only dabbled with Swift on my spare time and had difficulty answering a couple of the questions they grilled me on in Swift.

They specifically said I should have had more professional Swift experience when they rejected me. Of course all the companies I worked for were being more conservative and hadn't yet made the leap to Swift yet, so getting that professional experience was pretty much impossible. But I guess if anyone can afford to be picky, it's IBM on a project working directly with Apple.

So yeah, IBM is definitely gung-ho about Swift. Apple itself, possibly less so.

<comment><USER4> IBM advertises jobs yet when qualified people show up, they are rejected. Either it's a way to look like they are reaching out to the public to satisfy the government so they can then go hire outside the US; or it's a way to let insiders get those positions after the applying public are rejected, all IMO. When I was in there, 99.999% of the people I met came in through acquisitions, not applying for a job and getting hired.

<comment><USER3> A recruiter for IBM contacted me, actually. I didn't respond to an ad.

</comment></comment></comment></comment><comment><USER5> Does this loosely translate to "We want to sell Swift consulting services to the enterprise"?

<comment><USER6> Yes, preferably on top of IBM Cloud.

[http://www.ibm.com/cloud-computing/bluemix/swift/](http://www.ibm.com/cloud- computing/bluemix/swift/)

<comment><USER7> After the Helion debacle, I have my doubts about "enterprise" clouds.

<comment><USER8> I don't have any clients which will use any cloud solution other than half on- prem SAP and _maybe_ Azure are the only cloud solutions my clients will come close to touching, so forgive my ignorance but which debacle is that? (Genuinely curious from ignorance, not being flippant.)

<comment><USER7> Oh, HP launched a cloud, then shut it down again.

[http://uk.businessinsider.com/hp-shutting-down-hp-helion- pub...](http://uk.businessinsider.com/hp-shutting-down-hp-helion-public- cloud-2015-10?r=US&IR=T)

The last thing you'd want is to do a big migration then find the rug pulled from under you.

</comment></comment></comment></comment></comment><comment><USER9> Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs.

But I don't see as much upside for enterprise development. Server side tooling and deployment is still TBD, reference counting adds non-negligible cognitive overhead vs GC in an environment where the downsides of GC matter much less. They will have to build a complete ecosystem of server-side libraries from scratch. And unlike on iOS/OSX, there are already a lot of good and much more mature alternatives.

I wouldn't be unhappy if Swift became a real contender on the server but it seems unlikely to me that it will.

<comment><USER10> Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory)

To me sure there is things you think about but generally memory performance is less of a mental burden.

Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.

<comment><USER11> Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).

<comment><USER6> It is much easier than in either C++ or Rust.

<comment><USER12> Technically true, but very misleading in Rust's case. In Rust you rarely have to break retain cycles in the first place, simply because you don't use reference counting much. Things like "weak self" are not a problem, because closures aren't reference counted unless you explicitly make them so (and in fact I don't think I've ever seen a reference counted closure in practice).

<comment><USER6> I agree.

I only mentioned Rust, because of ergonomics, since the compiler cannot guide the user unless the types are known.

Or is already something in place to make use of intrisics for better error messages in such cases, instead of just giving a type error?

</comment></comment></comment></comment></comment></comment><comment><USER13> Hilarious that IBM still thinks of the enterprise as the arbiter of quality. Consumer is now setting the defacto standards, including on things like information security.

IBM's days of having a voice in that conversation are probably more limited than they realize.

<comment><USER14> would you car to give some exampled ? My opinion is that the enterprise is a somewhat separate ecosystem. Thus "enterprise-ready" -ready is not a mark of quality, it's a mark of belonging to the enterprise ecosystem.

<comment><USER15> I'm wondering what makes swift ready for the enterprise ecosystem. It barely seems to meet the requirements of the "enthusiastic consumer" outside of Apple OS.

<comment><USER16> To be ready for the enterprise ecosystem basically means that you can sue someone if things go wrong, and you can buy support packages for enormous sums of money. IBM is saying that you can 1) buy bluemix swift from them, and 2) sue them if anything goes wrong - but since they have a great legal team, they probably got ironclad agreements ready to go.

<comment><USER17> It's not about having someone to sue it's about attracting blame.

Blame assignment isn't really about who made good decisions, or who worked hard, or any of that, it's a combination of how bad it went and who made uncommon choices:

common choice + failure = external blame (who could have seen it coming?)

uncommon choice + failure = it's your fault for doing it weird

common choice + success = great job!

uncommon choice + success = I don't trust you, but you might be a genius

Since hierarchical relationships function using blame ("responsibility"), making predictable decisions becomes more important than making good decisions at some depth of hierarchy.

<comment><USER8> This is probably the most important comment in this thread. Being able to delegate blame out to $common-choice on project failures is the difference between that CIO being able to say "hey, not my fault, I bought the Oracle platinum integration package!" to satisfy the board rather than "sorry guys, I really thought my node.js idea would work, it's all the rage with the kids! Haven't you ever heard of Slack?!"

(If this sounds strange to you, just replace "node.js" with "Rails 2" and you'll see why ASP.NET and Java's still king in any company with a market cap > 100MM && age > 20 years. It's about continuity of support, and Windows 2016 servers can still run ASP Classic and .NET 2 WebForms apps just fine.)

"Responsibility" == risk mitigation for that purchasing authority.

<comment><USER18> Slack is PHP and Jquery, no nodejs AFAIK.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> So... what's the "elevator pitch" for Swift?

It has _anything_ interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) or Scala or Kotlin?

I know that iOS and MacOS desperately needed a _modern_ language, and great for them that they have it now, but does the rest of the world need it?

<comment><USER20> I think the pitch is that despite static typing, it offers a lot of multi- paradigm high-level features while remaining elegant with fairly minimal syntax compared to other native static languages like Rust or C++. It automatically manages memory but without a stop-the-world garbage collector and goes a long way to opening a lot of flexible design options to any developer: it has great support for generic programming, object orientation, and functional programming.

The downsides? Well, I find some of its syntax choices a bit odd and inconsistent; I think the pursuit of elegance could have gone much further. And, while I celebrate its pervasive use of closures/lambdas and functional idioms in my many contexts, it lacks true functional data structures that would be necessary to really write in a proper functional style with confidence that the runtime wouldn't suffer.

Also, the implementation of its high-level features is somewhat magical and hidden. You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive.

Additionally, at least on the Apple platforms, its Objective-C heritage can be a bit annoying. In particular, you can't mix and match closures with "selectors", which is a real shame and missed opportunity for flexibility and elegance.

<comment><USER21> One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully.

The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.

<comment><USER22> I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable.

Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a project.

I love going back to Ruby dev because VS Code is just such a joy to work in compared with Xcode. Xcode really struggles on my top of the line MBP with 16GB RAM.

I still love the language compared to ObjC but the tooling is abysmal. Every year we hold out hope that Xcode will magically get better but its the iTunes of IDEs at this point.

<comment><USER23> Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references.

You can always use AppCode if you don't like Xcode.

<comment><USER24> AppCode has also become increasingly buggy over the last year or so, and is now almost as unusable as Xcode (albeit in different ways).

On my computer, recent versions of AppCode _constantly_ use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.

I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.

There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).

It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.

</comment></comment></comment></comment></comment></comment><comment><USER25> This reminds me of the big announcement of IBM partnering with Apple for iPad in the enterprise. I wonder how that worked out?

I am a little sceptical of IBM's business plan, all in on Watson, etc., but I have used their Bluemix hosting services and it is fairly nice. BlueMix is has a great free tier level' you can run one or two small web services or apps for free. It is a good idea supporting Swift in the server.

<comment><USER8> There are plenty of enterprises silently chugging away with Cognos as their BI platform. 'IBM MobileFirst' (i.e. some guys basically make a 'custom' dashboard for your TM1 instance that C-levels can use on their iPhone) probably broke a profit by doing what they do best. (I.e. severely overcharging companies for functionality, in exchange for the purchasing authority having the ability to say "hey I bought IBM"). Cognos still is silently huge (TIBCO and Informatica levels of huge) and considering how the corporate world went from BlackBerry to iPhone, it's a safe bet that it made a profit.

Side-note: There was an article about the imminent demise of Oracle, but residual support contracts and the need for CIOs to keep renewing those contracts for a few hundred k a quarter is a cheap buy as insurance in the same way you go to PricewaterCooper and not JoeSchmo to get your books audited. (If/when PWC messes up, the board will overlook your failure.)

</comment></comment><comment><USER26> I cannot take this seriously. Even minor versions of Swift have breaking language changes and depredations. That tells me precisely it is too early for the enterprise.

<comment><USER27> That sounds like every enterprise application I've ever used – if you make money selling support and consulting, churn is awesome!

<comment><USER28> That explains "enterprise ready" then. :)

</comment></comment></comment><comment><USER29> I love all these zippy marketing keywords: "digital transformation" and "digital experiences". IBM is trying hard to get developer attention. They have a hard battle ahead of them to compete against AWS, Google Cloud and Azure. That's what this really all comes down to, pushing their hosting services.

</comment><comment><USER30> I literally just started to go back and re-learn some of the core concepts for the latest version... wow is Swift ugly!

EDIT: I'm not attempting to discredit the greatness that can be had... Just wanted to describe a feeling which I had while using it is all!

<comment><USER31> It's a systems language, and imo way more beautiful than c++.

<comment><USER30> Absolutely. I'm not attempting to put it down as somehow not worthy of anyones time, just thought I'd mention how "cushioned" it all felt :P

<comment><USER31> What language do you prefer over Swift? I'm curious.

<comment><USER32> C++11 with review-enforced RAII. Boost if you need special stuff involving odd data structures. gtest/gmock. Depending on what you're doing, add some Qt5, OpenCV, OpenMP, RapidXML/RapidJSON, any C library ever written - and there are BSD/LGPL libraries for pretty much anything. Make plugins with Lua. Run tests in Valgrind.

</comment></comment></comment></comment></comment><comment><USER33> In '95 I remember going to an excellent Smalltalk course. A year later that lecturer was working for IBM on Java. IBM '96 also bought and then shifted an excellent Software Configuration Management System by OTI towards Java (aka. Eclipse). IBM contributed a huge part of Java networking code too.

Java seems to be leaving a gap for various technical reasons. Java also may be seen by some as having strategic challenges under the Oracle stewardship. Go, Swift, Node and others are currently trying to exploit it.

Java took off not the least due to IBM stepping into the SUN court. Now IBM steps into the Apple court...

<comment><USER34> That's a good point, but do you think that things have a chance of playing out similarly this time around? I get the feeling that web tech was more of an open question at that point, so people would look to a group like IBM to set the standard. I'm not so sure that that's the case anymore (and I make my living building within the IBM ecosystem, so I wish it were so).

</comment></comment><comment><USER35> What exactly do you need in a server-side language these days? Most of the interaction is done on the client, in javascript. Your web service should just be responsible for handling basic request/response, CRUD operations and delegating to other more specialized systems when the need arises, which can be written in the most appropriate language given the problem domain and tools/libraries available. More often than not what dictates language choice is supporting libraries that you'd rather not rewrite from scratch. How good are they, how long have they been around? etc...

For that, its often just easiest to use anything non-blocking to serve as the main handler that communicates to your other services. For me, I use node but there are other choices if you don't like javascript.

Most of the time it's not worthwhile to switch to a language just because IBM deems it suitable. I've picked up more than a few freelance gigs where IBM have botched the job and grossly overcharged for something that could be done simply. My clients appreciate my honesty, openness, and simplicity of work.

What they really mean when they say "Swift is ready for the enterprise" is that THEY are ready --- they have developed all the sales materials, support orgs, and hired the "correct" developers (in this case Swift ones) to run their gambit on as big of fish as they can.

</comment><comment><USER36> Swift is good for enterprises that standardized on Macs and ios devices, but there aren't many of those (yet).

I'm pretty sure Swift isn't ready on Windows, which is a shame because most "enterprises" standardized on Microsoft Windows and Active Directory.

Go (golang) has better support for a wider variety of platforms, but it has serious bugs on non-Linux platforms (as of go 1.7.1) that make it unsuitable for the enterprise. Basically, whatever customized Linux distro used at Google will likely get the most time from superstars on the go team. Also, calling C functions and callbacks from C can cause all sorts of issues, and the "cgo isn't go" mantra scares me when considering Windows desktops, etc. as a target platform.

C++ is making a comeback and I like C++14, but backwards compatibility and other factors make it too complex compared to other languages. But at least it supports all the major platforms and there's no worry it'll drop support for one due to vendor politics.

Rust looks promising from a cross-platform perspective like C++, but Rust is still way too new for the enterprise just like Swift. Perhaps in five years, it'll stand a chance in the enterprise (as much as C++) and without the complex baggage from inheriting decades of backward compatibility.

Who knows what'll happen by the time Swift or Rust is considered enterprise ready and truly cross platform -- maybe in 5 years, there will be a cross- platform native compiled F# that doesn't heavily favor one vendor's platform or nim might skyrocket out of obscurity -- who knows, but its fun to imagine and do some coding to make the future brighter.

</comment><comment><USER37> Enterprises value stability over all else. Given the rather large changes to Swift 3, I don't see Swift as being "Enterprise Ready" just yet. That would require someone committing to maintain and patch Swift 3 for at least the next five, but preferably ten years.

</comment><comment><USER38> It's probably just IBM luring attention for its cloud service. I can't read anything other than that from this piece.

The real sign would be one day Apple telling us they are writing iCloud service or at least some significant part of it in Swift for Linux.

</comment><comment><USER39> The article mentions IBM's web framework:

[https://developer.ibm.com/swift/kitura/](https://developer.ibm.com/swift/kitura/)

Has this one gained the most traction?

<comment><USER40> I would say this one has the most traction so far: [http://vapor.codes/](http://vapor.codes/) [http://vapor.university/](http://vapor.university/)

</comment></comment><comment><USER41> For those that missed it, IBM showed some promising stuff in the "Going Server-side with Swift Open Source" talk this WWDC:

[https://developer.apple.com/videos/play/wwdc2016/415/](https://developer.apple.com/videos/play/wwdc2016/415/)

</comment><comment><USER42> Well, that's just not true IMHO. They need the ABI stability or I wouldn't do anything for enterprise. Also, Foundation getting open sourced is a huge part of this to avoid using third party libs for a huge amount of things (HTTP requests for example).

</comment><comment><USER43> I see a bunch of stuff in their github ([https://github.com/ibm- swift](https://github.com/ibm-swift)), but not the language implementation itself. Does anyone know what its license is?

<comment><USER44> Do you mean [https://github.com/apple/swift](https://github.com/apple/swift) ?

<comment><USER20> The post is about IBM's Swift implementation.

<comment><USER40> Swift, the language, is from Apple. IBM simply has built a bunch of tools for Swift and would like to sell consulting services around them.

<comment><USER20> Yes, but I thought the question you replied to was about IBM's implementation, and thus their github page for it.

<comment><USER45> What? They don't have their own implementation...

<comment><USER46> I've heard they ported GCD to Linux, though. Would love for that to be open- source.

<comment><USER47> It already is, and IBM did do a lot of the work in porting it:

[https://github.com/apple/swift-corelibs- libdispatch](https://github.com/apple/swift-corelibs-libdispatch)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER48> I think IBM might be moving Java/Websphere technical staff to Swift. Considering new versions Java/JavaEE are getting delayed so IBM would prefer to use Swift increasingly instead of Java.

<comment><USER6> Not sure, but they are already making J9 modular and using its JIT and GC for their own implementations of Python and Ruby.

So I would say IBM is scattering their eggs across multiple baskets.

<comment><USER48> Indeed. IBM is also investing a lot in Go by porting it to their hardware and OS primarily for blockchain stuff.

I think it is more of thing that Swift has more interesting Client/Server/Mobile story than Java. Given that I do not see why IBM would not cut investments in Java.

</comment></comment></comment><comment><USER49> How is it going with Linux, Windows, BSD, etc. platforms? Anyone with experience using Swift on something other than an Apple product have a story?

<comment><USER50> I'm pretty sure I saw a port for Arch as well.

<comment><USER51> I wouldn't call it a "port", but basically the Ubuntu binaries are universal enough that you can unpack the .deb, symlink a few things to match Ubuntu naming and run the binaries on Arch.

</comment></comment></comment><comment><USER52> I have serious reservations about IBM's involvement in Swift. I spoke with someone _very_ high up in the Sun organization once who said IBM was the worst thing to happen to the JDK. Which is saying something since IBM wrote most of the JDK.

IBM seems to make a mess of everything they touch. I really wish Apple had taken a "Thanks but no thanks" stance when approached by IBM.

</comment><comment><USER53> So is this finally the result of the Apple/IBM partnership that was announced a few years ago?

<comment><USER54> No, this is one small piece of the partnership. The companies have been partnering on iOS apps for specific industries since the announcement.

</comment></comment><comment><USER15> Which version (Swift 2, 3 or 4)?

<comment><USER39> Swift 3 is the version with large source change. It required a lot of refactoring. Fortunately, many of the fixes were handled automatically by Xcode. I'm keeping a list of changes:

[https://h4labs.wordpress.com/2016/09/17/my-ios-10-and- swift-...](https://h4labs.wordpress.com/2016/09/17/my-ios-10-and- swift-3-refactor-list/)

Any breaking changes going forward should be much less. Of course, you might be in the camp that wants zero breaking changes, then Swift probably isn't for you.

<comment><USER15> Do you really think Swift 3 is ready for enterprise usage? They say the core lib is not ready yet for production usage[0]. It's not about how may breaking changes I'm willing to take but in the enterprise world there is little incentive to rewrite large code bases. Even in the start-up environment the more code you write the less excited you are about breaking changes. Also Xcode doesn't run on Linux or windows and last time I've checked MacOS was not the the OS of choice in the enterprise world so Xcode is not an option. Next claim I'm expecting is that Swift is ready for the InSight Mars lander mission.

[0] [https://swift.org/core-libraries/](https://swift.org/core-libraries/)

<comment><USER39> I haven't used Swift on the server yet, so I can't honestly say. I'll give it a try soon.

However, it's probably best for devs who are already using it for apps (code reuse, experience, etc). For other dev, I might try Elixir, for example, for web dev. It is gaining a lot of momentum. A critical mass in adoption means better support, quicker answers to questions, etc. We all can't pay IBM to worry about the details.

</comment></comment></comment></comment><comment><USER55> I have access to books for Swift 1.0/2.0 as some has given them to me for free. How much of it is useful when it comes to breaking changes that came with 3.0 ?

<comment><USER54> If you don't already know Swift you'll be wasting your time. Swift 3 looks and behaves very differently from Swift 1. Fortunately, the Apple Swift book is free, up to date, and written well.

<comment><USER56> [https://itunes.apple.com/us/book/swift-programming- language/...](https://itunes.apple.com/us/book/swift-programming- language/id881256329?mt=11)

</comment></comment></comment><comment><USER57> "IBM says it's ready to receive its next Apple check"</comment>


The next, next big thing - <AUTHOR> http://radar.oreilly.com/2011/05/next-big-thing-web-mobile-data-ubiquitious-computing.html

<comment><USER2> I'm willing to believe hardware will be a big thing again soon: the transition of 3d printers and scanners from industry to hobbiest suggests there's room for even broader consumerization. Cory Doctorow's _Makers_ is a compelling vision of that future.

</comment><comment><USER3> It doesn't need to be a question of thick xor thin client. We've tried the thick client (and we're trying it again with the rise of AWS). We've tried the thin client (and we're trying it again with the rise of Chromium). It's almost like our technological adventures are a virtual Edison: "I didn't fail, I found ten thousand things that wouldn't work". I think the next, next big thing will not do away with the web, or the thick client, or the thin client, or big data, but represent a fusion of our understanding of all of these things.

<comment><USER4> I fully agree, and I'd like to add that this kind of fusion is already happening all over the place, blurring the line between what we used to call "thin" and "thick" clients.

For instance, a browser running huge amounts of JavaScript (e.g. ExtJS and stuff) can't really be called "thin" client anymore. On the other hand, a slick native app that does little more than presenting nicely some weather data can't really be called a "thick" client. Also, a huge "native" Java application that depends on the web and has auto-upgrade mechanisms is in many aspects very similar to huge JavaScript applications that are cached by the Browser.

Any application that needs to share data with other instances will need some server and some client part. The only question is where to put which part of the application.

Is the client merely a displaying tool like VNC? Or does the client actually run application code, and the server is just some kind of database? Which parts of the data is processed server-side and which client side? Or, is the server part decentralized and the clients communicate via P2P?

Maybe the application is even a combination of all those strategies, using in each corner of the application the most appropriate strategy.

Given all those possibilities and the wide range of succesful strategies that can be observed in the wild, drawing a sharp line between "thin" or "thick" client is already impossible today.

</comment></comment><comment><USER5> the next next big thing will be computation being so ubiquitous and interconnected that no one except developers even thinks about where the juice for any given activity is coming from.</comment>


"They've invented a new machine" – a folk song's mixed emotions on automation - <AUTHOR> http://rrherr.com/2015/05/11/peg-awl-a-folk-song-with-mixed-emotions-about-automation/

<comment><USER2> "Anxiety or optimism – which side is the song on? It depends who sings it."

As you describe, doesn't it also depend on the lyrics?

After all, the version from The Carolina Tar Heels (1952) has "New machine has set me free." The Molsky version deliberately changes the lyrics to make it sad. Had that line remained in the new version, would it still be sad?

FWIW, other examples of folk songs of how change [1] can leave people behind are the ballad of John Henry (eg, see George Pal's 1946 cartoon) or Phil Ochs "Automation Song" ("Now you've got new machines for to take my place ... I'm walking down a jobless road and where am I to go") from 1964.

[1] You quoted 'Progress can leave some people behind, even as it benefits society'. I use the word "change" because "progress" has two meanings: change over time, and positive change over time. The book you referenced seems to suggest that all progress benefits society. I disagree with that viewpoint, so I used a more neutral term.</comment>


Ask HN: Should I pretend that my startup is already successful? - <AUTHOR>

For SEO reasons (after reading patio11's greatest hits), I'm starting a blog in parallel to developing my webapp.
Now, I realize that I could write posts in two different tones: admit that I'm at the very early stages of this product and that I don't have users yet, or I could talk like I already have several users and I'm talking about some topic because someone mailed me about it, and I felt like clearing things up.
Even features could be presented in this way: "Several folks have asked me to implement X, so I finally did it this weekend. Tell me what you guys think about it."
The first is the one I'm naturally inclined, but by judging by some unanswered emails I've sent, being sincere this way makes you look like you're begging for them, and no one likes that (aka a loser).
The second one would be a "white lie" which would make customers feel safer and confident about the webapp. This might also make them less forgiving to any errors I make in the early days. <comment><USER2> Depends a bit who you're selling to and what you're selling. Governments organisations have special data requirements that are difficult for a small startup to reliably promise, for example. Clients and big brands want reliable phone & tech support for at least a year, and need to know your tech can handle the scale they operate at. There again, you'll need to posture as larger and more stable than you are.

But just because you're at a disadvantage in these types of sales, I still wouldn't recommend misleading anyone, since it's inviting disaster -- I'd suggest choosing products/customers where small is okay.

One time purchases that don't rely on support, upgrades, or workflow changes are easiest for big customers to buy from startups. On the other hand, consumers enjoy supporting small businesses with small purchases, so I think it's always in you radvantage to be honest there.

Jason Cohen's post on this is good and he's far more knowledgable than I: [http://blog.asmartbear.com/convert-shortcomings-into- advanta...](http://blog.asmartbear.com/convert-shortcomings-into-advantages- without-lying.html)

<comment><AUTHOR> I have to find some early adopters then.

</comment></comment><comment><USER3> What do you gain from these lies?

What do you risk if you are exposed?</comment>


Facebook caught lying? - <AUTHOR> http://blog.arunbalan.in/2011/09/28/hey-facebook-ive-got-a-question-for-you/

<comment><USER2> It's something of a hopeless pipe dream, but what the internet really needs is an upgrade to the HTTP protocol to allow persistent connections like telnet. When HTTP was designed, they never imagined people would "log in" to sites, and as such, the protocol is horribly designed for doing so. Not defending Facebook here, but the problem is a symptom of that poor protocol design.

<comment><USER3> Excuse my French, but what does that have to do with anything?

The issue at hand is about Facebook not respecting your request to log out of their service. "Log out" means "I'm going away. Do not assume anyone on this computer is me anymore."

Facebook deliberately choose to ignore this convention, and continue to track users using various methods in order to gather more information for their purposes.

What Facebook _should_ have done was delete all Facebook cookies - end of story.

How _that_ is related to the pros and cons of HTTP is beyond me.

</comment></comment><comment><USER4> To avoid this kind of problems, we need better privacy features in web browsers: better control on accepting / rejecting cookies, blocking trackers, hiding information which is usable for browser fingerprinting, etc. Today, this is possible with extensions, but I think, it should be default in the future.

</comment><comment><USER5> tl;dr Facebook not caught lying.

</comment><comment><USER6> Facebook apparently knows that "these people used the same computer". This is not evidence of cookie-based tracking, though: they could just be using the IP address.

<comment><AUTHOR> IP address is not accurate enough to reliably ascertain such a thing. First, there's the problem of NAT. Second, there's the problem of dynamic IPs. My IP address changes everytime my modem is switched back off and switched back on. I'm sure a lot of other facebook users don't have static IPs as well.

Point I'm making: This data is important to them and they're recording it. They have an easy and reliable way to access this data through persistent cookies which they've - ahem - left on user clients by mistake. A lawyer would call that circumstantial evidence. Of course, I can't be fully sure of my accusation. Hence the question mark.

<comment><USER7> JoachimSchipper is right that it doesn't have to involve cookies, and so are you that IP addresses aren't enough.

Facebook could be using the same methods as Panopticlick (<http://panopticlick.eff.org/>), which are incredibly effective assuming the two users log in from the same browser.

</comment></comment></comment><comment><USER8> See also: <http://news.ycombinator.com/item?id=3062900></comment>


Get a dummy's-eye view of a suborbital ride on Jeff Bezos' Blue Origin spaceship - <AUTHOR> https://www.geekwire.com/2017/dummy-blue-origin/ <comment><USER2> IDIOT: "earth is flat!", YOU: play this video</comment>


IPv4 Address Report - <AUTHOR> http://www.potaroo.net/tools/ipv4/index.html

<comment><USER2> What really surprises me is that by this graph it really seems APNIC is better rationing its allocation the most of the other RIRs with it projecting still having small numbers of IPs available for crossover after 2020.

Part of this is that APNIC have limited all new applicants to a /22 when they hit a final /8 available. Existing registrants were offered an ADDITIONAL /22 as their final allocation, and due to successful hand-back of unused space, an additional /22 allocation is available for existing registrants.

It seems to ensure that small players (such as startups) can still enter the market and build a viable product without having to worry about it until they are using more the 1024 IPs.

<comment><USER3> APNIC is being fairly conservative with their final /8, but the big graph doesn't show the feeding frenzy that abruptly stopped in 2011:

[http://www.potaroo.net/tools/ipv4/fig27h.png](http://www.potaroo.net/tools/ipv4/fig27h.png)

Interestingly, the allocation rate has picked up again in the last month or so. I'm guessing that's related to the recent announcement about the "IANA IPv4 Recovered Address Space".

</comment></comment><comment><USER4> I find it very interesting how few /8s are actually advertised vs how many are handed out -- if those graphs are collect then the difference is a quarter of all the IPs???

</comment><comment><USER5> anyone knows of an up to date list of providers that offer ipv6 to end users?

<comment><USER6> See [http://ipv6-test.com/stats/](http://ipv6-test.com/stats/). You can filter the list by country to see results by ISP.

The data is collected from users that visit the site and take part in the test. Keep in mind that the data isn't conclusive as the end-users location, and his hardware, effects the providers offerings and the statistics.

</comment></comment><comment><USER7> I don't believe it. It's just like those "peak oil" people. We just need to drill more; we can find more IP addresses.

<comment><USER8> Only for a while.

Right now, ARIN IPv4 addresses are easier to get than ever before, as providers are handing out IPv4 addresses out like candy so that they have as much IPv4 space under their control as possible when ARIN runs out.

The next phase, as has already begun in the RIPE region, is where IPv4 addresses are bought and sold on the private market. Right now, they go for published rates of between $7-$15 per IP, depending on the size of the block they're sold as. This will probably go up dramatically once all the regional registries (and in particular ARIN) run out.

We'll probably then see the price of IPv4 addresses go up higher and higher, as utilization efficiency increases. It remains to be seen how high the costs will go, but it will probably get to a point where the costs of acquiring IPv4 will generally be higher than the costs of implementing IPv6. It will likely only be then that we see wholesale adoption of IPv6. Large portions of the Internet may begin using it before then, but the problem is that IPv4 will continue to be necessary until the whole of the Internet is on IPv6.

<comment><USER9> But IP addresses aren't really fungible, are they? What's the smallest block you could actually transfer to someone in another part of the world?

<comment><USER8> Generally, a /24 is the smallest block for which most networks will accept BGP advertisements. You'd generally purchase a /22-/20 or larger though. Note that in most cases, these are (part of) blocks that were assigned before the current regional registries existed, as blocks allocated through the registries aren't actually owned.

</comment></comment></comment></comment><comment><USER10> Yes migration to IPv6 is essential, but virtual hosting for websites and NAT for ISP subscribers provides a way to indefinitely postpone IPmageddon. This never seems to be mentioned. Also once a block is assigned the actual usage is unpredictable and not reported on that I'm aware of - I know several folks who have blocks assigned by their DC and they're only using a fraction.

<comment><USER11> So far as I can tell NAT for ISPs is brought up pretty much every time that IPv6 is mentioned on HN.

And every time people point out that it breaks the fundamentally decentralised nature of the internet and makes it harder to run P2P services.

And also, pretty much every time someone mentions unused blocks, and someone else points out that even if we reclaimed the largest known blocks that aren't publicly routed this would only expand the timeline for a few months.

<comment><USER12> >it breaks the fundamentally decentralised nature of the internet and makes it harder to run P2P services

Well, those are two things ISPs don't care about...

<comment><USER13> Running a box that smoothly maintains hundreds of millions of sessions (a household might would peak at about 1000 concurrent sessions) is a different expense than running boxes that just statelessly route the packets for those hundreds of millions of sessions.

<comment><USER3> You actually don't need state to share an IPv4 address, if you statically allocate port ranges to customers, and route packets based on the address+port.

But rather than build special routers that understand port ranges, it makes more sense to map each address+port into an IPv6 prefix, and use standard IPv6 routing. That's the basis of MAP:

[http://en.wikipedia.org/wiki/Mapping_of_Address_and_Port](http://en.wikipedia.org/wiki/Mapping_of_Address_and_Port)

Of course, the scheme is useless if you don't have an IPv6 network in the first place.

<comment><USER13> Oh, indeed! The basic argument is "keeping state is more expensive and fragile than not keeping it".

BTW, speaking of MAP: the CPE-side code is now in OpenWRT trunk.

I have built a few images here, in case someone is interested to test: [http://stdio.be/blog/2014-06-10-OpenWRT-MAP-images-from- pure...](http://stdio.be/blog/2014-06-10-OpenWRT-MAP-images-from-pure-trunk/)

(Needless to say, would love to hear feedback)</comment></comment></comment></comment></comment></comment>


Opera acquires e-mail service Fastmail.fm - <AUTHOR> http://blog.fastmail.fm/2010/04/30/fastmail-fm-has-been-acquired-by-opera-software/

<comment><USER2> I'm one of the main developers and was one of the (now previous) owners of Fastmail.

Fastmail has always been a small company, there are just 3-4 main developers (myself, Bron, Richard and recently in the last year, Kurian), and a couple of support staff scattered around world. For that small size, I think we've managed to build a pretty great product with lots of niche and power features, loyal users, and apart from a small disaster in 2006 (2-3 day outage for a big chunk of users), we've also been incredibly reliable, especially in recent years.

<http://www.pingdom.com/reports/lzdx4pr0pdhk/> <http://www.fastmail.fm/help/overview_reliability.html>

Fastmail was nicely profitable, but not spectacularly so. We're basically all geeks, and we don't have a marketing or sales department that can grow our customer base significantly (we tried, but it didn't work out, and we probably should have put more effort in, but didn't... because we probably preferred to spend time just building neat stuff, or fixing that edge case bug, or doing that fun thing... like I said, geeks).

I think we had to face facts a bit, we were a small fish with limited resources in a market that has become severely more competitive in recent years. We needed to invest a bunch of time and money in updating our interface, and adding new features (especially better mobile syncing).

And coincidentally, it's around that time that Opera came along and started talking to us. Despite being half a world apart, there's a lot of fit between the companies. They use a lot of perl, we do to. They're a company run by technology people, creating a product that's loved by geeks, is highly customisable, has a loyal fan base, and despite it's small size, punches above it's weight. I think that describes us pretty much as well.

So the timing was right, and Opera have an interest in picking up email as a core competency, and a bunch of ideas on what they want to improve, what they want to build. The other Fastmail guys were also interested in new opportunities, and we're all becoming Opera staff and are committed to working there for a few years at least. There's already plans for some staff to move to Norway to work, a change of life after 5 years of just 3 of us in a single office (apparently the Norwegian lessons are paying off... Jeg vil gjerne et øl til)

So it'll be an interesting change, and something new I'm looking forward to. I've been working for Fastmail for 10 years now. It's been a great time. I've loved building the product and the company. Like anything, there's been ups (it's fun developing a site that customers really love and tell you about) and downs (some people are addicted to being able to access their email, and running a 24/7 email service means that if people can't get to their email for even just 1 minute, you'll start hearing about it). After 10 years, it'll be strange having a boss again. I've met a bunch of the Opera people, and it'll be really great working with them. I know the other staff are looking forward to it as well.

It'll also be great to have Neil on board as well. He worked for us over a couple of summers, and basically designed the entire "new" web interface, all the HTML, CSS and JS. We've already got 80% of a whole new AJAX interface done (remember in programming though, the first 80% takes 80% of the time, the remaining 20% takes the other 80% of the time), and I'm looking forward to completely finishing that off, and working on a bunch of new stuff.

Hmmm, this story went on longer than I expected. Hope it's interesting to someone...

<comment><AUTHOR> I too hope you've done well out of the deal. I've been a paying Fastmail customer for ~7 years and am very happy with it. The 2006 downtime and a few other hiccups around the same time were annoying, but since then things have felt rock solid.

I find the spam filter better than the one in Gmail, so thanks to whoever's done the hard work with that.

And thank you for keeping the old web interface around, I prefer it over the newer one. There's nothing particularly wrong with the newer one, I'm just very used to the way the old one works and find it fast enough without AJAX enhancements. That you kept the old interface going is one of the reasons I stayed with Fastmail, if you'd forced a switch to the new one I'd have probably gone to Gmail.

</comment></comment><comment><USER3> They have a pretty good plan for a startup if you want to go without a mail server for some time.

For mails generated by user interaction, eg. "You have a new answer to your question.", they have the limit of 2000 per hour. Can cover you for the first 2.000 - 3.000 users. And mail from their servers don't trigger spam filters at Google, Hotmail etc.

I hope they keep the Business accounts running. Here's the features and pricing table:

<http://www.fastmail.fm/pages/fastmail/docs/pricingtbl.html>

</comment><comment><USER4> I'm not sure whether this is a good thing or not. On the optimistic side, it could mean a more resourceful entity with plenty of goodies coming in like more File Hosting space.

On the other hand, I've been using the paid Fastmail service for over 4 years now and one thing they did head and shoulders above the bigger players was their service and support. Plus they were always pretty geeky, making sure the expert user had lots of configuration options to tweak every possible thing. Their sieve filtering was perhaps the best out there and the old web interface rocks.

What I fear is Opera trying to make FM into a mass consumer product losing the technical edge and going for the more flashy features like online chats rather than putting in better sieve capabilities or something like better Pine/Alpine support. How I wish this doesn't kill FM (I've prepaid for 2 years more). I would hate to make a email service switch since that is my primary communication medium online.

<comment><USER5> I don't know if you've used Opera, but it's by far the geekiest/most customizable browser, IMO. Total remapping of all shortcuts, ability to reconstruct the interface however you like from primitive controls, built in support for content (ad) blocking and mouse gestures, user script (Greasemonkey, sorta) support also built in, etc. I've never used Fastmail, but as you describe it, they couldn't have picked a better browser to sell to.

<comment><USER4> I do use Opera as my primary browser since I've gotten used to it from the 5.x timeframe. And I do agree that they could not have chosen a better browser to sell to.

However, I'm wondering if it should have been sold at all, specifically to a company that makes browsers. Why not to a hosting company like Rackspace's acquisition of Mailtrust and perhaps more importantly, why sell at all if it was a pretty profitable entity.

Now this may be the founder's big exit and I sincerely congratulate them for it, however my concern lies about the consumer (me). I hope it all turns out for the best of everyone involved, but I do have my reservations till I actually see FM operating as well as, if not better, than the FM of old.

<comment><USER6> The founder hasn't been involved with the service for years. The people who actually ran the service are still running it, and will keep doing that as Opera employees.

Also: Opera doesn't just make browsers. Opera also makes all sorts of services for both users and b2b customers. The browser just ties it all together.

</comment></comment></comment></comment><comment><USER7> Is Operamail (<http://operamail.com/>) coming back? Those 3MB of storage were just awesome.

</comment><comment><USER8> Fastmail.fm was in my opinion the best free web mail solution available before Gmail came along.

<comment><USER9> I still use fastmail because I don't like Gmail...

<comment><USER10> I absolutely agree - unfortunately, Gmail doesn't work great for everyone.

</comment></comment></comment><comment><USER11> There is a large thread about this on emaildiscussions.com: [http://www.emaildiscussions.com/showthread.php?t=59311&p...](http://www.emaildiscussions.com/showthread.php?t=59311&page=9)

I am displeased that the FAQ doesn't mention any relevant privacy concerns, even though for many people the fact that FM was a small company with a good track record and privacy policy was an important reason to choose the service.

I also recognize the dismay of this comment:

 _\- 'FastMail's practical approach to user privacy has always been to be extremely protective of customer privacy'. ...or we may just sell your all of your data to a third party, giving you zero days notice or an option to cancel without refund._

I really wished they would have at least given us some time to figure out what we want to do.

<comment><USER6> There was no way to give people time to figure it out. The acquisition needed to remain a secret until actually carried out, and once it was carried out, this was the only way to inform people.

Also, Opera Software has an excellent privacy track record, and is located in Norway, which has some of the world's strictest privacy laws.

</comment></comment><comment><USER12> Sometimes I, a long time Opera user, just don't understand them. From outside it looks like they have hard time keeping focus.

<comment><USER6> No, Opera has a very clear focus. They are not only a browser company, but also provides browser related services. They make money off of those things. With this they can offer better email/messaging services to their business customers.

</comment></comment><comment><USER13> I've used Fastmail since 2001. Free or relatively cheap and IMAP was a winning combination.

I admit that once Gmail started offering IMAP support I started migrating over to Gmail, but I still use my fastmail accounts for other purposes.</comment>


VideoGamesPlus.ca hacked, 21,000 users' details stolen - <AUTHOR> http://www.eurogamer.net/articles/2012-01-18-videogamesplus-ca-hacked-21-000-users-details-stolen

<comment><AUTHOR> It looks like they were not hacked exactly. They just left some backups in the open: [http://www.google.com/search?q=site:videogamesplus.ca+inurl:...](http://www.google.com/search?q=site:videogamesplus.ca+inurl:customers)

Edit: wow, it was not only the customer database. It was _everything_ : <http://www.google.com/search?q=qbsm_export+filetype:sql></comment>


What Makes a Great Software Engineer? Just My Thoughts - <AUTHOR> http://elliot.land/what-makes-a-great-software-engineer <comment><USER3> Fewer lines of code don't always mean simpler code. Sometimes it means cleverer code (read: harder to understand and maintain). Three quotes I frequently repeat in this context:

1\. Duplication is better than the wrong abstraction

2\. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

3\. Code must be written for people to read, and only incidentally for machines to execute

<comment><AUTHOR> One of my biggest pet peeves is code duplication from lazy copy/pasting. I find it's a good exercise for myself to sometimes pretend like the copy/paste key are not available to me.

I had to think about the first one for a moment, but I do agree. It's better to abstract later with greater knowledge than the much more difficult task of trying to debug or fix it later.

It's an outstanding list and great rules to work by!

<comment><USER4> > I find it's a good exercise for myself to sometimes pretend like the > copy/paste key are not available to me.

This is a great idea! I'll try to remember this whenever I have the urge to lazily duplicate some code (which is quite often now that I think about it).

</comment></comment></comment><comment><USER5> I wrote on characteristics of a great software developer a while back.

[http://www.supercoders.com.au/blog/50characteristicsofagreat...](http://www.supercoders.com.au/blog/50characteristicsofagreatsoftwaredeveloper.shtml)

The problem is that people try to recruit for these things.

When recruiting, follows Joel's advice - smart and gets stuff done.

<comment><USER6> Probably the first time a see a list of 50 points in which I wouldn't object to any of them. Impressive.

<comment><USER7> How did you finish the list? I'm still processing the last two items.

</comment></comment></comment><comment><USER8> What do you most developers hate? Legacy systems!

Why? so difficult to change, poor documentation, no tests, etc.

A great software engineer, goes for simplicity but not in terms of laziness.

1\. They keep the system simple enough and decoupled in the right way so that it's easy to change!

2\. They have tests, not just unit tests, unit, functional, integration.

3\. They document everything, code docs, design docs, design decisions docs, data structures docs, how to build, how to debug, how to maintain and change, etc

4\. They do the really difficult stuff, they don't write the software for themselves, the develop for humans, customers. It's not about what you like, it's about what your customers like. This means having meeting and talking to others, getting feedbacks.

5\. They keep learning, but they don't jump and adopt every fancy new technology, they stick to well proven stacks, so they tend to be boring.

</comment><comment><USER9> I've heard people say laziness is important. However that is a misnomer, the reality is the best inventors and engineers are sort of long-term lazy. They will spend 40 hours building something to automate a thing you can do in 15 minutes. But, they know that they or others will push that button so many times the 40 hours will come back quickly over time.

An example of this is a strong senior engineer might take a lot of time laying the foundations of a project, the scaffolding needed to really make coding a breeze and enjoyable in the future. This is because they're lazy, they want the future to be easier so they invest today to make the future just a little bit easier.

<comment><USER10> Related XKCDs:

[https://xkcd.com/1205/](https://xkcd.com/1205/)

[https://xkcd.com/1319/](https://xkcd.com/1319/)

[https://xkcd.com/974/](https://xkcd.com/974/)

<comment><USER11> The mouseover text of that last one is very relevant to the discussion.

<comment><AUTHOR> Yep, here it is for everyone that doesn't want to waste a browser tab:

"I find that when someone's taking time to do something right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they're a master artisan of great foresight."

</comment></comment></comment></comment><comment><USER12> Good post. I think too that reducing code is key. Here is how I like to show it.

Let's see what impact "size of code" has on "time it takes to add a feature". Just consider a graph where the X axis is "size of code" and the Y axis is "time it takes to add a feature". Obviously, the function is increasing, and probably faster than linearly.

Let's see what impact "size of code" has on "number of bugs". Same thing.

Let's see what impact "size of code" has on "time it takes to find a bug". Same thing.

Let's see what impact "size of code" has on "time it takes to resolve a bug". Same thing.

Let's see what impact "size of code" has on "time it takes to refactor a piece of code". Same thing.

Let's see what impact "size of code" has on "time it takes to a newcomer to be productive on that codebase". Same thing.

And on and on and on.

There is two canonical points on those functions. The first canonical point is when the codebase is too big for the value it brings. When you are here, you are in deep trouble. Basically, the cost of doing anything in that codebase is too high in comparison of the value it brings. A sign you are here is when you spend more time in meetings discussing what to do, than time coding.

The second canonical point is when the codebase is notably small for the value it brings. When you are here, the project looks like magical. The programmers look like 10x programmers. Indeed, doing anything on the codebase costs surprisingly little in comparison of the value it brings. A sign you are here is when you are not asked for estimations.

<comment><AUTHOR> You should totally turn this into a xkcd-like comic ;)

</comment></comment><comment><USER13> Great list. One I would add would be understanding what the client's problem and building an appropriate solution. Too many times I've seen developers just dive in coding up the solution the client suggested without trying to understand the problem the client is trying to solve. For example, by adapting the problem to using an existing CMS or SAAS you can avoid a huge amount of custom coding.

A good developer would be able to write simple code for a given solution but a better developer would suggest a simpler solution leading to even simpler code.

<comment><USER14> This is exactly the thing that makes a person a "10x" developer. Being able to write lots of reliable code in a short amount of time is a good trait, but knowing when not to write code is equally important.

</comment></comment><comment><USER15> > 1\. Simplicity Reduces Code

I always follow the KISS principle, if possible. It makes maintainability so much easier, not only in Software but also in Hardware. Every additional layer of complexity adds to the probability of failure.

</comment><comment><USER16> There should not be long strings of commits that focus on features. Continuous development means continuously looking after developers, too: intersperse commits that remove code, increase documentation, update versions of dependencies, fix ancient bugs or whatever else eases maintenance.

Test suites should not just be thrown together, where every test is a "diff" of a giant log file! You do NOT want to be constantly fixing "tests" that "fail" due to trivial differences. Ensure that your code can _completely_ expose all _relevant_ state for one feature so that you can write precise checks and ignore any other output.

There should be no compile-time options (like #ifdef) that are not automatically built before every commit. Developers change things, and they have to know _exactly_ what can break by doing so (especially with languages like C++, where a tiny change can cause true chaos). Put another way, don't set yourself up to discover problems weeks from now at the worst possible moment; build defensive code and infrastructure.

</comment><comment><USER17> Great programmers write code that even bad programmers can understand. Bad programmers write code that _only_ great programmers can understand.

<comment><AUTHOR> That's great, I'm totally using that: [https://twitter.com/elliotchance/status/751926458658852864](https://twitter.com/elliotchance/status/751926458658852864). I couldn't find your twitter?

</comment></comment><comment><USER18> Nice, you drove home the point of simplicity in building software which largely occurs over time in the hands of a good software engineer. Do more with less code.

Coincidentally, I had similar views in this piece some time back.. [https://medium.com/@thallukrish/on- coding-e3c03771a369#.bb5k...](https://medium.com/@thallukrish/on- coding-e3c03771a369#.bb5kuf6zq)

<comment><AUTHOR> Cheers, great article. Left my own comment ;)

</comment></comment><comment><USER19> The unspoken subtext is, of course, "as simple as possible while still adding business value". For example, there may be external constraints (contracts, regulations) that require more convoluted code. There may be certain business situations where there just has to be complexity.

In these cases, we should strive to understand: * the complexity and the sources of it * how the complexity will change, and how much (as best we can, as predicting the future is hard) * what, if any, of that external complexity needs to be in the system we're building, and what can be pushed into human hands * how best to encapsulate that complexity so it doesn't spill over into parts of the system where it needn't be

It's all well and good to say "keep it simple", but that can be difficult when there are external forces that are saying "the system must do X when Y, A when B, and C when D, except when X. Oh, and if Y then C, except when A", etc,etc.

<comment><USER20> It's not just contracts and regulations.

Example: Bob the sales manager doesn't want to view reports through your handy web portal. Bob wants them formatted in Excel sheets, zipped, and emailed to his corporate Exchange account daily. Bob is the only person in the whole company who doesn't like your portal, but he is powerful enough that his whims automatically become mission critical requirements. You either give Bob what he wants, messing up your clean design to implement functionality _just for Bob_ , or you have failed to meet the business's needs and will lose the contract, end of story.

</comment></comment><comment><USER21> Being able to step outside software engineering when engineering software.

<comment><USER22> Yeah! This.

'Perspective' ...

Mini perspective: step away from the desk, do something literally creative. I play my guitar.

Major perspective: get the hell out of the city, actually do something on a weekend. Come back - all of a sudden you have fresh eyes and see things more clearly.

I actually think that soft devs should take more vacation.

You know that professional concert musicians only practice a few hours a day - any more is pointless. You just can't concentrate that long.

A really gutsy move would be for Google to give a bunch of 'long weekends' where nobody can work, or even more vacation. And see what the results are.

<comment><AUTHOR> Fresh eyes on the problem is always good, usually after lunch or you have slept on it.

I find when my brain starts to grind to a halt I just go an do another un- related task to force myself to completely forget about the original task. It does help because when I go back to the original task my brain has to context- switch back into it and in doing so it may look at the problem a different way.

Extra holidays would be great! However, I think more holidays would make some engineers more productive and some less productive... I'm not sure if Google is still doing their 20% time, and if they are I know it doesn't apply to all the FTE engineers.

</comment></comment></comment><comment><USER23> There is a fine line between short code and readability, which is, by far, one of the most important factors of code quality. Say you have a code:

      $this->executeAfter(5);

This is a short code, but it's not readable. What the hell is 5 here? Let's improve it a little bit.

      class Time {

        protected $seconds;

        private function __construct($seconds)
        {
          $this->seconds = $seconds;
        }

        public static function inSeconds($seconds)
        {
          return new self($seconds);
        }

      }

      $this->executeAfter(Time::inSeconds(5));

I've just added ~10 lines of code, but the readability of _executeAfter_ is way better. In addition, the _executeAfter_ method is more flexible, since it can manipulate the _Time_ object now.

This is a very basic example to illustrate what I meant when drawing a line between the short code and readability.

<comment><USER24> I believe you have missed the author's point - "Using more code is actually the lazy fix." The author would recommend something like:

        $this->executeAfter(5); // Execute after 5 seconds

The above code is only 1 line, and is very clear. It does not add a brand new, unnecessary class, nor does it increase the surface area for bugs (adding a new class opens up the potential for new bugs, while adding a comment does not).

<comment><USER23> This is not entirely true. It depends on the language, but the definition of _executeAfter_ for the most of dynamic languages would be something like

      public function executeAfter($seconds)

This code does not guarantee that the value of $seconds is _correct_ , whereas this:

      public function executeAfter(Time $time)

...will help engineer to not make silly mistakes.

It definitely depends on the language, but I personally like self-explanatory code and tend to think that inlined comments should only describe things that require explanation, such as complex logic.

</comment></comment></comment><comment><USER25> Great write up. One of the challenges is definitely finding a system that recruiters can use to prioritize these things.

<comment><AUTHOR> I'm generally not a fan of recruiters simply because the vast majority of them are sales people first, and tech people second (or often no technical experience at all). Compounded by the fact some people interview very badly but are good engineers and visa-vera.

Even if you have experienced engineers doing the screening process (separate from the company being applied for) I still think it would be challenging because theres no "correct" way for a team to work and companies are so vastly different.

It definitely is something to think about. If you do some up with something, let me know :)

</comment></comment><comment><USER26> Great article. I think you have hit on something here that only comes with a lot of experience and looking back and what really worked. I rarely see an article that I think YES. TOTALLY. Well done!

<comment><AUTHOR> Thank you for the kind words :)

</comment></comment><comment><USER27> Before you aim to become great by reducing your code please become competent in absolutely necessary basics: DRY, separation of concerns, basic patterns, security, etc.

<comment><AUTHOR> Yes and no. I think we read these things in textbooks and either don't truly understand why they exist until we've made the mistakes or we go too far the other way and start dictating best practice on to everything.

It's best to be be somewhere in between. It can only be learned by doing, not studying.

</comment></comment><comment><USER28> My thoughts conveying similar message from a different angle: [http://hakunin.com/cms-trap](http://hakunin.com/cms-trap) (for those who might've missed it when it got upvoted on HN 3 years ago).

</comment><comment><USER29> In my experience, laziness is one of the most important traits of a _good_ developer.

<comment><USER30> You have to be careful how you define 'lazy' in this case. Suppose a developer just quickly writes code that fixes the current problem, but doesn't care about the consequences long term, or doesn't fix the underlying problem - <USER2> good.

Now, if you define 'lazy' as someone who will go to great lenghts to not do boring tasks in the future, yes, I completly agree :)

<comment><AUTHOR> Spot on in my opinion ;)

</comment></comment></comment><comment><USER31> "The best engineer will write zero code" \- unfortunately, the author has forgotten to tell us what she does do.

<comment><AUTHOR> I'm a software engineer. If that's not clear from the article, you should be able to tell from the bio at the top and bottom of the page.

<comment><USER31> I'm sorry, I may have been ambiguous. I was actually wondering what the best engineer does.

</comment></comment></comment><comment><USER32> You probably want to the right thing

<comment><AUTHOR> Thanks, I've fix it up.

</comment></comment><comment><USER33> Autism.</comment>


Can the Right Kinds of Play Teach Self-Control? - <AUTHOR> http://www.nytimes.com/2009/09/27/magazine/27tools-t.html?hpw=&pagewanted=all <comment><USER2> _Dramatic play, he said, was the training ground where children learned to regulate themselves, to conquer their own unruly minds._

This makes intuitive sense. Dramatic acting is almost by definition doing what you think you should do, instead of what you want to do. Except for method acting, which instead tries to make it so what you want to do is what you should be doing.

I'd be interested to know if actors have better or worse self-control than non-actors, and if method actors have better or worse self-control than other types of actors.

</comment><comment><USER3> FTA: Especially these days, they contend, when children spend more time in front of screens and less time in unsupervised play, kids need careful adult guidance and instruction before they are able to play in a productive way.

Kids need adults to show them how to play? Holy crap, what are we coming to?

<comment><USER4> Indeed. Professionals want constant reassurance that it's OK for them to be paid to be constantly interfering with children's play.

"How to begin to educate a child. First rule, leave him alone. Second rule, leave him alone. Third rule, leave him alone. That is the whole beginning."

(D.H.Lawrence)

<comment><USER5> The ability of professional educators to turn what are valid and powerful observations about childhood development, such as this stuff about executive function, into stale, formulaic, and worst of all _ineffective_ teaching techniques never ceases to astound me.

It probably boils down to the problem that when trying to teach "children" as an amorphous mass, "formulaic" and "effective" are simply never going to go together. No matter how smart the formulator or how hard the formula-applier tries.

</comment></comment></comment><comment><USER6> _In some studies, self-regulation skills have been shown to predict academic achievement more reliably than I.Q. tests._

Observing an individual's ability to self-regulate works as a good predictor of character in all kinds of situations, interviews being one of the more useful applications. Although justifying your subject judgments to your colleagues could be tricky -> "He answered the concurrency questions better than average but kept slouching down into his chair - I don't think he's going to be able to meet deadlines".

<comment><USER7> Also consider reminding such colleagues that there is a definite, well confirmed negative correlation between conscientiousness and intelligence: [http://www.ist- world.org/ProjectDetails.aspx?ProjectId=74c83...](http://www.ist- world.org/ProjectDetails.aspx?ProjectId=74c831c7db5d4fd1835f7ad6a37411f8)

<comment><USER2> In the abstract of that paper, it says "the significant negative correlation could be observed only in groups with above average mental abilities and not in a random sample from a general population." Are there other papers that say there's a general negative correlation?</comment></comment></comment>


Chrome is blocking torrentz.eu - <AUTHOR> https://torrentz.eu/i

<comment><USER2> Which will ironically make people less secure, since some people will just disable Chrome's malware warning, or the at the very least learn to ignore the warnings.

And Torrent Freak provides actual information here: [https://torrentfreak.com/chrome-blocks-major-torrent- sites-o...](https://torrentfreak.com/chrome-blocks-major-torrent-sites-over- harmful-programs-150710/)

<comment><USER3> This random security site that I have not vetted at all says the site loads a file containing suspicious javascript "show_ads.js"

[http://www.quttera.com/detailed_report/torrentz.eu](http://www.quttera.com/detailed_report/torrentz.eu)

<comment><USER4> Kinda makes sense, as all ads are suspicious at the bare minimum.

</comment></comment></comment><comment><USER5> Considering the number of "Download" buttons on torrent sites, I wouldn't be surprised at all of some of them led to an .exe file. And the updates hint that the issue is slowly being resolved.

Nothing to worry about.

</comment><comment><USER6> Same with [https://kat.cr/](https://kat.cr/)

Though I assume this is a hiccup.

</comment><comment><USER7> not blocking for me</comment>