The modern American Dream, perhaps. The historic American Dream was a marketing campaign centred around enjoying the long commute in your American made automobile.
But we are still bound to supply and demand. If everyone was a coder, price would plummet. Programmers are only currently able to do reasonably well because they are relatively limited in numbers compared to the demand for them.
It is very much impossible for most Americans to be coders while maintaining high incomes. The industry isn't anywhere near that big, currently employing less than 1% of the population. Even if it could grow by an order of magnitude, it still wouldn't absorb any meaningful portion of the population.
The working class, as the name implies, earn their money by working. The upper class make their money through investments. The middle class fall in between. They make part of their income by working and part of their income through investments.
The practical implications are that if the working class stop working, they can no longer make ends meet. The middle class have the opportunity to stop working for periods of time, but not indefinitely. The upper class can survive without ever lifting a finger.
While I completely agree that the standard library is all you need in quite a lot of cases, the parent seems to be asking from more of a "how do I structure my application" perspective. A tool that generates the boilerplate necessary to use the standard library effectively in a complete application. Not just http handlers, but think of the persistence layer, for example. The standard library does not assist much with the engineering aspect of the job.
The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL.
What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).
What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them?
Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.
> the only clean at scale power solution for peak load is nuclear power
Nuclear is fantastic for base load, but peak load? Steam bypassing costs as much as generating electricity does, but with nobody wanting to pay for power they didn't use. Technically a good solution, but falls apart economically.
Having used Rails seriously since it was originally made available as an open source project, I find myself agreeing with you less and less. It has really failed to stand the test of time, in my opinion.
I agree that it nailed the needs of web applications in 2004. If you are still building web applications like they did then, perhaps it is still the best tool. In the circles I find myself in, there is a push for much more Javascript heavy applications and Rails starts to become a large hinderance more than a help in that environment, when compared to other tools.
We've built a log of great software together over the years, but I can honestly say that I'm not going to rush into using it in future projects.
I imagine it is being primarily driven by the recent vast decline in the Canadian dollar. Just about all of the costs involved are going to be about 30% cheaper compared to a couple of years ago.
> The concept of a salary is to pay someone in return for work performed.
Not necessarily. Having someone retained for future needs, for example, is worth paying for in some cases. Value isn't limited to work performed.
Pay is, of corse, just the point where the buyer and seller agree. There is no fundamental reason why a janitor position cannot pay the same or more than a manager, if janitors refuse to do the job for any less.
Additionally, while I do not know in which country you reside, generally countries who fully subsidize higher education have much more stringent requirements to entry, allowing only those who are completely serious about receiving an education access.
In America, if you are willing to pony up the cash, you're pretty much guaranteed a spot. Combine that with the common idea that you will not be able to find a job without a degree and you end up with a lot of people who aren't really in it for an education, but feel like they have to be there anyway.
Also, H1B workers get paid the same as local workers... So if you buy the allegation that wages are being depressed by H1B workers, why don't you take a peek at the bulletin board of your break room
The idea usually is that the presence of an H1B means that someone local does not exist to do the job, which means that a company would otherwise have to pay more than the going rate to poach someone else from another company. Then the company losing the employee has to pay more to poach from somewhere else, and so on, until eventually everyone who is suitable for such a position is making more.
The fact that H1Bs are paid what the locals are paid is exactly the issue people have when they talk about wage suppression. It is in much the same vein as when Apple/Google/et al. agreed to not steal each others employees. It is not like those employees were exactly hurting for compensation, but they theoretically could have made more without that treaty between companies.
> Most exceptionally high earners have college degrees.
Interestingly though, most exceptionally high earners have post-graduate degrees, according to Gallop[1]. When you exclude that group, the non-college graduates make up the largest portion of the highest earners.
If there is causality here, it seems one has to be mindful to continue their studies long enough to see the benefits. Simply getting a degree does not seem to pave the way to a better income.
I take that to mean that for the first time in his life he read the papers and fully understood them without needing additional background, not that there isn't more to learn outside of those papers.
> Most students of history in high school won't be historians; most students of literature won't write great novels or screenplays; and so on.
But by the same token, the economic effects are quite apparent. It takes a very special individual to rise above the pack in history and literature to turn that into a successful career. For most, with so much competition, it will never be more than a hobby. Anecdotally, I have a couple of friends who are published authors and I would be surprised if they are ever able to recoup the cost of the time they put into it, let alone sustain their costs of living.
Programmers are fortunate right now that the skill is relatively rare amongst the general population and when demand exceeds supply, prices rise. The concern isn't so much with everyone being a programmer, it is that only a few will be able to make money at it when the supply starts to exceed the demand, much like careers in history and literature today.
As always, prices are determined by supply and demand.
A price is too high if the buyer can find the same thing (another programmer considered to be an equal hire, in this case; people are not commodities so this can be difficult to evaluate with absolute accuracy) for less. A price is too low if the buyer cannot find the same thing for even an equal amount.
The price is just right, at that moment in time, if there is a mutual agreement between a buyer and a seller.
> Well, sure. Hand-written assembly is also identical to compiled code
I mean when you convert the template<type> statement to the #define statement with the hypothetical preprocessor, it would be the same as if you had written the same code using #defines originally. They are functionally interchangable. If this satisfies generics in your mind (I don't think this describes you, for what it is worth), then standard C macros are more than sufficient to cover all the cases you would want, albeit less pleasant to type.
> I don't think macros are a satisfactory replacement for generics, no. I don't know how I seemed "excited" about it.
Consider your previous post misinterpreted then. It read to me like you thought the hypothetical code was theoretically different and solved problems with the previously provided macro, even though it was the exact same macro in both cases. The only difference was the slightly different syntax. Which, I might add, anyone can fairly easily add something similar to their Go code if they really wanted to.
