I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything.
I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it".
If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics.
Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.
> Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal.
> This also prevents errors being dropped by accident.
Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.
> And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem.
"A little copying", "less reliant on dependencies"... do you even vendor bro
> While not objectively a bad thing, that's at the crux of the problem many have with Go: it sets the bar very, very low for getting in your way instead of trusting you to be even slightly competent.
And there's nothing wrong with that, that's exactly Go's target audience.
> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.
I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".
(I'm going to ignore the personal attack and insult)
> If you want to talk figuratively, making mistakes does not constitute having your "head up your ass." Even making multiple mistakes doesn't warrant that kind of statement.
Making deliberate mistakes multiple times and resisting fixing them for 10 years does qualify as having their "head up their ass" (or asses if that's what you prefer).
> Generics are slower, that's the trade-off. Developer time vs. execution time.
You have no idea what you're talking about.
> Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.
No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an experiment in combining bad decisions into a single programming language to see what would happen. What those very people didn't realize upon releasing it to the world is the sheer amount of people who fell for it, it was supposed to be a joke, with a stupid looking mascot and all... Now they have to take it seriously - and Google has to choose between keeping it alive or getting a forever bad rep for killing it - because too many companies rely on it, and they are forced to retrofit useful features on top of the giant pile of garbage they've created.
VS Code takes ~6 seconds from clicking its icon to having its window show up. On an 8th-gen Intel i7 with an SSD. Yes Electron has abysmal performance.
I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?
> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI.
Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.
> Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease.
That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).
> For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.
Threema is one alternative.