Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go best practices, six years in

peter.bourgon.org

Post reply on HN
Print view View original

201–207 of 207 posts

Re: Go best practices, six years in

#201

Post by weberc2 »

valarauca1 wrote: post #86
weberc2 wrote: post #62

Earlier quoted context omitted.

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 application…

>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.

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

#202

Post by kinkdr »

Looks a lot like a language designed by a committee, but I generally like it.

I don't love it, like I love Python, but it does its job and it is fast.

What I really like is the defer(), the channels(having the option for asynchronous channels would be awesome), the go routines(async callback hell is getting old).

What I find completely awkward however is the enforced first letter capitalization(don't tell me how to live my life, go!), the interface{}, and the GC.

Re: Go best practices, six years in

#203

Post by calcifer »

kinkdr wrote: post #202

Looks a lot like a language designed by a committee, but I generally like it. I don't love it, like I love Python, but it does its job and it is fast. What I really like is the defer(), the channels(having the option for asynchronous channels would be awesome), the go routines(async callback hell is getting old). What I find completely awkward however is the enforced first letter capitalization(don't tell me how to l…

I get - and agree with - the complaints about interface{}, but what's wrong with the GC?

Re: Go best practices, six years in

#204

Post by mmargerum »

ereyes01 wrote: post #143
dineshp2 wrote: post #6

Slightly tangential, but, could someone share their experience using Go specifically for building websites? How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel? Is building websites using Go a good use case or is Go better suited for building high performance microservices?

As you probably know (and as you can probably tell from some of the responses here), sometimes choosing languages can be like choosing a religion :-) As a backend for a web application, Go's performance is pretty great. The Go standard library comes with a fast parallel-enabled HTTP server that already makes use of all your cores in recent Go versions. No need for things like gunicorn to take advantage of cores. Ther…

The cost and pain of developing software is approximately zero compared to the operational cost of maintaining it over time

not my quote

Re: Go best practices, six years in

#205

Post by weberc2 »

MichaelGG wrote: post #199
weberc2 wrote: post #198

Earlier quoted context omitted.

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?

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.

> 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

#206

Post by kinkdr »

kinkdr wrote: post #202

Looks a lot like a language designed by a committee, but I generally like it. I don't love it, like I love Python, but it does its job and it is fast. What I really like is the defer(), the channels(having the option for asynchronous channels would be awesome), the go routines(async callback hell is getting old). What I find completely awkward however is the enforced first letter capitalization(don't tell me how to l…

And how could I forget, the multiple return values. Give me tuples, Go, don't give me multiple return values!

Re: Go best practices, six years in

#207

Post by kinkdr »

calcifer wrote: post #203
kinkdr wrote: post #202

Looks a lot like a language designed by a committee, but I generally like it. I don't love it, like I love Python, but it does its job and it is fast. What I really like is the defer(), the channels(having the option for asynchronous channels would be awesome), the go routines(async callback hell is getting old). What I find completely awkward however is the enforced first letter capitalization(don't tell me how to l…

I get - and agree with - the complaints about interface{}, but what's wrong with the GC?

No control over it. It will run when it decides to run, stalling my app.
Post reply on HN