m0th87

Natural gas releases less CO2, but it releases more methane in the shipment process, which is far more potent as a climate change agent than CO2. Depending on which estimates you buy into on the amount of methane lost, natural gas may be worse than coal for climate change.

I know most job boards are pretty noisy, but there are a few that are really good. Depending on the city/industry you're interested in, there's likely a niche board - including HN itself.

I'm at The Muse (YC W12) - I think we have a pretty good selection of jobs as well, especially in NYC/SF: https://www.themuse.com/jobs?job_category%5B%5D=Engineering&...

Feel free to email me too if you're looking for something specific, I'm happy to help. yusuf @ our site's domain.

I've been writing Rust too, but I'm not why the argument that it'll reduce the attack surface is glib. It can't prevent all security holes, though, because nothing can.

Parallelism necessarily implies concurrency [1]

So, "SIMD concurrency" is not incorrect (although SIMD parallelism is more correct :)

1: http://programmers.stackexchange.com/a/155110

The assumption there is that a regressive tax policy "lifts all ships." Piketty (and plenty others) have demonstrated that this does not happen.

How do you then prevent a regressive tax policy, given capital is almost the exclusive form of wealth accretion for the 1%?

I was a $BIGCO intern in 2011. I only hung out with Justin briefly at that time, but he more than anyone else got me into the startup scene. He came off to me as both rawly honest and friendly - attributes that are usually mutually exclusive. He'll make an awesome spokesman.

> Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust.

That's not a valid argument for why better tooling can't help alleviate some of the difficulty.

> Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term.

If that were true, the most effective programmers would only code on assembly.

> Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and other optimizations.

Why would higher level languages obviate knowledge of any of these things? If anything, I think it would help by reducing "noise" from incidental complexity; e.g. ownership in C vs Rust.

We made git-fit, which was inspired by git-media: http://github.com/dailymuse/git-fit

On the plus side, it's stupidly simple. On the down side, it's stupidly simple. The readme explains how it works.

Their site, not linked off in the article: https://coders.forsanders.com/

You can deadlock in purely message passing code, even if there are no blocking sends. See an example in Erlang: http://james-iry.blogspot.com/2009/04/erlang-style-actors-ar...

You can have "implicit" currying behaving as you described in a dynamically-typed, strictly evaluated language as well.

You can have currying in a dynamically-typed, strictly evaluated language.

I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want <feature X>, you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.

Why should this be the "most controversial theory"? Have we already forgotten what triggered the Arab Spring, and consequently the power vacuum that created the IS?

The only thing off, as far as I can tell, is the remark that "economic deprivation and the horrors of wars [...] benefited only a select few of the region's residents." I'm not sure if this is the WP mis-reading Piketty, but he makes it pretty clear in Capital that war benefits no one, especially the super-rich. It's not like the Arab aristocracy were itching for multiple revolutions that called into doubt the existing power structures.

We ported a major production site from python 2 to 3 a year ago. Exactly one bug has come up - something to do with unicode encoding on a relatively minor part of the site. Thanks to 2to3, the concerns for bugs coming up in porting are way overblown.

Interesting. This is closer to the older UI, before they rolled out "Repository Next" - https://github.com/blog/1529-repository-next

I feel like this is the direction Julia is going in. It's in this interesting space between statically and dynamically typed languages - technically it's dynamically typed, but you get a lot of the safety and performance guarantees afforded by static type systems through Julia's aggressive type inference [1]. As the type system gets richer, it should only get better on this front.

If you haven't checked out Julia yet, it's a beautiful language. There's a reason why Graydon (the guy who made the very early versions of Rust) likens it to a Goldilocks language [2].

[1] https://stackoverflow.com/questions/28078089/is-julia-dynami...

[2] https://graydon2.dreamwidth.org/189377.html

Don't believe the hype. Google has been saying that they can execute javascript for years. Meanwhile, as far as I can see, most non-trivial applications still aren't being crawled successfully, including my company's.

We recently got rid of prerender because of the promise from the last article from google saying the same thing [1]. It didn't work.

1: http://googlewebmastercentral.blogspot.com/2014/05/understan...

Oh man, that is a very good idea. Apparently Heroku (our pg provider) supports it as well: https://devcenter.heroku.com/articles/heroku-data-links

We use Chartio at my company. If you haven't tried it yet, this product is stellar - almost all of our BI needs are handled directly by stakeholders rather than having to go through an engineer, and their support is very helpful and responsive.

I would consider moving off to something like Quicksight if it supported redis. Some of our BI-related data is stored there, and currently to get at it we have an app that proxies data from there to postgres for Chartio's sake.

In my experience, this isn't really true. Google still can't crawl most non-trivial javascript-powered apps, and if it doesn't work, there's little insight on what you need to tweak to get it working. It hasn't been able to crawl our javascript-powered parts of the site across two major architectures without prerender, and I know a lot of other companies with the same issue.

If for whatever reason lfs doesn't work for you, check out our solution to large file storage on git: https://github.com/dailymuse/git-fit

We wrote it because of various issues with tools at the time, basically boiling down to an inclination to have a dead simple solution.

I haven't tried lfs, but if it's anything like github's other software, then I'm sure it's substantially better than our tool.

Per-actor GC is pretty important, as it allows Erlang to guarantee soft real-time / low latencies. This is simply impossible in the JVM unless you go with Azul's GC, which then sacrifices throughput.

I dunno, our sass codebase eventually got to a point where we couldn't watch it with the ruby-based compiler. It would take something like a minute to recompile all the files when a globally included file was edited. We ended up writing our own wrapper around sassc (the c-based sass compiler.)

How does Haxe manage impedance mismatches between it and so many target languages? I've never heard of anything pulling that off successfully. Maybe Eiffel? But then, who uses Eiffel?

You could turn this around and make it an argument against vim, if you're an experienced sublime/emacs/whatever user.

I'm not. We weren't fans of php either. Even if you buy into the philosophy that all languages are technically equal, that still doesn't make them pragmatically equal.

It was probably our network, but we had a very hard time finding good php engineers, and a much easier time finding good python engineers. So that won.

A couple of years ago, we moved off of wordpress precisely because it was written in php. Once you're trying to do anything reasonably complex in a CMS, the architecture and the programming language matter, because you have to extend the CMS in some manner. For us, wordpress wasn't extensible enough - and php wasn't pleasant enough - to justify continued use of it. I imagine people in a similar position who want to use Go would give this a serious look.

Can't you tune a 64-bit JVM to have a smaller heap or GC as aggressively as a 32-bit JVM?