devishard

Hacker News, where saying it nicely is valued more than saying anything useful.

I think that Java can definitely provide significantly more protection than Go, but I do agree that Java's horrible namespacing conventions and lack of type inference makes it cumbersome.

So what, you're on par with a 20 year old language? C# for example learned from Java's mistakes; why couldn't Go?

This is interesting, especially given that many people lie about previous pay in order to get a higher pay. It's an extremely effective strategy.

> The are great advantages to individuals and society to paying less than the value of goods and services. If my daughter is ill, and a simple shot of antibiotics will cure her, should I pay $20 for that, or should I pay what saving her life is actually worth to me? I've enjoyed ever faster internet connection speed at my home (coming in two weeks -- gigabit!) I assure you I'm not paying the full value of what that speed is worth to me. The same for food, clothes, transportation, everything. If I really did have to pay the full value to me for each of those I would, by definition, be indifferent to buying any of them.

Okay, so what's the society of my boss getting paid twice as much as me while actively impeding my ability to create value?

Also, antibiotics and internet are poor examples of market economics; both are heavily subsidized and regulated. So it's disingenuous to hold these up and then in your following paragraph claim that market economics is helping humanity.

> Market economics has some serious downsides, but it has vastly increased the welfare of humanity. More people have been coming out of poverty in China in the past few decades that ever before in human history.

How do you justify attributing this to free market economics?

> If you feel it is unfair that as a developer you can create millions of dollars in value that you aren't being compensated for, then I recommend you consider ways that you could be compensated for this value. Perhaps instead of being an employee, maybe get involved in a start-up with equity (or found a company.) Having done so, I can assure you it's more nerve wracking than ever I would have expected, and harder to unleash the millions in value than one might expect, but it's still fun, challenging, rewarding, and worth giving a go! :-)

I do think it's unfair, but I actually don't care, because I'm self-aware enough to realize that the way in which our economy hurts me is nothing compared to how it hurts most people. I'm incredibly lucky to have landed in a career where things are only as unfair as they are, and I'd much rather work toward helping people in worse situations than me than in fixing the minor injustice of getting paid less than management.

I actually have nothing against Elon Musk. I don't expect anyone to do things completely altruistically. But it's ridiculous to claim that this is just purely altruistic.

Almost anyone can think of other apparent motivations Musk might have without my help and indeed without much thought. It doesn't require explanation.

I also think that people should be strongly discouraged from making claims like "here is a man who twice bet his personal fortune on these companies with no other apparent motive besides making the world a better place." That statement actively decreased the quality of discussion. Hopefully bronz will think before posting in the future.

> Somebody (usually several somebodies) took the chance to create a support structure to enable said person to create the millions of dollars in value.

A tech company contains a lot of structure, and very little of that is actually geared toward enabling anyone to create millions of dollars of value. A large portion of that structure exists to enable the management of a company to justify taking in large profits. It's should surprise no one that those creating the structure would create it in a way that benefits them.

I know a few people who work at a tech cooperative, which has mostly developers with 1 secretary who manages benefits/taxes/etc. and 1 "business liaison" who manages customer communication. They've created millions of dollars of value without most of the structure, and it's no coincidence that they're all set to retire in their late 30s.

I don't think the poster of your parent comment would disagree with your explanation of the how things are; they're only saying that's not how it should be.

If we lived in a just meritocracy, people who created millions of dollars in value with their code would be compensated with millions of dollars, but this is rarely, if ever, the case. It's this fact which makes libertarian arguments about the unfairness of tax and social welfare programs offensive.

I don't think the poster of your parent comment would disagree with your explanation of the how things are; they're only saying that's not how it should be.

If we lived in a just meritocracy, people who created millions of dollars in value with their code would be compensated with millions of dollars, but this is rarely, if ever, the case.

It's telling that the most sophisticated type system you've dealt with is Ruby, though. I think that if you spent some time working in OCaml/Nim/Rust/D/C# you'd learn a lot which would cause you to be a lot less impressed with Go.

1. How many people have 10 million line code bases?

2. How many of those people would have much smaller codebases if they used a more expressive language?

3. Of the people who have 10 million line codebases and would still have 10 million line codebases in a more expressive language, how many of those could actually compile their programs faster if they used a language that allowed partial compilation of only the parts of the code that were changed?

Very few people have Google's problems, and I'm not even completely convinced that Go is the best way to solve Google's problems.

Or literally any statically-typed language I know of after C. I suppose it's possible there's some language I'm unaware of that has managed to somehow provide less type-checking than Go, but it's certainly not a commonly-used one.

> Sorry, your posting is unnecessarily abrasive.

Go is a much bigger problem in our industry than the tone of my post.

> I have never claimed that Go has the most advanced type system.

You claimed it had "strict type checking", when it has the least strict type system of any statically-typed language in common usage except C.

> But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system.

With template types, you can definitely get more strict type-checking out of C++ than out of Go.

So basically, Go has a more modern type system than C. And that's arguably not true. None of which disproves what I said: I said, "people who like Go only like it because they have no idea what has happened in programming languages for the last few decades."

> And it gets work done.

You can make that claim about any language. The question is, does it get work done as efficiently as other languages? And the answer is pretty clearly no.

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point:

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system.

Strict type checking? Have you used any other languages besides C? Go's type system is a joke.

Like literally, it's a joke. If you get a bunch of people who know about types languages in a room discussing types, "What about Go?" is guaranteed to get a laugh.

shitty design != conspiracy

> here is a man who twice bet his personal fortune on these companies with no other apparent motive besides making the world a better place.

That has to be the most naive statement I've seen on Hacker News.

Sure, maybe if you're looking for reasons to take offense, "just" is one you could take offense to. But ultimately I think if we all are walking around on eggshells to the point we can't say that word, that's a much worse environment than one in which people say "just".

Besides, just because you take away the word doesn't mean they can't say it. Removing the word just makes it harder to recognize when people do it.

> I don't think we do. I think we need to foster a culture of honesty and rigor. Of good science. Which is decidedly different from fostering a culture of "repetition" for its own sake.

No one is proposing repetition for its own sake. The point of repetition is to create rigor, and you can't do rigorous science without repetition.

> Paying for the cost of mountains upon mountains of lab techs and materials that it would require to replicate every study published in a major journal just isn't a good use of ever-dwindling science dollars. Replicate where it's not far off the critical path. Replicate where the study is going to have a profound effect on the direction of research in several labs. But don't just replicate because "science!"

I could see a valid argument for only doing science that will be worth replicating, because if you don't bother to replicate you aren't really proving anything.

There is literally no way to use the email they took from me that isn't a dark pattern.

> If you're going to take the trouble to specify that it's an integer list, might as well use a statically typed language, right? When you use a dynamically typed language, presumably the point is to not have to worry about static types.

Yes, I said that. :)

> > "Soundness" is a mathematically defined concept, but a very binary one (it's sound or it isn't).

> That's precisely why it's better!

Well... it's better for some purposes, but it doesn't allow us to talk about most languages effectively. None of the top 10 most commonly-used languages in industry today are soundly typed. If memory serves me, in fact, the only language I know of with a mature implementation that's soundly typed is ML. So it's a useful concept in a very specific context, but not that useful for talking about most languages.

> I'm not so sure about this one. Although Java is certainly safer than C, because it replaces undefined behavior with a battery of runtime checks (just like a dynamic language), I feel it's about equally difficult in Java and C to translate my thoughts into types.

Basically I think what you're describing about Java is a mixture of mid-strength static typing and relatively strong dynamic typing. At least, that's how I'd describe it.

C does no real checking i.e. around `void` pointers, adding integers to pointers, tagging unions, etc., at compile time or at runtime, which is why I claim it's a very weakly-typed language (and also why I tend to avoid some of those features).

That's very interesting. Do you have any insights into why the descriptor differences are like that?

As someone who has thought Go was a poor choice for almost any project for a long time and argued that many times, I used to come up against the argument that Go package management was superior to other languages. Six months ago I said:

> Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems.

> With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go.

> You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option.

> I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries.

> If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.

And in a different post:

> give it a decade and Go packaging will be just as miserable as packaging in any other language.

I've been coming up against that argument a lot less lately. It looks like my prediction is coming true a bit ahead of schedule.

Question: it seems to me like you could get a long ways with a hidden service simply by placing the same key on multiple servers with disparate physical locations. Wouldn't this provide a sort of randomized load balancing, since different connections would find different servers with the correct key first? I can definitely see the need for more sophisticated load balancing if your usage gets large, but for smaller services it seems like this would give a good amount of scalability.

I'm not well-versed in how these work though, so I'm curious.

> There are two sources of such information: the static context (e.g., in Scheme, which variables are in scope) and the dynamic environment (e.g., again in Scheme, the type of an object, and, in Python, pretty much everything). The static context grows whenever you bind variables in the program text (e.g., when you define a procedure). The dynamic environment grows when the control flow reaches such binders (e.g., when it enters a called procedure).

Heh, I intended that as a rhetorical question, but I admit that wasn't clear from my post, and this is a very thorough answer. :)

> For example, if you create an empty mutable list object, dynamic analysis can't tell you what its element type is supposed to be, until you actually start inserting elements into it.

That's a limitation of most implementations of mutable list objects in dynamically typed languages, but there's nothing preventing a dynamic language from having a mutable list that enforces a single type in a list at runtime starting from the construction of the list. In Python it would not be difficult to implement an `IntegerList` class which enforces that all its elements are integers, for example.

Yes, we can't determine at compile time that the following is a type error:

    a = IntegerList()
    a.append('Hello, world')

But we can report on that at runtime (remember, I'm talking about the quality of type errors, not when they occur).

Further, one can imagine a hypothetical dynamic language where we parameterize types, too:

    a = List<Integer>()
    a.append('Hello, world')

Of course this could be implemented statically, but it could be implemented dynamically, the difference being that the type error would be reported at runtime instead of compile time. The reason, I think, that this isn't done is that once you get to the point where you're putting type parameters like this, you've lost most of the benefits of a dynamic type system, and would gain more from seeing your errors at compile time.

> > A type system that gathers lots of type information is equivalent to a strongly-typed language IMHO

> This isn't true. C++'s type system gathers a lot of type information, yet C++ isn't “strongly typed” (assuming that term means anything at all) by any stretch of the term.

You're right, I can't imagine what brain fart caused me to say what I said there. /shrug

> Rather than “strongly-typed”, a more useful term is “sound”. A type system is sound when it actually protects the language's basic abstractions. For example, Standard ML has a sound type system, and there's a formal proof of this fact. Java's type system is actually unsound, but it makes up for this deficiency by inserting runtime checks to turn wrong operations (e.g., invalid downcasts) into runtime exceptions (just like in Python!). C++'s type system is also unsound, and performing wrong operations is simply undefined behavior.

"Soundness" is a mathematically defined concept, but a very binary one (it's sound or it isn't). "Strength" is a different concept which admittedly isn't an objective measure. But I think we can agree on it as a subjective measure for comparing some things. For example, I do think there's a real phenomenon described that we can agree on when I say that Python is more strongly-typed than JavaScript, and Java is more strongly-typed than C, and I think you'd agree with me on these comparisons, even though none of these languages are soundly typed. Sound typing corresponds to a very strong type system. :)

I'm aware of what's happening. It's definitely a norm in C and it produces desirable results in many cases (I've written similar structures myself many times). All I'm saying is that from a type perspective it's a bizarre choice to allow that.

> Well durr! We could be here all night listing things that SSH hardening wouldn't secure against. I never suggested it was a silver bullet to fix all security needs (which seems to be the faux argument you're accusing me off).

That's not what I accused you of--people can read our previous discussion and see both what I actually accused you of saying, and also that you said what I accused you of saying.

> You cannot compete on an intellectual level so you make baseless accusations about my professional capabilities instead.

I did call your course of action a mistake, but that's not an attack on your professional capabilities. Everyone makes mistakes. I'm sure you're reasonably skilled at your job.

I think you'd enjoy this conversation a lot more if you didn't take my disagreement with your strategy as a personal attack. But if that's what you want to do I can't stop you.

I didn't explain that well--initially Twitter was on RoR and sharded MySQL, which wasn't scalable. Obviously they have done a lot of scaling work and can handle their load now.

If I were implementing Twitter today, I'd probably do Elixir and Cassandra. I don't generally leap to go NoSQL but Twitter's structure is particularly suited to Cassandra. Elixir gives the ease of development I associate with Ruby with the scalable, decentralizable BEAM. I'd also consider going with Erlang straight up--it may not be as pretty as Elixir, but there's a lot to be said for maturity in a language.

But I'm saying this because I have the benefit of newer technologies and having seen Twitter's mistakes. From a technical perspective, I think Twitter is pretty well done.

> I think that's an unfair comparison for two reasons: (1) People were already comfortable with the idea of paying for cabs, cable, games, books/electronics in the old world. Whereas the current norm is _not_ to pay for social media services.

Of course; this is because cabs, cable, games, books/electronics all provide value. Most social media services don't, at least not enough value for people to pull out their credit cards.

> (2) A transportation service, game, streaming video service, e-retailer can deliver value to their first customer. A social network is only valuable if others are using it. If Spark / Twitter 2.0 launches tomorrow, even if they can provide a bunch of product improvements over Twitter 1.0, the first users have no reason to pay b/c they're joining an empty / worthless conversation, so at launch it's almost necessary to allow people to join for free. And this creates the norms described in (1).

I disagree, I think the norms described in (1) exist because Twitter/Spark provide very little value to their users.

You're describing a first-to-market advantage, but that's not really relevant. If that were a signifiant deciding factor, Twitter could simply institute a subscription fee and be profitable by tomorrow. But they can't: if they did that, they'd lose all their users overnight.

> My point was correct to the specific attack you broadly described.

But you didn't correct it, you proposed a solution that didn't address the attack I described.

> Your example required a web server attack that allowed arbitrary code execution and privladge elevation; which is a hugely specific attack and it's pretty fair to say it's unlikely (in the case of gaining root access and then choosing to enable SSH, which I'll get to).

The XSS attack is just an example of a vulnerability that wouldn't be addressed by hardening SSH. There are plenty of other vulnerabilities that wouldn't be addressed by hardening SSH.

> Furthermore, and at risk of sounding like a broken record, if an attacker can remotely execute code as root then they have absolutely no need to enable SSH for they already have far easier methods of firing off a remote shell. (To be honest they don't even need root to accomplish this).

There's a good reason to demonstrate SSH access even if they have root access: they might want to show their capabilities without exposing how they gained those capabilities (because knowing how they gained those capabilities would allow the OP to fix the problem).

> This is not a mistake, this is something I've done in practice when auditing security at work.

Just because you've made mistakes in practice when auditing security at work doesn't mean they aren't mistakes.

This isn't even time for a security audit. OP first really needs to do some forensics. A security audit should happen, but it can wait until the vulnerability has been found and fixed.

That's a reasonable critique, and I think you're right. There exist products that start off without value people would pay for and slowly develop into something with value people would pay for, and Google is a good example.

I guess that leaves room for Twitter to develop into a product people would pay for, but I'm skeptical that can happen without very significant changes to their product, to the point that I'd be hesitant to call it the same product.