News for hackers. Stuff that matters.
Re:Go best practices, six years in by askyourmother on Sunday May 01, 2016 @04:38PM (#11607764)
Appreciate it was written as tongue in cheek, but I am glad that today a developer can start with Go, test, write code, build, deploy all with Go, whereas nearly every other ecosystem requires additional tools, often external competing tools. Then life becomes about having to learn whole new toolbekt before even coding.

Go still keeps it lean, and is great.

The fact it does not have hipster dev approved status is also an added bonus. The minute we see a bloated testing suite with yet another DSL, for Go, we are in trouble.

Re:Go best practices, six years in by spriggan3 on Sunday May 01, 2016 @04:47PM (#11607799)
> The fact it does not have hipster dev approved status is also an added bonus.

What are you talking about ? the hype is strong with Go. So strong devs are persuaded they need to use Go at all cost then complain Go has a garbage collector ( just go go-nuts mailing list).

So strong there are countless articles on the net about "How we moved from X to Go..." just like in 2007/8 with Rails.

> The minute we see a bloated testing suite with yet another DSL, for Go, we are in trouble.

GoConvey and co ...

Re:Go best practices, six years in by jkarneges on Monday May 02, 2016 @04:53AM (#11610054)
> So strong there are countless articles on the net about "How we moved from X to Go..."

Writing about Go is a great way to hit the front page of HN. I once saw 5 articles about Go on the HN front page at the same time!

Re:Go best practices, six years in by gizzlon on Monday May 02, 2016 @07:47AM (#11610617)
I don't think that's true anymore (?). HN has a well defined, very short, hype cycle.
Re:Go best practices, six years in by ddw on Monday May 02, 2016 @12:09AM (#11609154)
Except you can not use GoConvey and still write a quality test suite.

Plus GoConvey wisely separated the UI visualizer from the BDD, we use the former and not the latter.

Re:Go best practices, six years in by eternalban on Sunday May 01, 2016 @06:46PM (#11608198)
> just like .. Rails

Uncanny, isn't it?

Re:Go best practices, six years in by daurnimator on Sunday May 01, 2016 @08:05PM (#11608470)
> The fact it does not have hipster dev approved status is also an added bonus

Huh? In my experience Go is the most hipster dev language around at the moment.

Re:Go best practices, six years in by skj on Sunday May 01, 2016 @09:07PM (#11608636)
The insight here is that the "hipster" devs are always the ones who have strong opinions that you do not share.
Re:Go best practices, six years in by cikey on Monday May 02, 2016 @03:46AM (#11609795)
Seems more like Rust is the new hipster target if i count the recent hn posts about it...
Re:Go best practices, six years in by daurnimator on Monday May 02, 2016 @04:21AM (#11609938)
I don't think you can equate press coverage with hipster-ness.
Re:Go best practices, six years in by spriggan3 on Monday May 02, 2016 @05:36AM (#11610195)
How many articles a day about Rust on HN ? that's right, not as much as Go.
Re:Go best practices, six years in by takeda on Sunday May 01, 2016 @08:48PM (#11608584)
I would say it is second after node.js
Re:Go best practices, six years in by MichaelGG on Sunday May 01, 2016 @05:09PM (#11607875)
Rust has that built in, but managed to be a much more solid language (feature wise).
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.

Re:Go best practices, six years in by twic on Sunday May 01, 2016 @07:47PM (#11608387)
> The minute we see a bloated testing suite with yet another DSL, for Go, we are in trouble.

https://github.com/onsi/ginkgo