No, React beginner tutorial implies learning JSX , then you need to compile JSX into JS. Vue.js does none of that. You just write Javascript and HTML. And yes, Vue.js also supports server-side rendering.
> I think it is no surprise that one goal of Go is coding at large where large teams are involved.
I don't buy that. There is no proof Go programming at large scales better than Java programming at large.
Go didn't reach the scale of Java programs yet. And no, Kub or Docker, while fairly large, are nothing compared to 15 y.o. multi-million line Java codebases. Go certainly needs less bureaucracy due to the ease of deployment, but it doesn't mean Go projects scale better in large teams.
> For single person projects that I think you are doing, many people want intellectually stimulating language where Go may fall short.
I really hate this kind of arguments. Features like generics aren't intellectually stimulating, they are here because people want to write type safe code. Context.Value(interface{})interface{} isn't type safe code.
Now tell me, what is more intellectually challenging? writing concurrent programs free of race conditions or generics?
> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces.
As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling.
> (And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)
So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".
> The fact is a lot of people are perfectly fine current Go capabilities and prefer writing useful software solution as compared to debating on PL theories and community agendas.
How many? how many didn't use Go because it lacked of a sane type system? because Go relies way too much on runtime behavior (AKA type switches and reflection) to be called a modern statically typed language. In all my time using Java I never had to cast something once or use reflection, or to do a type assertion, all these are common practice in Go, especially when the std lib is now getting API like Context.Value(interface{})interface{}.
This isn't PL theory, these are flaws that aren't going anyway and will become more apparent as users will have to maintain all that "productive Go code" written 5/10 years ago. With Go the developers basically do the compiler's job manually. These problems are absolutely not going away, and people will write about how they ditched Go for these reasons.
> Not enough Go code adds context like os.Remove does. Too much code does only
Well, the error interface is { Error()string } and gophers were told to use errors as values, not errors as type because supposedly "exceptions are bad". By providing context you are just re-inventing your own mediocre exception system. Why use errors as value at first place if you need context? just put exceptions in Go, therefore people don't need to use a third party library to wrap errors in order to trace the execution context.
No, React beginner tutorial implies learning JSX , then you need to compile JSX into JS. Vue.js does none of that. You just write Javascript and HTML. And yes, Vue.js also supports server-side rendering.