News for hackers. Stuff that matters.
Re:Go best practices, six years in by weberc2 on Sunday May 01, 2016 @05:27PM (#11607922)
I don't know, I want to like Rust, but every time I pick it up I feel like I'm relearning C++. It's learning curve is steep, the sorts of applications I write benefit more from solid development velocity and a good concurrency story. I might be wrong, but I get the feeling that Rust really only shines where performance and meticulous control are paramount. I want to like it, but it feels ill-suited to the applications that interest me. :(
Re:Go best practices, six years in by ntonozzi on Sunday May 01, 2016 @05:56PM (#11608040)
I don't think there's anything wrong with that. Rust is designed for a specific market, and it sounds like you aren't part of it.
Re:Go best practices, six years in by weberc2 on Monday May 02, 2016 @04:48PM (#11615460)
I agree; but I think I'm still allowed to be disappointed that my use cases aren't a good fit for so thoroughly-heralded a language. :)
Re:Go best practices, six years in by MichaelGG on Monday May 02, 2016 @04:51PM (#11615484)
Don't be disappointed. If you don't need the performance Rust offers, then use another ML-ish language. More expressiveness, none of the ownership issues (just GC).
Re:Go best practices, six years in by weberc2 on Monday May 02, 2016 @04:59PM (#11615558)
Which would you recommend for someone who prefers a C-like syntax, a good concurrency story, a comprehensive standard library, Java-esque speed, and dead-simple tooling (e.g., Go's tooling), and compilation to a static binary?
Re:Go best practices, six years in by MichaelGG on Monday May 02, 2016 @05:43PM (#11615929)
C# and F# can both compile to a static binary (Mono's AOT compiler), and meet your other requirements. I find it curious that "safety" wasn't one of the points.

If you're looking for C-like though, you are probably not in any modern-featured language designer's aim.

Re:Go best practices, six years in by weberc2 on Tuesday May 03, 2016 @09:44AM (#11620533)
> I find it curious that "safety" wasn't one of the points

It was implied by the context of "ML" languages. That was my intention at least; I thought ML languages were characteristically safe.

Regarding "C-like", I mostly mean syntax. I'm not too familiar with the ML family, but many FP languages have bizarre syntax which amplifies the difficulty of learning new concepts IMO.

Re:Go best practices, six years in by valarauca1 on Sunday May 01, 2016 @07:45PM (#11608381)
>I feel like I'm relearning C++

Because you are. You likely wrote widly unsafe things which are perfectly legal in C++. Rust is really just enforcing RAII which C++14 already has, and you've likely avoided.

Re:Go best practices, six years in by catnaroek on Monday May 02, 2016 @01:40AM (#11609383)
C++has had RAII for decades already. Actual Rust innovations are the borrow checker and dynamically sized types.
Re:Go best practices, six years in by pjmlp on Monday May 02, 2016 @02:21AM (#11609487)
Yes, we were already using it on Windows to program COM in the mid-90's.
Re:Go best practices, six years in by cwzwarich on Monday May 02, 2016 @03:39AM (#11609775)
The borrow checker is predated by Cyclone and other work on region systems. Rust added more polish, but none of the basic ideas are new.
Re:Go best practices, six years in by catnaroek on Monday May 02, 2016 @03:53AM (#11609823)
Of course, I'm aware that work on region systems dates back to the mid 90's, which is why I called Rust's borrow checker an “innovation” (the first time a product form factor or feature successfully makes it into a market) rather than an “invention” (coming up with a product concept that didn't exist before).
Re:Go best practices, six years in by MereInterest on Sunday May 01, 2016 @09:07PM (#11608637)
Wait, people avoid RAII? With how useful it is in every circumstance, I can't imagine C++ without it.
Re:Go best practices, six years in by weberc2 on Monday May 02, 2016 @04:57PM (#11615541)
It's not just the safety features; it's the syntax, the build system, the numerous kinds of strings, the difficulty of finding up-to-date documentation, etc. Rust just has a steeper learning curve than many newer languages. This is not to say that the learning curve is unjustified; only that it exists and is significant.
Re:Go best practices, six years in by weberc2 on Monday May 02, 2016 @09:35PM (#11617202)
Regarding safety, we don't even need to call into question my competence with writing safe code :) ; Rust's borrow checker currently precludes a swath of perfectly safe programs. This isn't a knock on Rust; it just means it's not yet intuitive.
Re:Go best practices, six years in by catnaroek on Sunday May 01, 2016 @06:17PM (#11608106)
It's not just about performance, but also (perhaps primarily!) correctness: making sure that resources (not just memory) are freed in the right places, that your code won't try to use resources that have already been freed, that the same object can't be mutated by two or more parties at any single point in time, etc.
Re:Go best practices, six years in by takeda on Sunday May 01, 2016 @08:46PM (#11608582)
Rust really aims to be replacement for C. It allows you to program in low level, but you have much more powerful type checking and keeps track of ownership which reduces number of errors that plagued C language.

Yes go also claims to be C replacement, but probably the only similarity is its simplicity, but unlike C it is not as expressive.

Re:Go best practices, six years in by BuckRogers on Sunday May 01, 2016 @09:47PM (#11608758)
I haven't used Rust extensively, more Go for sure. But it seems to me that Go was aiming for simplicity more than being a true innovation. It's basically a compiled Python with type annotations and unfortunately a GC to spoil it all.

Rust was aiming at innovating and advancing the PL space with meaning. I can't say looking back the time I invested with Go was well-spent.

Rust is probably worth the effort if you have the need for what it offers. It just requires more out of you than Go does.

Re:Go best practices, six years in by MichaelGG on Sunday May 01, 2016 @08:25PM (#11608522)
I don't know a whole lot about C++, but I've worked on projects using C. Seems to me Rust is straightforward and just enforces what you have to do in your mind otherwise.

Once IDEs start coming around it should be quite competitive. I'll admit to thinking the same thing: I'll use Rust for the absolute critical parts, then F# for the rest. But more and more parts I'm writing are easy enough to do in Rust, and I get the perf as a bonus.