sinatra

> Go supports green threads (goroutines)

As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.

Please please keep it. It's not perfect (comment text still small, buttons & links are small, etc), but it's much better than before.

There are surely hundreds of web designers who'd be more than happy to submit their proposals for fixing the mobile markup for free. It's disappointing to see that the website that I spend the most time on on my phone still didn't have a mobile markup till today. Thank you for doing this. Now, please let's move forward, not backward.

I feel bringing concurrency to Ruby (what Rubinius is trying to do) is going to be harder than bringing Ruby to concurrency (what Elixir is trying to do). Adding Ruby-like syntax on top of fundamentals like functional programming, immutability, etc (which are naturally suited for concurrency) sounds like a better approach to me. Would love to hear others' opinion.

> While the part of Europe I come from is completely white for various reasons, nobody really cares about race.

Maybe because in a homogeneous society, there's no reason to talk about race.

> Then you come to the US and it's all about race race race and more race.

Maybe because unlike the parts in Europe that you mentioned (which were completely white), there are different races here.

> You are born with your race and you can't change it. You are born with your class, but you can change it. Focus on that part.

People here are NOT discussing race because they want to change their races. They are discussing race because just like sexism, homophobia, etc, racism against anyone (even if they're doing well professionally) is something to highlight, acknowledge and work towards getting rid of.

I'll certainly want to be in a country that actively talks about race than a country that doesn't. If you think not talking about race means there's no or less racism in Europe, then just look at soccer / football.

My favorite: are you really aiming to become a glorified consumer gimmicks firm?

Yes, just using built-in packages, and not depending on too many third-party packages is definitely attractive to me. The code full of "if err != nil" is an issue that I've also noticed. However, I'm hopeful that this may actually remind me to be more exhaustive in error handling.

Why did you mention the container? How kind of benefits would you be getting from a container for Go?

Thanks! The point about immutability is important. Based on the comments I've been seeing on HN, I had a feeling that Docker brings its own set of problems. But, it may be worth checking it out.

> I think Elixir has good library support too.

I guess the support will be even better if you consider using Erlang libraries.

This is a good place to ask this (because Go posts attract a lot of commenters, even those who dislike Go and like some other language):

Which language/framework would you choose today for writing WebServices? Preferably with the following characteristics: static type (or at least static analysis), easy deployment (ex, generates a single binary like in Go), supports concurrency very well, is small/simple, has good tooling and debug support, and is fun to write. Go (except for good debug support)? Elixir (dunno how good it is with deployment and debugging)?

I'd imagine transferring H1B to your own company will have the same issues that applying H1B for your own company will.

Considering H1B visa only allows you to work for the company that sponsored your visa, what you're describing sounds illegal, not just a loophole. I'm not saying they shouldn't do so. And I'm also not saying anything about whether the H1B requirements make any sense. I'm just saying that hopefully they're aware that what they're doing is illegal and may hurt their companies at any moment.

After 10-15 years of incremental improvements in web & mobile apps, I have started feeling that technology has finally started to try to solve real problems. General purpose robots, self driving cars, internet of things, virtual / augmented reality, etc are all very interesting! The kinds of things that people in 70s & 80s would think we'd have in 2010s. I'm getting excited about future again!

As long as you understand that when that site gets compromised, all other sites where you use your standard password get compromised for you as well. Collectively, all those sites getting compromised for you may be enough of a reason to consider password managers.

Not necessarily. I don't go from zero to product till I have verified that there's a need for the product. I try to fail fast before developing the product. By the time I'm developing the product, I'm fairly certain it's not going to fail immediately after launch. Oh, and once you've built a product that people are using and you're going after growth, you would rarely get a chance to switch languages or frameworks. So, then, you're stuck with the language that you don't even like anymore for many years.

I think you're also over-estimating the time required to learn a new language to be good enough for most startups. I understand that there are some areas where language mastery will be tremendous benefit. In that case, I agree that switching languages may not be such a good idea. But, that's a special case, IMHO.

> Picking a shitty, slow language, as long as it's a popular one (JavaScript, Java, C#, PHP, Python), is going to have a much better cost/benefit profile.

Although, keep in mind that a startup is going to be a roller coaster ride for years. You'll have days when you get tired of writing financial models for investors, or when an angry email from a customer ruins your mood, or you hit a road-block with a UI that just doesn't feel right. You'll want to take a break from all that by going back to just writing code for a day or two. At that point, you will want to get pleasure out coding. I'll be very unhappy if after those kind of days, I try to find solace in coding, and I see PHP, JavaScript or Java staring back at me.

Compared to the years it takes to turn a startup successful, the time needed to learn a new language well enough is negligible. I knew just basic Ruby when I switched to Ruby + Sinatra from Java for my new startup. Now, three years later, I can't be happier I made the switch.

IMHO the main reasons compared to, say Ruby, would be: native support for concurrency, Erlang VM, fault tolerance and speed. However, I'm also disappointed that there's no type checking. EDIT: Although I don't agree with the comment below, I'm removing comment about Golang because it's unnecessary in the discussion about Elixir.

I remember reading somewhere that 44% people think ads don't work on them.

I think slightly differently. I don't think I import enough packages for "save file after first usage" to become a deal breaker.

Yes I do use goimports. Also very useful.

I've been using vim-go for about one year now. The combination of vim-go, gofmt and YouCompleteMe is all you need for a perfect Go setup. Thanks to Fatih and Val!

Thanks! I also disabled the plugin. As 1Password asks for my password every few hours anyway (I lock the screen every time I leave the desk), hopefully it won't be as inconvenient as I originally thought.

Yeah, I'm aware of some of those security issues (I understand that it can't help me if I am targeted. But, I may be safe in broad hack attempts). However, I just don't have any solution that has the convenience & stability of Dropbox + encfs. What do you use for syncing docs securely?

Yeah, the keychain is obviously encrypted, but I still feel uneasy about it being naked on Dropbox. The reason I'm leaning towards using encfs + Dropbox vs iCloud is that although I definitely trust Apple more with my data (compared to Dropbox), I feel that an encryption controlled by me at client side will be safer.

I use 1Password. To my non-security-expert eyes, the two weakest spots in how I use 1Password are: (a) The plugin I use on the browser, (b) The fact that I use Dropbox to sync the password keychain.

I can maybe move the keychain to an encfs encrypted folder in Dropbox. Then, I won't be able to use 1Password mobile app. And for the plugin, perhaps I can disable the plugin and copy-paste the password directly from the app.

Would love to get others' feedback. UPDATE: It appears I can combine sync through encfs folder and manual sync through phone to achieve sync on all devices.

Did anyone else here have this issue with Dropbox & Finder in Yosemite where newly added files in Dropbox show up in terminal, but not in Finder. And to force finder to refresh, you need to use a workaround like creating a temporary folder and deleting it? [1]

If you did, then do you still see this issue in El Capitan? I may be willing to upgrade to the GM if this issues gets resolved.

[1] https://www.dropboxforum.com/hc/en-us/community/posts/201166...

If you trust Google, you can consider https://domains.google.com/registrar too. It's fairly straight-forward, no nickel and dime, you get private registration for free, and I am quite confident that it'll be hard for someone to use social engineering to steal my domain from there.

I've heard that AM didn't verify. And I'd say many shady websites won't.

I actually thought about something slightly related -- With the AM drama, won't an individual have a reason to signup to all shady websites with their worst enemey's email address and then wait for one of those sites to get similarly hacked? Would some people have created AM profiles of others just as a joke, and now those people might be in trouble?

I once found a dating profile of mine that was created by an overzealous relative. Thankfully this was few years before I met my spouse.

"every SQL script file must be immutable after it is deployed to production or staging environment."

git doesn't support locking files. Then, what is the best way to meet this immutability requirement?

The examples you gave (DB, JSON, etc) are big enough that there would be decent support for those in Rust. But, your concern is definitely valid for more niche requirements. If your primary concern is availability, stability, maturity etc of a language's ecosystem, then IMHO, you should not choose a language as new as Rust. Rust is currently in the "early adopter" phase, and it is going to go through the same issues (and excitement) that most early adopters do in any field.

Wait, Google doesn't support iOS devices (whereas, this announcement is specifically about iOS), right?