3 ms·

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concer

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

eximius 3y ago
There is more code written in C++, but there are fewer "C++ packages" in the sense of just doing `go get` and you're ready to use it.
- rowanG077 3y ago
  I doubt that's true. In all the years I have never not found a library that can the things I want in C or C++. It doesn't have a package manager but that doesn't mean it doesn't have packages.
eklavya 3y ago
It doesn't make sense when you use this reasoning on established languages like C++ and Go. Makes all the difference when you are less than a year old language.
furyofantares 3y ago
> I want a language for writing applications that is more expressive than Go but less complex than Rust. > Go is simple and straightforward, but I often wish it offered more type safety. Rust is very nice to work with (at least for single threaded code) but it's too broad and complex, sometimes painfully so. It seems clear that the author really likes aspects of both Go and Rust and desires something between the two. Check out the complexity vs type-safety illustration at the top of the page, with Borgo placed between the Gopher and the Crustacean just before the complexity curve gets steep. They're basically building their personal ideal version of Go with inspiration from Rust.
- rowanG077 3y ago
  Sure. I'm not knocking the design goal. The same thing could be achieved by having C++ as a target. So why choose go.
  - furyofantares 3y ago
    Because they like go, are making essentially a go extension, and so a lot of their features map directly to go features. No need to re-implement goroutines and channels etc. The type system lets them reject the programs they want to reject, but if a program is valid in the type system it can, in large part, emit essentially the same go code sans the types. I mean, I'm making some assumptions here, but that's typically the reason.

It doesn't make sense that that is the reason. Surely C++ has way more packages. So Go would be a bad choice if package availability was a very important concern.

eximius 3y ago

There is more code written in C++, but there are fewer "C++ packages" in the sense of just doing `go get` and you're ready to use it.

rowanG077 3y ago
I doubt that's true. In all the years I have never not found a library that can the things I want in C or C++. It doesn't have a package manager but that doesn't mean it doesn't have packages.

eklavya 3y ago

It doesn't make sense when you use this reasoning on established languages like C++ and Go. Makes all the difference when you are less than a year old language.

furyofantares 3y ago

> I want a language for writing applications that is more expressive than Go but less complex than Rust. > Go is simple and straightforward, but I often wish it offered more type safety. Rust is very nice to work with (at least for single threaded code) but it's too broad and complex, sometimes painfully so. It seems clear that the author really likes aspects of both Go and Rust and desires something between the two. Check out the complexity vs type-safety illustration at the top of the page, with Borgo placed between the Gopher and the Crustacean just before the complexity curve gets steep. They're basically building their personal ideal version of Go with inspiration from Rust.

rowanG077 3y ago
Sure. I'm not knocking the design goal. The same thing could be achieved by having C++ as a target. So why choose go.
- furyofantares 3y ago
  Because they like go, are making essentially a go extension, and so a lot of their features map directly to go features. No need to re-implement goroutines and channels etc. The type system lets them reject the programs they want to reject, but if a program is valid in the type system it can, in large part, emit essentially the same go code sans the types. I mean, I'm making some assumptions here, but that's typically the reason.