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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

181–190 of 402 posts

Re: The State of Go

#181

Post by Groxx »

dilap wrote: post #171
Groxx wrote: post #124

Earlier quoted context omitted.

It's mostly-impressively backwards compatible, I'll definitely agree there. It's clever, and in many cases it'll do the right thing automatically. Since it seems that's their goal, they achieved it quite elegantly, and that's a tricky thing to do. (edit: and quite quickly! seriously, this is an example of a healthy community at its best) But personally I don't agree with the decision - it adds surprises when you try…

There's no denying it's at least flirting with "too clever" territory. What saves it for me is (1) the analysis of a large body of code that seemed to show only positive impact (2) that the behavior is well-documented and (3) anytime you're converting between types, you should always be thinking, "what is the range of these types? what information might get lost?", which with (2), should leave you alright. But, I cou…

"Should", definitely :) Easier said than done. But I'm happy to wait and see, it's not like this would make Go the only language with weird time handling. As it stands they're probably in a better place than most people are used to.

That code-corpus-analysis is pretty neat, I hadn't looked through in detail before. Thanks for pointing it out!

---

Sorta as an aside, it seems the proposal can lead to:

  t1 = time.Now()
  ...
  t2 = time.Now()
  diff = t2.Sub(t1)
  t1.Add(diff) != t2
Times are hard :|

Re: The State of Go

#183

Post by reikonomusha »

spion wrote: post #84
MichaelGG wrote: post #65

Earlier quoted context omitted.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

Thats not a strength of Go. Structural interfaces, channels and performant M:N green threads are its main strengths, and AFAIK there is no other language that provides a similar combination in a familiar C/ALGOL-like packaging. If such a language existed and had generics and Swift or Rust style error handling as well as some backing by a large-ish corporation / organization, I think that language would be preferred t…

I feel like maybe 10 years ago no one would utter something like "C# needs ADTs" because they didn't have mainstream appeal, despite computer scientists' understanding of them.

Re: The State of Go

#184

Post by geoka9 »

kuschku wrote: post #161
geoka9 wrote: post #101

Earlier quoted context omitted.

> Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken) That's it. I think OP just assumed panics in Go are what exceptions are in other languages.

Because the stdlib is using them more and more? As someone mentioned, even closing an already closed channel can panic. Calling the random number generator with a negative limit panics. And there’s nothing like checked Panics so you’d know if one will happen or not.

I see nothing wrong with that - those _are_ fatal conditions that indicate that something is dangerously wrong in the program.

And those panics do give you a helpful stack trace, complete with source code line numbers, so it's easy to find the culprit (as opposed to "bubbling up" exceptions).

Re: The State of Go

#185

Post by Paradigma11 »

hota_mazi wrote: post #150
seagreen wrote: post #136

Earlier quoted context omitted.

Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I doubt I have any more depth than you as a programmer, but I've gone one step farther than you down the language safety progression, so maybe my thoughts from here will be interesting. When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. There are a lot of silly thing…

> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.

The type system is an integral part of the language.

Re: The State of Go

#186

Post by zzzcpan »

Buttons840 wrote: post #167
labrador wrote: post #41

Earlier quoted context omitted.

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

I've been thinking about a two way compiler with a primary focus on producing readable code. If such a compiler targeted Go or Java, you could white your "Go+" code (for lack of a better name) in a higher level language with more features, and have it compiled to readable Go code. I don't know to what extent this is possible, but if it was good enough you could be a Go developer while rarely writing actual Go code.

It is very much possible, there are already DSLs that generate Go code. I'm even doing that myself.

Re: The State of Go

#187

Post by riprock »

I've never used Go, but would you write your customer facing REST service using Go? Or would it only be used for back-end microservices? What's a recommended library for writing a customer facing REST API?

Re: The State of Go

#188

Post by yawaramin »

spraak wrote: post #121

I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.

You may be interested in https://facebook.github.io/reason/

They have an active community that is very engaged in improving the entire developer experience. Plus ReasonML is just OCaml under the (new syntax) hood so you have decades of OCaml expertise and libraries to draw on. In case that's not enough, it also deploys to JavaScript and targets the npm ecosystem, so you also have the entire npm package collection at your disposal.

Re: The State of Go

#189

Post by chimeracoder »

yawaramin wrote: post #180
chimeracoder wrote: post #74

Earlier quoted context omitted.

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ... It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

> It's not a criticism

I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism.

> it's literally how the Go language creators themselves describe it. See the Rob Pike quote

Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same things that excite researchers about programming languages don't lend themselves to good software engineering in industry. (And he's right).

But regardless of what the creators of the language may have intended, I'm saying that the criticism regarding experience with functional languages is flat-out wrong. I've written more code in various functional languages than the overwhelming majority of people who read this site - both on and off the clock - and I'm testifying that yes, even for someone who has deep experience with functional language of both the Lisp and the SML families, Go still has a lot to offer that very few others do.

Re: The State of Go

#190

Post by notfreeyet »

Cyph0n wrote: post #119
shurcooL wrote: post #106

Earlier quoted context omitted.

It's `present`, a very simple tool. Written in Go, open source. Using it is a choice. I agree its ability to work on mobile is limited and that could use a CL (or a few) to improve. https://godoc.org/golang.org/x/tools/cmd/present

A beautiful example of NIH syndrome in the real world.

It's an example of someone quite effectively solving their own problem in a couple hundred lines of code. That it's flawed in ways that are not part of its original use case is irrelevant.

NIH is a problem when you spend a lot of time creating inferior solutions to solved problems. Not when you spend a tiny amount of time solving your own problems very effectively for years...

Post reply on HN