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

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

351–360 of 367 posts

Re: Go 1.6 is Released

#351

Post by codygman »

pjmlp wrote: post #346
johan_larson wrote: post #335

Earlier quoted context omitted.

I fear you are right. Go's simplicity, its pattern of having one and only one way of doing anything, is likely a product of its youth and unpopularity. As the years pass and its following grows, people will come along who want to do things differently, and the ecosystem will become richer but also more confusing. Perhaps the best thing for the language would be for it not to become too popular.

Avoid success at all cost. -- Haskell

It should be read:

Avoid (success at all cost)

Rather than what you might be (others do at least) implying:

(Avoid success at all cost)

Re: Go 1.6 is Released

#352

Post by codygman »

pori wrote: post #306
cies wrote: post #283

Earlier quoted context omitted.

> It seems the landscape for functional alternatives are mainly Scala and Clojure Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option. Finally there's Rust, which is besides being a bit more functional also more low-level than Go. While being fairly young,…

Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by. I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.

> Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it.

That's the same as saying:

Well, I was tempted to mention Go. Problem is, I haven't found a practical use for it.

That is to say, just pick a problem and try to use Haskell to solve it. 90% chance it will fit your niche fine.

Re: Go 1.6 is Released

#353

Post by conceit »

munificent wrote: post #330
prodigal_erik wrote: post #309

Earlier quoted context omitted.

Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.

> Use the platform's blessed solution (rpm or dpkg). Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or user, you don't get to use our language." Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you can , you just want have any users…

But it makes sense if half the configuration (or what not you expect from a package) is platform specific, like where do the libraries and resources live, does pip know about the windows registry? I doubt it.

Re: Go 1.6 is Released

#354

Post by tptacek »

cdelsolar wrote: post #225
kasey_junk wrote: post #54

Earlier quoted context omitted.

There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alt…

abysmal tooling? ... extremely primitive concurrency support?? Are you talking about Go?

No fully-functional debugger. Minimal instrumentation. No good code transformation or refactoring tools. No concurrent data structures.

Re: Go 1.6 is Released

#355

Post by infogulch »

lobster_johnson wrote: post #314
infogulch wrote: post #313

Earlier quoted context omitted.

iirc, the decision to disallow unused imports was largely motivated by improving build times. And not just for your package either. If each package in the tree can accidentally have an extra import or two it could end up ballooning to crazy proportions where everything and their third cousin is imported with only some of them being used. That's what I remember from reading about it.

But that concern is about releasing , which is completely orthogonal to building . Go conflating the two is, I think, its biggest design mistake on the build system side. In Go, dependencies are inferred from imports, which, since it can't express versioning information, leads precisely to this sort of problem. It makes sense only if you're putting all of your dependencies in a single versioned work tree, but almost…

What are you talking about? How is unused imports related to library versioning? And how is focusing on improving build times orthogonal to "building"? The concern with build times is to make building while developing faster [0], how is that related to "releasing"?

Your points are tangential at best, and nonsensical otherwise.

[0]: http://mortoray.com/2015/05/06/fast-build-turnaround-time-is...

Re: Go 1.6 is Released

#356

Post by lobster_johnson »

infogulch wrote: post #355
lobster_johnson wrote: post #314

Earlier quoted context omitted.

But that concern is about releasing , which is completely orthogonal to building . Go conflating the two is, I think, its biggest design mistake on the build system side. In Go, dependencies are inferred from imports, which, since it can't express versioning information, leads precisely to this sort of problem. It makes sense only if you're putting all of your dependencies in a single versioned work tree, but almost…

What are you talking about? How is unused imports related to library versioning? And how is focusing on improving build times orthogonal to " building "? The concern with build times is to make building while developing faster [0], how is that related to " releasing "? Your points are tangential at best, and nonsensical otherwise. [0]: http://mortoray.com/2015/05/06/fast-build-turnaround-time-is...

You clearly didn't read what I wrote.

First, Go doesn't have any concept of "releasing". "go get" just (1) just grabs the latest HEAD from whatever repo you're using, and (2) follows import paths. It doesn't even use release tags.

So the "build times are affected by unused imports in dependencies" problem only exists as a hypothetical issue because "go get" implicitly trusts dependencies' import statements.

Other package systems don't do this. They (RubyGems and NPM are good examples) require that you build a release that you then publish. Included in such a release is a dependency manifest (Gemfile.lock, npm-shrinkwrap.json) that the package manager can read.

The more natural solution is to generate a dependency manifest at release time that only includes valid imports, and refuse to release something that contains unused imports.

The build time issue only exists locally if you run a monorepo like Google's, and in that case it's my opinion that, just like code linting, this is your own concern, not something to pollute an entire developer ecosystem with.

Re: Go 1.6 is Released

#357

Post by fuddle »

oofabz wrote: post #247
fuddle wrote: post #150

Go is great, but I wish they would add terany operator support.

They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.

Which is more simple, an if/else block or a terany operator?

if/else:

if i == 0 {

   return "foo"
} else {

   return "bar"
}

terany:

return i == 0 ? "foo" : "bar"

Re: Go 1.6 is Released

#358

Post by zelcon5 »

sinatra wrote: post #5

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…

> generics

Go makes it easy for third party applications to parse the language,so generics are possible with pre-processing/codegen; e.g., https://clipperhouse.github.io/gen/

Re: Go 1.6 is Released

#359

Post by thebaer »

prodigal_erik wrote: post #305
thebaer wrote: post #188

Earlier quoted context omitted.

I'm sure there are good uses for it, but I personally haven't found one yet. I mostly use Go's multiple return values to also return errors -- and that's really like using checked exceptions in Java. So whether it's a try/catch or an if statement, you have to code for these things one way or another.

A try-catch block can cover many complex statements and pushes the recovery code down where you aren't forced to continually reread it. Even if it's possible to write concise Go, nobody seems to be interested in trying, it always seems to become a mess that spends 2/3 of its time on errors.

¯\_(ツ)_/¯ I'm personally a fan of the style, and like explicitly seeing where the fault points in functions are, rather than having to memorize what exceptions might get thrown by what. But it can definitely cover many complex situations.

That sucks to see people making a mess with error handling code, but there are examples of good uses out there. This [0] is one I quickly found.

[0] https://github.com/schachmat/wego/blob/master/we.go

Re: Go 1.6 is Released

#360

Post by pjmlp »

grey-area wrote: post #273
pjmlp wrote: post #238

Earlier quoted context omitted.

The team has already stated "The language design is done".

The issues list has a bunch of breaking changes they've put off to Go2. It won't come soon, but probably at some point they will produce a Go2, if only to fix a few small annoyances and things they got wrong in the stdlib which would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will introduce lots of huge changes to the language, I doubt very much it would, but it probably will happen sometime. ht…

Update to my reply.

"So… when is Go 2?", Slide 38

"No plans. Maybe never.", Slide 39

https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...

Post reply on HN