The set of people who worked their asses off and the set of people who were considered wealthy when they reached the median retirement age (or at the time of their death) don't necessary have a high degree of overlap.
Ancestor post stated that the intersection was not equal to the empty set. Its reply post implied that the intersection was not equal to the union, and perhaps that the intersection was not even a significant fraction of the wealthy set. They were speaking past each other.
Wealthy people like to overemphasize the contribution of hard work to their own wealthiness, which has a side effect of encouraging non-wealthy people to fall into exploitable patterns in their attempt to become wealthy. If you want to get rich, don't work hard. All that hard work is just going to distract you from what you should be doing--acquiring ownership of moneymaking machines that are either fully autonomous or have a very high multiplier for turning your own work into spendable money. You can buy them, or you can build them, but you'll have a hard time doing either unless you spend a lot of time around wealthy people, leeching off their knowledge of how the machines operate.
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.
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.
I think the trouble there is just that many other modern languages haven't taken the extreme stance on typing that Go has. It's much easier to learn say, Rust or Scala, than it is to fork and maintain a branch of Go, and there's certainly nothing so special or attractive about Go to tip the balance in the latter's favor.
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).
It is rather surprising if not outright shocking that experienced developer get heavily invested in a language when other mature/ better alternatives are there.
> 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?
The group of people who are able to fork, change and maintain their own Go variant are usually not the people who would ever consider using Go in the first place.
Have a look how long it took PHP to get an AST (instead of the broken mess of reading&executing). Those who are able aren't those who would ever deal with PHP.
I've sometimes wondered a bit about this myself. But consider what you'd end up with if you wanted to keep most of go's benefits, but add on such bits. And consider that you could just use Ada, Nim or OCaml. Or maybe Rust (I really like Rust, I'm not sure how much overlap there is in any subjective list of "Go the good parts" and "Rust the good parts" though).
I think some of the best parts of Go is the central model: "go get", "go fmt" along with the standard library - if you fork, the burden falls on the fork keep all that stuff working in a sensible way too.
- OCaml is great but parallelism is still limited by its "Global Interpreter Lock" (like Python or Ruby).
- Rust is great but ownership/borrowing is not for everyone and people sometimes prefer relying on a good garbage collector.
- Nim is great but it's a "small" project compared to Go and most people prefer relying on a large ecosystem like the one offered by Go.
- Ada was a major milestone in the history of programming languages, but it's considered by most as an "old" language, compared to Go/Rust/OCaml/Haskell/Scala/etc.
> 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.
This is a bizarre comment. Rails failed to stand the test of time because it doesn't play very nicely with monolithic JavaScript frameworks? Are you asserting that such frameworks are the future?
I think they are referring to most UI logic being on the client, not on server. That architecture does not require a monolithic JS framework, nor does Rails offer anything special in that case.
