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

101–110 of 402 posts

Re: The State of Go

#101

Post by geoka9 »

cube2222 wrote: post #69
candiodari wrote: post #59

Earlier quoted context omitted.

In reality Go makes it worse, if you truly keep track of all possible cases. After calling a method, in Go you have to 1) "if err != nil" after every statement 2) give some serious thought to whether the previous statement could panic or not Good luck if it's a library call that may get updated or call other libraries ! 3) Think about the non-error error cases that can't be abstracted out. Go is like C, in the sense…

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) You should really use a library like github.com/pkg/errors so you get to wrap the error you return with additional information. Errors are just a worse Either monad after allm they're much more pleasant to us…

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

Re: The State of Go

#102

Post by [deleted] »

jrs95 wrote: post #76
hepta wrote: post #47

Earlier quoted context omitted.

What are your problems with spring boot? What bloat are you referring to?

I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that. The autoconfiguratuon was also a…

[deleted]

Re: The State of Go

#104

Post by randomdata »

labrador wrote: post #41
greg7mdp wrote: post #38

Earlier quoted context omitted.

How can you write an efficient container without generics?

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

I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.

Re: The State of Go

#105

Post by geoka9 »

coldcode wrote: post #32

I for one will be more interested in using Go when Jetbrains finishes their IDE. Clearly not everyone cares to develop in an IDE but after 33 years of doing it, I prefer the idea. Give Swift (my current work) as many years as Go has had (10 years), and maybe I won't find Go that interesting any more.

To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.

Re: The State of Go

#106

Post by shurcooL »

throwaway91111 wrote: post #78

Man I really wish they would stop using whatever crappy presentation software this is; it NEVER works well on mobile.

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

Re: The State of Go

#107

Post by spraak »

thewhitetulip wrote: post #52
joaodlf wrote: post #14

I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…

I agree with you, I didn't know how to build a webapp, two years ago, I learned the basics and implemented a fully working webapp in Go along with the REST client, all without having to buy a single book, the docs are amazing, the community is amazing and the language made me build things fast, I love GOPATH, I love gofmt. Apart from the tooling, I felt as if I have been writing Go since a long time, even though I wa…

I am really glad for that guide. I came across it last week and really appreciate the methodology (i.e. an anti-textbook) thank you for that.

Re: The State of Go

#108

Post by geoka9 »

rpercy wrote: post #39
coldcode wrote: post #32

I for one will be more interested in using Go when Jetbrains finishes their IDE. Clearly not everyone cares to develop in an IDE but after 33 years of doing it, I prefer the idea. Give Swift (my current work) as many years as Go has had (10 years), and maybe I won't find Go that interesting any more.

I've been using the Gogland beta for the last few weeks and it's been quite stable. For large codebases, it's hard to beat a good IDE's ability to quickly jump between symbols (go to definition, find usages, etc).

Check out godef/guru - they let you do all those things (and more) in a text editor.

Re: The State of Go

#109

Post by dilap »

Groxx wrote: post #88
dilap wrote: post #81

Earlier quoted context omitted.

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…

I dunno... in some ways, the problem is that they didn't think it through to begin with, and chose something widely-known-to-be-ambiguous-and-problematic like "time.Now()", instead of choosing unambiguous names / structures from the start. It's kinda the equivalent of making a new language (nowadays) and not defining what encoding your native strings use. Of course it's going to cause problems. Except the timer issue…

Fair point! And I certainly don't claim that the Go devs don't make mistakes. They started with the theory that the problem should solved as Google does, by arranging that clocks don't run backwards. When it become clear that wasn't reasonable, they moved towards a new solution in a way that I felt was impressive.

Re: The State of Go

#110

Post by Qerub »

jrs95 wrote: post #76
hepta wrote: post #47

Earlier quoted context omitted.

What are your problems with spring boot? What bloat are you referring to?

I suppose most of my negative experiences with it are specifically in the context of using it to build microservices. The memory usage alone created a bit of a problem, I ended up using nearly all of my 16GB of RAM when I had to run many services simultaneously. And because the functionality of any given service was fairly minimal, there really wasn't a need for a framework like that. The autoconfiguratuon was also a…

I usually get rid of @EnableAutoConfiguration and then selectively import the auto-configuration classes I actually want with @ImportAutoConfiguration.
Post reply on HN