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

151–160 of 318 posts

Re: Seven years of Go

#151

Post by Manishearth »

weberc2 wrote: post #126
Manishearth wrote: post #45

Earlier quoted context omitted.

A lot of this comment resonates with my experience and views :) > You'll note that i didn't list Generics. I know that's high on peoples list, but not mine This is me too. Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almo…

You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.

That only works well if each "variant" holds the same kind of thing. If not, you have to store them one after the other (space wastage), or use interfaces to store them in the same place (tag isn't necessary anymore, extra boxing).

Rust enums (ADTs) aren't like Java enums where each variant contains the same kind of data.

Re: Seven years of Go

#152

Post by mmmBacon »

I've had a little exposure to Go and seen how rapid development in Go can be while still maintaining decent performance.

Is anyone aware of scientific stack development in Go? Specifically, does HN think thee will be a Numpy or Scipy equivalent in Go or does this not make any sense?

Re: Seven years of Go

#153

Post by pcwalton »

weberc2 wrote: post #146
pcwalton wrote: post #134

Earlier quoted context omitted.

I'm not interested in debating which language is easier to learn for C++ programmers. I'm pushing back against the (clearly false, IMO) idea that adopting Rust is a mistake .

In the context of the conversation, adopting Rust over Go is a mistake for the majority of applications primarily because of the difference in learning curve . Of course there are other factors, and not all applications are equal. I threw in my C++ background to demonstrate that I'm quite capable of thinking in the low-level terms demanded of Rust programmers, and my learning curve was still very large. You can disag…

I don't agree that the learning curve difference (which is a temporary cost that decreases over time) is high enough to outweigh the benefits in the "majority" of cases that could benefit from Rust (and reap those benefits long-term). I respect your experience, but it doesn't invalidate mine, which has held up with many people I've seen get up to speed with Rust.

Re: Seven years of Go

#154

Post by stcredzero »

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 find this interesting. Are there examples around, or a blog post discussing this?

Re: Seven years of Go

#155

Post by dbaupp »

weberc2 wrote: post #126
Manishearth wrote: post #45

Earlier quoted context omitted.

A lot of this comment resonates with my experience and views :) > You'll note that i didn't list Generics. I know that's high on peoples list, but not mine This is me too. Been programming in Rust for 3 years, and picked up Go two years ago. I like the language; I like how it feels like "C but safety net". I haven't used it for anything important (course projects a bit), but this is because so far Rust works for almo…

You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.

That approach has its own problems, such as wasting memory (need to store any data for each tag value separately, rather than benefiting from overlapping storage ala Rust enums or C tagged unions), as well as losing type safety: one has to manually remember which (groups of) fields correspond to which tag values (although the Go loss of type safety is far better/more controlled than the one for C tagged unions). Using interfaces has neither of these problems.

Re: Seven years of Go

#156

Post by weberc2 »

pcwalton wrote: post #129
weberc2 wrote: post #113

Earlier quoted context omitted.

Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. No, there's a lot more. See my reply to your sibling comment. > I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C. This argument doesn't make any sense to me. Why is being better than a language fr…

> No, there's a lot more. See my reply to your sibling comment.

Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety?

> Why is being better than a language from 1978 our sole criterion?

I have no idea. Thankfully no one made any such argument.

> Shouldn't we try to make our software as reliable as possible?

No, we should make it sufficiently reliable. For example, many applications might not benefit from Rust's pedantic checking of data races (e.g., if the application is sequential), but the impact on development velocity could be prohibitive. By the by, I like Rust, I just think it's not well-suited for most applications.

> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

While I absolutely agree, this isn't incompatible with my claim, that Go is at least as safe as C, and thus safety alone doesn't preclude Go from safety critical applications.

Re: Seven years of Go

#157

Post by stcredzero »

richard_todd wrote: post #70
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 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 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 problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

Re: Seven years of Go

#158

Post by krylon »

I remember reading the initial announcement. I looked at the language briefly, and found some of the syntax too weird.

A few years later, I looked again and discovered I actually liked it very much. Still do. I mostly use it for toy programs I write in my free time, but I find that Go is very compatible with the way my mind works. I am currently trying to use Go at work for some of the tasks I usually would use Perl for. The fact that it comes with a relatively nice templating engine in the standard library makes it very attractive to replace the CGI scripts that have piled up over the years.

Interestingly, I had pretty much the same experience with Python - at first, I disliked the syntax ("no Dutch person is telling me how to indent my code!"), but then I came back a couple of months later and found that I really liked the language. (wrt indentation, Python only forces me to do something I would do anyway, it just took me a while to understand that.)

Re: Seven years of Go

#159

Post by jasonwatkinspdx »

drej wrote: post #47

My 2c: Go is incredibly convenient for non-programmers. I don't make a living writing software, I make a living answering quantitative questions, using computers. I use Python for most tasks, but when I need extra performance and/or portability, I grab Go every single time. The main appeal is the quality standard library that covers most things I get in contact with. I could get immersed in it right away, because I d…

Not only are you a programmer, you are clearly more aware and capable than many, many, people who consider themselves professional programmers.

Re: Seven years of Go

#160

Post by grayrest »

olauzon wrote: post #143
brandur wrote: post #41

Earlier quoted context omitted.

I've taken a very similar path recently myself and started looking into Rust. > 2. Proper error handling. I love error checking Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable. Rust's `Result` type, `try!` macro, and pattern matching are an inc…

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry). Does Rust really have an "incredibly high barrier to entry?" I've been using Rust for a few months, and just deployed my first high-throughput application a month ago, and my experience has been the opposite. Yes, the first couple of weeks were a bit rough while I was getting us…

> Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace.

This is the very definition of "high barrier to entry". Clearly it wasn't too much of a barrier for you but I can see how it'd be an issue for people. I'm expecting editor support and wider adoption (differently constructed tutorials, SO answers) to lower this barrier. I think Rust has the potential to be very popular, particularly if the reputation shifts from "high barrier to entry" to "slightly harder to get started but fewer problems in production".

Post reply on HN