skysight-inc/HackerNews huggingface dataset:
Summary:

A Javascript developer that have been using it for client-side purpose will not learn how to use nodejs from the day to night even if he is a expert on it, for something nodejs is for serverside programing.

"Front-end and back-end can be written in the same language.". I would prefer to right my backend in something else instead Javscript , even PHP would be a more pleasant choice, and if that would be the case i would rather use Clojure and Clojurescript togather to right everything in the same language.
Watch out for patents in the US. I worked on a similar MVP for a client a few years ago and he did some patent research and did not move forward because of what he found.
Great job with the site, it looks very clean!
What's wrong with Python? I've messed with all 3 you listed but at the end of the day I always end up going with Python.
With the persistent difficulties the middle and lower class have faced since the financial meltdown I wonder how long this will be the dominant mindset. It seems strongest among the boomers and weakest among people under 35.

That fact that most Americans seem to put the welfare business and the rich ahead of themselves is hard for me to get my head around.
A problem with trucks as the leading-edge is that they're already a bit alien to the public and policymakers: resented in traffic, feared out of proportion to actual risks, underappreciated as some narrow corporate/union interest. If they're the test case, enthusiasm will be lower, regulation more costly/cautious, and the public vaguely suspicious, primed to assume the worst when anything goes wrong.
The U.S. Postal Service has lost more than 5 billion dollars over the past year.
You need to explain traffic spikes and lulls, because right now your argument looks ridiculous.
Use whatever is best for you... PHP can scale... I've built applications that handled 4x as much visitors per day as you mentioned without any real problems... Crappy code is in every language, it's all on you... You can build amazing things in PHP... Just like you can in Node.js and Ruby, and Python...

If you want to build it quickly, do it in what you know best... If you want to learn a new language as you go, build it in Node.js or Go.
Noticed a minor bug: clicking "sign up and write" and then the "X" on the popup still has the spinner going on the signup button
Unless you know you can't use what you know, stick with what you know. Business concerns trump technical concerns for early-stage startups, and the differences between the three are minute as far as business is concerned. However, having to struggle with learning a new stack can impact your business.

Even if the differences between node.js and Go mattered, you won't get anything valuable from asking HN "should I use node.js or Go", since the two stacks are broadly in a similar niche and have similarly-sized communities. It'll mostly be fans of one technology bashing the other, as you can already see in this thread. It would be better to focus on specific concerns: Do you need support for shared memory on multicore? Is the ability to reuse JavaScript code on the browser and the server a concern? Is there a specific library that's essential to your business that's only available on one or the other? These questions would engender a much more interesting discussion.
They must have some idea of 'appropriate' devices, no? For instance, I'm wondering about a mini pcie gsm modems for laptops.
You're assuming that all the visits are evenly distributed over the day. I doubt that assumption will hold...
Exactly what I thought. There is an awful lot of damage a semi-truck can do if things go wrong. But, then I realized, that there is not necessarily a need for the "trucks" to be big. Maybe you could go the Roomba route, and make them much smaller than traditional trucks, maybe even smaller than conventional cars. Since no driver is needed, you can scale out with many of them, rather than having one very large truck. Maybe that approach does not work for everything, but somehow I think having a large bunch of cargo ants is much less risky than a single very large cargo elephant.
PHP.

You want to start with something you know, especially at a time when getting an MVP, making iterations, and being nimble is important. Because you both already know PHP, this is a no-brainer. Things have changed dramatically with every aspect of web development in the past 6 years, and PHP is the thing that (although its changed a lot) has probably changed the least compared to your web front-end (HTML5/CSS3), client-side JS, and responsive design (which basically didn't exist 6 years ago).

You should also consider the economics of your situation. Developers who know enough about Go and Node.js to do it professionally are going to charge you much more than those who code PHP professionally.

Ultimately, you're probably doomed to failure just by raising this question. Its been stated ad nauseam on HN before, but you need to iterate quickly and discover what works and drives traffic/sales. Don't waste time trying to learn a new programming language. If you want to devote any time to learning something new, it should be learning how to market your product better.
How will training the public that Scientists are money-grubbing hucksters who are full of crap help the matter any?

Also: It just might teach the public to actually take agency over who gets funded and encourage them to decide for themselves who is or isn't a huckster.

Incidentially, I am trying to cure cancer, and I've set up a nonprofit to do so... And am considering writing an piece explaining why you shouldn't donate to me. (if you can't take the risk of failure, etc.) What do you think? Although I'm being genuine, is it too humblebraggey?
I think it's really important to talk about what Science is. It gets bandied about like it's this abstract idea when, in fact, it is a real process that is taking place. A good definition of Science is humanity's current working knowledge of reality based on the process of lots of people utilizing the Scientific method to test hypotheses. I think that's fair definition. On examination of this definition you will notice it has a large human component.

Science is like the stock market. It's lots of people spit-balling about what's happening in the market (in Science's case, the market is "ideas about reality"). In the short term Science can look really ugly, just like the stock market can, in the long term, however, we'd like to think of it as an accurate weighing machine.

I generally think this is a fair assessment, but as I get older and start to see how few people there are who aren't willing to cut corners to get ahead. This worries me, because, like the stock market, Science affects real peoples lives. It's all well and good that over the course of 100 years the Dow Jones will outperform cash or, really, any other investments, but that's of little use to the real people who get left behind in periods of great economic stagnation. Science can go through similar periods of stagnation, and currently, it seems like we might have hit upon one.

It is possible to criticize the current way we have set up the Scientific endeavor without criticizing the abstract notion that human beings will generally discover new things over the long term. I think it is hardly controversial to say that our current way of doing things is not the best, but it may even be bad. Money and time are corrupting factors. Postings that used to require a PhD require a post-doc, positions that required a post-doc, now require two. The immense pressure of publish-or-perish is becoming greater and greater and room for failure, which is an essential part of the Scientific method, is being squeezed out. This is not a good thing and, I think, is a larger reason, among others, why Science is becoming noisier and noisier. When the stock market becomes noisy it benefits insiders, but hardly anybody else. I think Science is, currently, in a similar place, it's efficacy is being diminished by crap.
That is quite a pessimistic assessment but I have to say I agree with it. I have been watching American politics closely for several years now and have little hope that any significant solutions the the widening income/wealth gap will come from there.
Moving from Ubuntu to Debian
yeah, oops.
Depends on what you want to do. But I can tell you that this is sort of a pointless argument for a blogging platform

I've found that the really important bit when writing read-heavy web-apps is good caching. The write-path could be written in something slow-ish and it will be hit far less than the front-caches serving data.

So, if you need a web templating language + basic json callbacks, php will definitely do the trick for version 1.0 (or ruby-on-rails or whatever gets you up to 100% feature complete). I've written game backends which did ~2.5k-3k rps on a single machine with PHP (though, I did have to fix PHP APC's locks to handle those loads in the process).

But then you still need to know JS to write the frontend code.

Node.js basically lets you combine 2 skill sets into one - the frontend and backend can share the same data model code for instance. This is easy if you have complex data-structures to communicate between the two layers.

Go actually gives up that advantage, but wins out because it can do compute intensive tasks faster - and can do state-ful daemons in a much nicer way. If you were building say, an online game, where say it was poker game with low-latencies, I would go for go. Definitely.

But as it stands, the only reason to go for Node.js is that your front-end dev can double as a backend-dev. Otherwise, I'd stick with what you know & are most productive in.
If The Internet Is Your Canvas, You Paint In Zeros And Ones
So, clearly, I'm not 'an adequate javascript developer'.

Luckily an inadequate javascript developer can write naive code in Go that reads from disk or writes to a socket without worrying about needing "a class which you pass methods to your callback functions and bind them to the instance properly" or "prototypical inheritance".

You can just call a function and use the result.
We have a server that we've deployed for our customers. It's a middleware-free web platform. It won't be released officially for some time but we'd be happy to have you evaluate it.
ELB, CloudFront, SQS, SES ... it’s nice to have those things at your disposal even though alternatives exist. Consolidated billing, fewer accounts to log into (admin overhead) etc.
node's error handling is by far its weakest point IMO, Go is a lot better in that respect, but a full javascript stack has its advantages
Hello XorNot,

I remember having read some papers regarding the modification of InkJet Systems for combinatorial chemistry. But papers are always one thing, out-of-ivory-tower application another.

Do you have any contact details? I could not find them in your profile.
Driverless trucks is a real opportunity that could save a lot of money in shipping.

But it could be exploited. If a person walks out in front of a truck, the automated truck better stop. Which an unguarded truck would become easy to rob with little risk. A flat tire would mean the truck calls in for help and is stranded defenseless on the side of the road. That said a fair amount of loss could probably be absorbed with the savings.

I expect long haul truck drivers instead to turn into truck captains. They're present but not for the driving. The truck can drive through the night while they sleep. The captain will handle weigh-ins, emergencies and other road tasks.
Iris, a ready-to-fly UAV quadcopter
This is the best answer. You can scale any language to 100k pageviews/day. Some scale easier than others, but almost anything reasonable will hit those numbers with the proper infrastructure.

New languages and frameworks have their pitfalls. Pick what you know so that you don't get tangled up in the weeds while trying to build out a product quickly.
Go is a better language than PHP. Much better. It also compiles to machine code, and has excellent multi-thread facilities (goroutines) that boost performance and also make coding simpler (Not more complex!).

But you might find coming up to date on PHP easier, since you already know an old version of it.

There are many more coders available for PHP than Go. But Go programmers on average are higher in quality because the drudges and blubs don't bother learning new languages.

Recently one of my hosting providers sent me a notice that my account was being transitioned to a new version of PHP. That can't happen with a compiled language like Go, since the none of the language itself goes up on the website, only the executable program binary.

I don't know much about Node.js...
I still don't understand why people ask this question. It's exactly like you say. The technology stack does not really matter. All that matters is how productive you are in the initial phase.

You should always be choosing something you are familiar with, because it will allow you to get where you want much quicker. And yes, later, then you do actually build a business, you can start playing around with newer technologies. But only if they are valuable for the business.
> One had over $250,000 in sales in 18 months before I sold rights to it for another $90,000 to another company.

For anyone interested, I'm guessing this is it...

http://flippa.com/blog/dan-grossman-on-selling-wpreviewsite-...
The book says that the source code of the exercises is available on their website, however the website doesn't appear to exist anymore. Is there an official location where that can be found? Same with the solutions - it says they are available electronically.
SharpPLM (document and quote management for small/med manufacturing companies) is still pretty early but I make $200/month. I feel like I am still figuring out product/market fit.
What a truly fatuous and obnoxious comment. You've managed to hit most of the HN bullshit argument dog-whistles: accusing people of being shills, invoking Aaron Swartz, arguing on behalf of "hackers", speaking for the rest of the site, and accusing the person you're debating of dishonesty. And you managed to do it in an argument about software licensing. Well played.
I think of it as paying a little extra to outsource the boring parts of my job to Google. I don't worry about sharding, load balancing, replication, ...etc. I've done those in the past, and it wasn't that exciting. I like spending my time on code, and it lets me build things faster.

App Engine has it's disadvantages as well. At one point I used typhoonae (open source framework that let's you run you GAE apps on EC2) and was about to switch, and then decided against it.
It depend on what kind of online service you want create.

I think you will get 100 postings where 100 people try to convince you from their favorite language.
Write it in PHP to start. If it takes off, hire a bunch of devs and rewrite it in Go. I say this as someone who hates PHP and generally likes Go and Javascript.

The biggest question in your business model is not "How do I scale this?" or even "What technology should I use?", but "Will this take off?" If the answer to that is yes, you will have resources to deal with the problems of how to scale it, and you will have more information to answer the question of what technology to use. (In particular, you'll know what your developers want to use; you can give them an ownership stake in the technology decision - which should really be their decision, not yours; you will know exactly what feature set you need to implement and what sort of loads you'll bear; and additional libraries or technologies may have come out in the meantime.)

Usually the biggest factor in development time is how well you know the technologies you're using, not any intrinsic level of productivity with the tools. Different technologies will top out at different levels, and IMHO Go tops out significantly higher than Node.js, which tops out significantly higher than PHP (and at least in the early stages, Python tops out higher than Go). But if your goal is to found a successful company and you know what idea you want to pursue, you are better off investing the time in proving out your business idea than in learning the perfect new technology. (If you don't have a concrete idea, investing in learning a new technology is a pretty good way to pass the time until you do.)
This story is one of the big reasons LA (despite the weather) is not a great place to live. It has been unwalkable with a few exceptions. Though public transit is being slowly rebuilt from destruction, talk to most Angelenos and they don't even know there is a subway, much less use it.

Also, there is a certain segment of the population that fights denser development that would encourage transit improvements. I don't really understand why such a person would live in Hollywood, for example.
If they had designed the win32 PE .exe format differently, they could have included a 16bit NE stub to throw up a messagebox with the message - in the same way the .exe files already include a 16bit MS-DOS MZ .exe stub with an equivalent message.
He's not referring to a strike, but to politics.
If you count on 100k visitors per day, it doesn't really matter which one you choose. We are serving well over 10M page views daily and we don't see a reason to switch away from PHP yet.

The only reason I see you might want to go with Node or Go is if you want to attract developers who like to work with latest technologies. If you want to do the first version yourself, then choose the one you are most comfortable with. When you need to scale (from technical and resource perspective), make sure to analyse all aspects of it before going into one direction.
How long would the streetcar have taken vs the time to travel via manhattan on the subway? (Londoner here so trying to put it in context).
You know PHP, so use PHP. There's going to be a mountain of business challenges between 0 and 100K daily visitors - free up your mental bandwidth for that.

Also, something as read-heavy as a blog is well suited for something like Varnish (https://www.varnish-cache.org/). Regardless of the backend technology you choose, a caching http proxy (or whatever) should be absorbing most of the traffic.
And for people saying $7K/person pales in comparison to the Swiss $36K/person, remember to consider that people who make a lot more would get a lot of their $7K taxed away anyway - so it's probably closer to an effective $15K-25K a year considering this.
Startup lets you own a piece of the world
The Chinese are in love with Bitcoin, and driving its price high.
Updating Confluence and Jira is a nightmare and keeps you hunting for solutions
I made the post on Facebook and am somewhat confused why it has appeared on HN.

This is extremely unscientific, so I would not recommend making any conclusions based on it.

...but if there's interest, I'll improve the data and write up a blog post.
> request objects aren't stored in python's thread local storage. If they were, a thread re-use will leak context local.

No more so than werkzeug since it works the same way.

> Werkzeug uses the thread/greenlet id as key in its storage

Which is exactly how Python's threadlocals work.

> and cleans up when the request completes.

You do realize that nothing stops you from "cleaning up" your threadlocal "when the request completes" right? Yes werkzeug's locals and localmanagers conveniently provide hooks for that cleanup, but that's what it is: convenient. The primary purpose and the one explicitly mentioned in werkzeug's own documentation is having a single system for both greenlets and threads (the stdlib's threading.local obviously doesn't work with greenlets, just as werkzeug's locals don't work with non-greenlet coroutines)

> In a single threaded server, the context locals won't leak from one request to another. If they were global, they would.

Not if you cleaned them up after the request has executed. And apparently that's all you need to make a global variable not-global-after-all.

> I don't see how request object has anything to do with global variables.

It's an object available from all scopes. That's pretty much the definition of a global variable.
If one were to analyze this concretely instead of with a bunch of platitudes, you want to find the optimal intersection between the productivity a language grants you for the task you are trying to accomplish, the amount of developer time required to maintain it, and the hardware required to support it.

1) Productivity - The speed at which you can create a respectable prototype. This is not just a matter of your team having mastered the language -- some languages are more specialized than others. For example, it will be orders of a magnitude easier (i.e. will require less dev time) to build a distributed system in a language with built-in actor support (i.e. Go, Scala, Erlang, etc.) than it would be to do so in say, PHP.

2) Maintainability (in terms of dev time) - The languages and its predominant frameworks will dictate how difficult it is to maintain a codebase. For example, many programmers will attest that statically typed codebases are easier to grok and maintain than dynamically typed. Dynamically typed code requires more edge case testing, and statically typed code allows an entire class of bugs to be compiled at runtime.

3) Hardware - Languages have different performance characteristics. Some languages will require $x / unit of web traffic. Others will require $y / unit. This translates into the # of servers required to support your app, which may diverge at a polynomial rate or worse over time. This is unlikely to be a big factor in the early goings, but it can matter a lot when / if you achieve success, so can be a worthy tiebreaker -- because it is highly unlikely you will be switching languages entirely once your company is in the groove, so the choice you make early on will stay with your company for a lifetime.
I've done a couple projects with Go now and really like it, but it does have a big weakness as far as backend -- models and and the tools to make a good model abstraction layer. This may be a personal opinion problem, so I'd like to hear what other people think of it. I personally find the tools for interacting with datastores particularly weak. Their sql package for example was way too simple for me.

I've heard good things about the mongodb package and interface, but I haven't had a reason to use mongo.

So really if you use Go for your server side, you'll get a lot of nice benefits, listed by sambeau, but just be aware, you might have to tussle to find the right fit of backend tools, and you will likely have to make your own Model abstraction. This might not be a downside though, as I know a lot of engineers will build (or rebuild) the model layer no matter the framework.
Except Brooklyn and Queens are not the suburbs.
PHP is such a poor technology, however many great websites were build using it, so I would say that you should go with technology you know best.

PHP will rather never be a bottleneck itself, you can fuck up many other things like data storage. All modern data storage solutions come with PHP interface.
Bitcoin is back near its all time peak price