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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

161–170 of 235 posts

Re: A year with Go

#161

Post by nulltype »

djhworld wrote: post #152
coldtea wrote: post #146

It's amazing how Go caught on. It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc. It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years). It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling. My theor…

> It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I find the level of sneery nose turning in this thread quite abhorrent to be honest.

There seems to be an idea that some ways of telling your computer what to do are too foppish and that if you are serious about it you use a language from 40 years ago. Of course that's probably what the assembly programmers said about C and there aren't many of those left anymore.

Re: A year with Go

#162

Post by masklinn »

mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit.

Java has multiple native code compilers, how is it a benefit when Java can do the exact same thing? (FWIW I learned recently that C# also has at least one native code compiler).

Re: A year with Go

#163

Post by masklinn »

twic wrote: post #77
xrstf wrote: post #70

Earlier quoted context omitted.

Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better. But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)…

One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?

No, it's an unhelpful thing about HN having a terrible partial subset of markdown: ignoring that every other markdown implementation under the sun has more supported markup, all of them provide ways to escape markup characters and inline code sections which ignore markup characters.

Re: A year with Go

#164

Post by masklinn »

webkike wrote: post #26
heinrich5991 wrote: post #25

Earlier quoted context omitted.

You can do that by storing `Box ` in your vector. In fact, that's the equivalent of what Go does in your example.

That's fantastic to know. I might just switch back to rust because of this.

If you have known lifetimes, you can also use &Trait (and lifetime variants thereof): http://is.gd/4SyShN

For more information on that, check out "trait objects" (http://doc.rust-lang.org/book/trait-objects.html).

The gist of the issue is this: a Vec (and most other collections) needs all items to be sized and of the same size in-memory to lay itself out (know how much memory to reserve for each item for instance), and it stores its stuff inline. So a Vec's buffer looks like this:

    [u8|u8|u8|u8]
and a Vec for a struct { u8, u32, u8 } looks like this (ignoring padding):

    [u8,u32,u8|u8,u32,u8|u8,u32,u8|u8,u32,u8]
If you want to store both A and B inline in a Vec you've got trouble: that they both implement Foo doesn't mean they have the same size at all (and they often don't), and Rust's type system doesn't allow it anyway (`A: Foo` says that A implements Foo, but the function or collection still gets an A via reification and monomorphisation).

The alternative is to do what languages Java or Go do under the covers: add a fixed-size pointer as indirection between the collection and the actual items (the pointer is actually fat, you get a pointer to the instance itself and a pointer to the vtable for the trait implementation, I think Go does the same but java doesn't as each instance has its classpointer), so you get e.g.

    [&A|&A|&B|&A]
all pointers are the same size and things work out. More generally than trait objects, you need to do this to store any unsized type (http://doc.rust-lang.org/book/unsized-types.html) in something which only accepts sized types.

Re: A year with Go

#165

Post by masklinn »

eloff wrote: post #10
Arzh wrote: post #2

The point isn't about learning something new. It's about trying to apply those things into a language they think is easier to work with.

I'd argue the point is the opposite of learning new things. As the Go team themselves say, Go is an engineering project. It's about sticking to well understood, well defined ideas that allow large teams of typical skill to develop and maintain good software. Go is boring compared to some other languages that push the envelope and try new things. But that can be a good thing if you start thinking like the business own…

The problem is that Go doesn't use things which are well understood and well defined now (or were so 6 years ago when Go was released), it stopped its (partial collection) about 40 years ago.

Re: A year with Go

#166

Post by Dewie3 »

jerf wrote: post #65
matthewmacleod wrote: post #34

Earlier quoted context omitted.

In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways. As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full o…

"code is often needlessly repetitive and obtuse to write." I think it helps to remember that Go's use case is a lot of teams interacting to produce fairly large code bases, i.e., at Google. I'm getting into it for my job because it has the same use case, and I find it hits a nice sweet spot in what you can do, vs. what you can't do, and I happen to be in a position in which I am routinely hit hard by other people's "…

The Java approach to larger-scale programming.

Re: A year with Go

#167

Post by lazyjones »

dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

> now an article like this is almost unanimously upvoted (without much contrarian discussion(!))

The HN guidelines were changed (or defined more precisely...) and many people might shy away from posting negative comments about submissions.

I have to compliment the author on omitting complaints about lack of generics.

Re: A year with Go

#168

Post by amaranth »

sdenton4 wrote: post #154
threeseed wrote: post #137

Earlier quoted context omitted.

How so ? It takes minutes to install it. Just download it, copy it and set JAVA_HOME to make it easier for other applications. I've done this on hundreds of servers during my lifetime and never once had an issue.

Oh, look, there's already an antique jre installed on my os, not compatible with the particular jre needed by this application, which I first need to uninstall. And then hope that it doesn't break anything else in the process, because I haven't been following the minutae of java development environments for the last n+1 years... I think it falls solidly in the "easy if you know it, and a wasted q hours if you don't"…

That's why he said to set a JAVA_HOME so this JRE can exist separately from the system one.

Re: A year with Go

#169

Post by Dewie3 »

NateDad wrote: post #126
dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

Most Gophers just get tired of defending against the same arguments over and over. At least this guy actually used it for more than an afternoon... Though anyone who says they don't understand go's pointers after that length of time is a somewhat questionable source. I've been using go full time for two years and love it.

> Most Gophers just get tired of defending against the same arguments over and over.

Tip: you're not required to be a defender/evangelist.

Re: A year with Go

#170

Post by samora »

I think a lot of us miss the Go point.

There is nothing special about Go. It's simple and just works.

Every time I used Go for a project it just worked. No fuss. With very little effort. And that's the point.

Post reply on HN