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

What? You have to be authenticated as a superuser or other role with a very specific privilege.


> Immune response in reaction to what?

Autoimmune diseases like Crohn's and colitis?


The part of this argument I don't really understand is that it seems like the cost of bad programmers is higher, not lower, with a "simple" language where it's _normal_ to have type-unsafe code and mutable state everywhere.


Go is type safe (unless you use "unsafe" package, that is, but it's no different from Rust).

Or show me how you would subvert Go's type system and tell me which language you're comparing it to that wouldn't allow similar type system subversion. And no moving goal posts, please. "Type safe" has a certain meaning.

The value of immutability is so overblown, as shown by literally every mainstream language being mutable by default.

Not to mention the perf cost of immutability.

For just one example see https://ayende.com/blog/164739/immutable-collections-perform... (immutable version of dictionary is 30x slower, immutable list is 16-32x slower).

I'm not cherry-picking. This is just the first search result. If you understand how immutability works from first principles, it just does much more work.

Ultimately I wouldn't describe Go as "minimizing bad programmers" but "minimizing a damage that well intentioned but ultimately mis-guided good programers can do to the codebase".

For example I believe that your enthusiasm for immutability is well intentioned but I would rather not take 30x perf hit for theoretically safer code.

Bad programmer will write a bug that can be fixed.

A mis-guided good programmer will write a compile-time parser that only he can understand (possibly only for a week after writing it), will baloon compile times, produces incomprehensible error messages and you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read.

Go prevents mis-guided smart programmers from inflicting too much pain on everyone else.


Good compilers don't keep immutable things immutable at runtime, but turn uses of clean high-level functional code into tight C-like loops.

https://donsbot.wordpress.com/2010/02/21/smoking-fast-haskel...

It's been seven years since: that's GHC 6.13, and GHC 8.2.1 is being released soon. Performance is even better now as long as laziness doesn't bite you (which is much less rare than people think).

> you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read

I don't know what a "compile-time parser" is, but someone used to a good parser combinator library is going to be difficult to convince.

http://www.haskellforall.com/2017/06/translating-c-parser-to...

It reads like the formal spec of the language. Hand-writing recursive descent parsers isn't fun (given a sufficiently complex grammar) and expecting people to accept it as the One True Practical Non-Ivory Tower Way (and expressing dismay at not being able to convince them otherwise) is suggestive of monoculture, the kind that prides itself on copying code and using wrappers over the two or three first-class data structures that exist in the language for everything.


> Go is type safe

Functions that accept or return the interface{} type are not type-safe. These are _common_.


For almost all jobs at SpaceX, only permanent residency (i.e., a green card) is required, because that's what ITAR and EAR require.

But, yes, of course companies have no choice but to exclude non-citizens from jobs that require a security clearance, because getting a clearance requires citizenship.


I'm not sure what your search query is supposed to prove. That something is rare doesn't mean it doesn't exist. I have personally used this YAML feature, albeit very rarely, obviously.


His query is attempting to show that while

> YAML is what people turn to who need these kind of advanced feautures

might be literally true, it is also true that

YAML is what many people turn to even if they don't use those features

So the original concern of

> Powerful but pretty catastrophic if you use (naive) recursion to analyze a user-submitted data structure.

is probably reasonable.

There is a pretty good likelihood that many YAML users (i.e. the app developers) are unaware of the power exposed in the format, and the possible consequences of parsing & walking user input.

It brings back all sorts of memories of XML entity attacks, etc. When developers build simple data interchange methods on top of complex formats that they don't fully understand, all sorts of issues emerge.

It's not YAML's problem per se - it's very helpful that there is a commonly used, complex data format for people who need such features. It would be far worse if everyone was inventing their own solution for this - but the reality on the ground is still pretty messy.


>It would be far worse if everyone was inventing their own solution for this

They are - HJSON, JSON5, TOML, etc. Most of these reference YAML's overcomplicated spec as a reason for their existence.


>it can be considered a form of vigilantism

No. Vigilantism is extralegal. A lawsuit is by definition not vigilantism.


Boom! Exactly. He did something good using available means. Pragmatism is the ultimate move to make good things happen in the short term and he did it.

Had he not the risk of other people's information being leaked for the entertainment of the masses could be higher.


It is a strange, strange world in which Uber is considered "tech" but turning around a rocket after it's boosted a payload toward orbit and then landing it back on earth exactly where intended isn't technologically innovative enough to qualify.


> There's no reason to buy any other car.

This seems beyond out-of-touch. There are plenty of good reasons. Cost, size, and the fact that you might need a car now and can't actually buy a Model 3 yet would be chief among them.

It seems like a pretty great car if you're in its particular market though.


Yes, it seems pretty common to spend $35k on a vehicle, and of course people buying $35k sedans are in the Model 3 market, but I don't think that includes even new small economy car buyers.

It would be difficult to spend $30k on a new standard-engine Mazda 3. Mine was $18k brand new. The top standard-engine trim is around $25k. That other $10-17k is another $165-285/month over 5 years at 0% interest, and that is not an insignificant amount of money to many/most people.

If you can't save that much monthly in gas, and all you want is a boring, basic, reliable car, it's not worth it (yet). Tax incentives help, but Tesla is going to hit the 200,000 vehicle limit well before filling even all the Model 3 pre-orders.


You're comparing a Mazda 3, which is an economy car, against an entry-level luxury sedan. This is a bad comparison.

Mazda doesn't even have a car in this segment. You should be comparing it against a BMW 3-series, Audi A4, Acura TL, Mercedes C-series, Lexus GS.

All of those vehicles start in the 30s, and you would be lucky to get out the door with reasonable options under $50K. You could probably get the BMW up to almost $100K when you start considering the M package and various sports options.


> You're comparing a Mazda 3, which is an economy car, against an entry-level luxury sedan. This is a bad comparison.

Indeed, that was my point. The claim that "'economy' cars like the Honda Civic, Mazda 3, Toyota Camry, etc. can easily push up against $30k with a few options" is trying to assert that people buying those kinds of cars are in the Model 3 market. But they really aren't. People buying small luxury sedans like the ones you've mentioned probably are, though.


I think I'd resign if someone in a position to be reviewing Python code scolded me for using a list/dict/set/generator comprehension.


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

Search: