Good point. I agree there are other reasons to use Go, I what mean is that unless I have a project that gets a lot of bang for the buck out of those, the KISSness of Go wins out over those nice features and their correlated complexity. GC was just at the forefront of that list of features.
Re:Rust vs C Pitfalls
by Ericson2314 on Tuesday December 27, 2016 @11:24PM
(#13268406)
There's simple, and there's anti-intellectual. Go would be the latter.
Well, in many respects Basic, PHP, Javascript, Java all had various forms of "anti-intellectualism" baked. They lost some of them along the way.
Still, the fact that all those languages are in the top 10 of programming languages kind of says that people don't really care.
Go is against the sort of programming that builds up conceptual dream worlds of gratuitous abstraction and needless complexity. When that's the only way you want to think, Go will indeed seem anti-intellectual.
Re:Rust vs C Pitfalls
by tigershark on Wednesday December 28, 2016 @08:39AM
(#13270350)
A modern programming language without any whatsoever support for generics from my point of view is just extremely bad, for someone else can very well be proof of anti-intellectualism.
Re:Rust vs C Pitfalls
by santaclaus on Tuesday December 27, 2016 @05:21PM
(#13266708)
> I don't use Rust just because I want to avoid GC.
Go that is?
Re:Rust vs C Pitfalls
by burntsushi on Tuesday December 27, 2016 @05:28PM
(#13266760)
Hmm, not sure I understand? Re-reading, perhaps my phrasing wasn't clear. What I meant was that I use Rust, and it's not simply because it lacks GC. There are lots of other good reasons too.
To be even clearer: I don't think Rust's value proposition depends on whether you absolutely must avoid GC or not.
Rust has gc, no?
No, it does not. It does allow you to implement it if you want though: https://github.com/Manishearth/rust-gc
Not in the mandatory runtime overhead, cycle collection, or non-deterministic pausing senses of the word.
It has optional RC type.
It had GC as core part of language, about six or more years ago?
It has reference counting for some of the constructs which is a form of garbage collection and it has runtime overhead. Like shared_ptr in c++.
Re:Rust vs C Pitfalls
by tomjakubowski on Wednesday December 28, 2016 @06:16AM
(#13269832)
This is a misleading comment. A Rust program may use reference counting by explicitly wrapping some value in Rc<> or Arc<>; the standard library provides these generic types. There are no "constructs" built in to the language or standard library that require the use of reference counting.
I wrote it's like shared_ptr which is also construct in C++ standard library, what is misleading here? You don't need to use it also in C++ and I did not wrote that you need to use it in Rust also, you disagree with something that I didn't wrote.
PS. Pozdrawiam rodaka.
Re:Rust vs C Pitfalls
by 404-universe on Tuesday December 27, 2016 @06:01PM
(#13267011)
Not really, no. You could implement one with e.g. reference counting, but one is not provided for you by default.
Re:Rust vs C Pitfalls
by colejohnson66 on Tuesday December 27, 2016 @05:57PM
(#13266982)
Depends on your Rust implementation. You can have an implementation without one and use it to make, say, an operating system.
Re:Rust vs C Pitfalls
by steveklabnik on Tuesday December 27, 2016 @06:07PM
(#13267054)
There is only one implementation of Rust, and it does not have tracing GC. The language does not include semantics for one, so it would be an extension of the language.
Re:Rust vs C Pitfalls
by colejohnson66 on Wednesday December 28, 2016 @12:00AM
(#13268511)
Right. I had that backwards. (I don't program Rust)
> I don't program Rust
If you don't know anything about rust, you shouldn't respond to a question about rust.
(I've used Go and Rust daily for the past few years. I love them both.)