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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

101–110 of 318 posts

Re: Seven years of Go

#101

Post by tptacek »

jryhurst wrote: post #87
tptacek wrote: post #61

Earlier quoted context omitted.

Even writing Postgres functions, you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) over and over again. People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it.

We prevented the grossness of writing things over and over again by just using Golang's script generation and some other stuff. http://github.com/spacemonkeygo/dbx .

I wrote something very similar, but this is exactly what I mean by writing 40% of an ORM.

Re: Seven years of Go

#102

Post by weberc2 »

wyager wrote: post #91
be_erik wrote: post #3

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

How is Go safer than, say, Java? It doesn't really do anything particularly useful or interesting on the safety front; it's type system is weak, it has null pointers, its error management mechanisms are mediocre.

It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).

Re: Seven years of Go

#103

Post by AsyncAwait »

weberc2 wrote: post #92
richard_todd wrote: post #70

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

Re: Seven years of Go

#104

Post by thewhitetulip »

aikah wrote: post #68
sethammons wrote: post #43

Earlier quoted context omitted.

One of my biggest complaints about ORMs is that I often know the exact query I need to write, and it is a pain to compose it with the ORM. Simple CRUD, sure, maybe. Beyond that though... Arguably one of the biggest benefits of an ORM is sanitization. You get that for free with Go. I've done quite a bit of work with DBs and Go, and I've not seen the need for an ORM, just some library helpers.

> You get that for free with Go You get that for free in any language that allows you to pass parameters to a query. There is nothing Go specific. > One of my biggest complaints about ORMs is that I often know the exact query I need to write, and it is a pain to compose it with the ORM. I agree that ORMs are often their own DSL one has to learn, when SQL is already there. In that sense they are opaque. Yet ORM still…

I have written a small webapp in Go while learning it and I didn't use an ORM, but the feedback I got from reddit is that at some point in time I'd need to use an ORM. What are your thoughts on the usage of ORM? +ve points vs -ve points?

Re: Seven years of Go

#106

Post by AsyncAwait »

be_erik wrote: post #3

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

> strikes the right balance for me between productivity and safety.

Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it?

Genuinely curious.

Re: Seven years of Go

#107

Post by pjmlp »

weberc2 wrote: post #98
wyager wrote: post #89

Earlier quoted context omitted.

> what it does couldn't possibly be done in e.g. Python What can you do in Go that you can't do in other languages? I can't think of anything. The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives, but you also lose a lot of expressive power.

Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything t…

C++17 gives you async/await, coroutines and parallel algorithms.

Re: Seven years of Go

#108

Post by thewhitetulip »

pvsukale3 wrote: post #85

Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.

Jumping to a framework without understanding how internals work is a bad thing. Also, experience is everything, eventually you'll get a hang of it.

It is not a barrier, you might like the intro book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook... and https://github.com/astaxie/build-web-application-with-golang...

Re: Seven years of Go

#109

Post by pcwalton »

didip wrote: post #66
tptacek wrote: post #33

Earlier quoted context omitted.

Strong, strong disagree on the idea that ORMs aren't necessary because of some property of Golang itself. Lack of decent ORMs is probably my biggest complaint about Go, and I think if you look at a lot of large web app packages you'll find people are all writing their own 40-60% of an ORM.

Wrapper functions are not the same as full blown ORM. For every heavily used ORM features, there's an opportunity to fall into a trap, e.g N+1, because the surface area of an ORM is wide. In contrast, wrapper functions are low cost, easy to write, and recognizable because you write them yourself.

> In contrast, wrapper functions are low cost, easy to write, and recognizable because you write them yourself.

Isn't saying that you should use functions that are "recognizable because you write them yourself" basically saying "you shouldn't use libraries?" This seems like the obvious NIH fallacy.

Re: Seven years of Go

#110

Post by Matthias247 »

72deluxe wrote: post #64
dilap wrote: post #19

Earlier quoted context omitted.

I love Go and think it could be good in this area, but so far as I know no one is using it for any serious GUI work (yet?).

What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?

IMHO Go is a good choice for lots of system daemons and commandline tools. If networking is involved it shines even more.

> 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?

You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in that, C# for Windows (Winforms and WPF) and Java for cross-plattform GUI applications.

Post reply on HN