I can see the appeal. Not having to write C# style oop probably gave the team a huge productivity boost. I bet it compiles hundreds of times faster making the team, cicd, and dev efforts substantially more productive. Cohesive integrated modern tooling is also a huge plus. Project structure is considerably simpler... I am not really a go fan but I would chose it over c# in a majority of cases as well.
I think they missed out by not going with Rust. It seems like the social factors weighed out. Probably hard to quickly assemble a rust team within msft. Again though that makes Go a practical choice. I don't see why people are so confused by it. Go is a pretty widely used and solid choice to get things done reliably and quickly these days.
The reason they didn't do Rust is because it was faster and more reliable to port the compiler and Go was a strong match particularly because of struct layout, types, concurrency, etc. but most importantly because it was native code with automatic garbage collection which Rust simply doesn't have. There's a video of Anders talking specifically about this.
The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed.
I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.
exactly , it sounds as if he is entitled to rust software.
Golang is generally very fast and simple as well , the only problem is of memory allocation / garbage collector overhead but the benefits outweigh the loss.
> They probably just didn't want to redesign a bunch of data types that assumed one existed.
Dude, just read the article being discussed, this is addressed so you can just stop making shit up.
The audacity of people like you to just keep adding speculations upon speculations on a subject without even bothering to learn what is being discussed.
Yes they said there were issues with cyclic data structures. Not really speculating just wrote it funny. I get why they chose what they did and even said I agree with it.
> I think they missed out by not going with Rust. It seems like the social factors weighed out.
They absolutely address this in the linked article, so why are we even speculating here?
> Probably hard to quickly assemble a rust team within msft.
The same MSFT that is rewriting their Windows OS in rust as we speak? I think you should stop commenting when you don't know anything about the subject.
Saying that Microsoft is "Rewriting Windows in rust" suggests you might not be as informed as you think... Very specific components with history of performance or security issues are getting ported in a very uncoordinated effort. Windows will be primarily C, C++, and C# for a very long time to come
Also those are two different skill sets. Writing critical sections of an OS is not the same thing as writing a compiler. And completely agree, windows to what I have read, is being deliberate and isn't doing a total rewrite at all. Thanks for chiming in so I could type less.
> Not having to write C# style oop probably gave the team a huge productivity boost.
I wrote a lot of Go code as well as Java. When people say things like this, I'm not quite sure what exactly they are referring to. No one is forcing you to write mutli-level deep inheritance hierarchies in Java/C#, and Go itself is OOP. Structural typing has its issues as well. Where does this supposed inherent productivity boost lie?
Unless, of course, you are not working on a greenfield project and instead are porting an existing compiler from Typescript, in which case Go is the language you would choose as it is the language that most closely resembles Typescript, allowing ease of bulk conversion by script. The same reason why it was chosen for Typescript.
People say this like it's a bad thing. It's not, it's Go's primary strength.