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

71–80 of 318 posts

Re: Seven years of Go

#71

Post by [deleted] »

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.

[deleted]

Re: Seven years of Go

#72

Post by jerf »

fizzbatter wrote: post #28
greendragon wrote: post #18

Earlier quoted context omitted.

Curious what they weren't so happy about with Python? Was it purely performance? If so, did they consider PyPy, or at least profile what the slowest bits are so they can evaluate whether to throw everything out or just rewrite the slow bits? Was it the language itself? Not everyone likes dynamic languages, though it's odd they started with it. Did you consider Node at all?

Type safety mainly, i think. Performance is a definite concern, but they have a lot of internal applications and the stability of them varies. I offered up that less dynamic languages would provide more speed and reliability to boot. I know Python got types in 3.5, though i'm not sure if it has Go-like Interfaces (Traits in Rust). If not, i think it really should. I do firmly believe they'll be quite happy with Go th…

Python has always had Go-like interfaces in practice. The problem was that they were not reified into the code, so you had no easy way to know when calling a function and passing it a "file" exactly what file-like things the function was going to do with that "file" without reading the source code. You had to extract the interface yourself.

Re: Seven years of Go

#73

Post by neospice »

oelmekki wrote: post #62
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.

> 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. I have to assume those people did not first learn and use C, then went to assembly, but rather the opposite ;) So, the comparaison does not apply, here. > you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) I…

What are the typical trade-offs of outsourcing all the data manipulation & lookups to the DB. Are there cases when this is absolutely what you don't want to do?

I realize this is a very general and vague question but it's something I've been pondering about.

Re: Seven years of Go

#75

Post by junke »

gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

> I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options.

Such as?

Re: Seven years of Go

#76

Post by vram22 »

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?

>What is it being used for? HTTP servers?

Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too).

[1] This video that I blogged about:

Video: C++, Rust, D and Go: Panel at LangNext '14:

http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane...

has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright.

There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :)

Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently.

[2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did.

Edit: fixed typos, added a few points.

Re: Seven years of Go

#77

Post by Klathmon »

72deluxe wrote: post #63
Klathmon wrote: post #14

Earlier quoted context omitted.

I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can…

That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to wh…

Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed.

It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways.

It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical).

So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff).

I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.

Re: Seven years of Go

#78

Post by aikah »

sandGorgon wrote: post #60

has anybody evaluated building an api in Go vs Kotlin ? We are considering moving our financial tool api from python to either Go or JVM/Kotlin/JavaLombok+lambda . I really like Kotlin as a language.. but im really worried about the future. Jetbrains isnt Google.... I like Kotlin also because we are an app-based startup.. and we have been considering Kotlin on the app side as well. That would be a nice crossover of e…

> has anybody evaluated building an api in Go vs Kotlin ? We are considering moving our financial tool api from python to either Go or JVM/Kotlin/JavaLombok+lambda .

Obviously, take a second to compare Go ecosystem with Java's and you'll get the answer. Furthermore even if Jetbrains discontinue Kotlin, your libraries are still compatible with the rest of the JVM languages. So you loose really nothing.

Again what you should consider is the ecosystem and not the language. I wouldn't try to do data science in Go for instance, when Python or Java have stronger libraries in that domain.

Go is a nice outsider who is growing in spite of its issues because it's easy to pick up. But you should really try it out and see for yourself if its limitations aren't an hindrance for your domain problem.

Re: Seven years of Go

#79

Post by pcwalton »

Thaxll wrote: post #16
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

Choosing Rust in a shop where no one knows Rust is indeed a big mistake where in Go it's pretty easy to pick up the language quickly.

My experience is the exact opposite. Most of the people who I work with now using Rust did not know any Rust at the time they were hired. There haven't been any major problems at all.

Do you have experience that shows otherwise?

Re: Seven years of Go

#80

Post by didip »

fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

I solved channel without panic by doing channel bookkeeping in the main() entry point.

Wholeheartedly agree with you that channel panics a little too easily.

Post reply on HN