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

191–200 of 207 posts

Re: Go best practices, six years in

#191

Post by NateDad »

fludlight wrote: post #59
sudhirj wrote: post #3

Earlier quoted context omitted.

To vendor a dependency is to store a copy of all the source code you're trying to use inside your project itself. That way, when you compile your project, you also compile the code it depends on. Updating code you depend on is a semi-manual process - you choose to copy the latest version of the code you depend on into your project again. This is contrast to stacks like Java, where I can give you a pre-compiled JAR fi…

Is this different from statically linked libraries (as opposed to dynamically linked)?

This is about code, not libraries. Vendoring the code means copying it into your own repo... that way you're guaranteed that everyone who builds your project is building the exact same code, and if one of the third party repos disappears, your project doesn't all of a sudden fail to compile.

Re: Go best practices, six years in

#192

Post by raould42 »

tptacek wrote: post #183
nvarsj wrote: post #38

The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…

I'm sure this comment was written in good faith, but it doesn't belong at the top of this thread. It could be attached to virtually any post about Go . It barely engages with the actual post at all. Practically every other top-level comment below it is better. And, of course, it spawned a completely useless thread litigating Java vs. Go. Perhaps that's why it's at the top of the thread --- which means voting had a pe…

I think having a ui widget to let us fold sub threads would be great. I really don't enjoy trying to scroll past some giant thread I think is not interesting to me.

Re: Go best practices, six years in

#193

Post by setheron »

raould42 wrote: post #192
tptacek wrote: post #183

Earlier quoted context omitted.

I'm sure this comment was written in good faith, but it doesn't belong at the top of this thread. It could be attached to virtually any post about Go . It barely engages with the actual post at all. Practically every other top-level comment below it is better. And, of course, it spawned a completely useless thread litigating Java vs. Go. Perhaps that's why it's at the top of the thread --- which means voting had a pe…

I think having a ui widget to let us fold sub threads would be great. I really don't enjoy trying to scroll past some giant thread I think is not interesting to me.

There are chrome extensions that do this :)

Re: Go best practices, six years in

#194

Post by bbrazil »

dlor wrote: post #90
bbrazil wrote: post #84

Earlier quoted context omitted.

This defeats the purpose of a good flags library though. Where flags shine is when you've some obscure tunable deep in the dependency tree that you need to tweak (particularly in an emergency). Plumbing through potentially thousands of flags through to main is nonsensical in that scenario.

The flag libraries I've used always make this easy, but the problem comes in when you try to reuse that dependency in another binary as a library. Maybe you've seen a better flags library than I have, though.

No, the flags libraries I've used had exactly that issue.

When that came up what you'd do then is refactor that to be a class parameter or config option or whatever (and we'd usually ask that the flag be kept in some form).

Until then though you get the benefits of a quick and easy way to both expose and use tunables, which is much better than not having it at all.

Re: Go best practices, six years in

#195

Post by weberc2 »

ntonozzi wrote: post #73
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 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.

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

#196

Post by MichaelGG »

weberc2 wrote: post #195
ntonozzi wrote: post #73

Earlier quoted context omitted.

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.

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

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

#197

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.

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

#198

Post by weberc2 »

MichaelGG wrote: post #196
weberc2 wrote: post #195

Earlier quoted context omitted.

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

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

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

#199

Post by MichaelGG »

weberc2 wrote: post #198
MichaelGG wrote: post #196

Earlier quoted context omitted.

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

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.

Re: Go best practices, six years in

#200

Post by asdf1234 »

pjungwir wrote: post #137
brightball wrote: post #78

Earlier quoted context omitted.

At some point mid #3 I finally hit the "I think it's time to just learn Elixir for every situation where I don't need a portable binary..." So far, looking like a solid decision.

I'm looking to transition from Rails to something more performant. Phoenix is at the top of my list, but these benchmarks worry me: https://www.techempower.com/benchmarks/#section=data-r12&hw=... https://www.techempower.com/benchmarks/#section=data-r12&hw=... In both Phoenix has very high error rates, and in the first it seems really slow. Here is their Phoenix test app: https://github.com/TechEmpower/FrameworkBenchm…

There were problems with the benchmarks and nobody had time to fix them. This is usually the case when the benchmarks have high error rates and this has also happened in the past with Haskell, C# and F# libraries.
Post reply on HN