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

Go 1.4 is released

blog.golang.org

Post reply on HN
Print view View original

241–250 of 265 posts

Re: Go 1.4 is released

#241

Post by topstarnetwork »

simias wrote: post #148
xrstf wrote: post #92

Damn, another project giving up on Mercurial and switching to Git. :-/ A few more major ones and basically nobody is using Mercurial anymore. How sad.

I've favored hg over git for a long time but I gave up that fight a few months back: I mostly use git for all my new code now. I think the DVCS "war" is nearing an end and git pretty clearly won it, for better or worse. Still, it's great we've had all this DVCS craze in the past years, we ended up with great open source tools that improved a lot over the CVS/SVN of yore.

Hello, I fund your c web development coment very intresting, as far as developing a website in c instead of php and as I was looking for a c - c++ freelancer would you be intrested for some work? my email is tatzianarose@hotmail.com thanks

Re: Go 1.4 is released

#242

Post by ajuc »

ajuc wrote: post #181
tormeh wrote: post #138

Earlier quoted context omitted.

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

Inheritance as taught in OO courses (deep class hierarchies) is bad most of the time. We can save 100 lines of code there by coupling 2 slightly related things forever (and arbitrarily choosing this criteria for division as the most important). I've made game before I knew OO programming. I haven't knew it then, but I used Interpreter Pattern - there was data model, with a list of records, each record had some enums…

@vegedor you are hellbaned I think. I can't respond to you and your post is grey.

I wrote the OO game in C++, but I avoided multiple inheritance, because there were warnings everywhere: "don't use multiple inheritance". And I don't think it would be much help in the end.

Another thing inheritance doesn't solve - when you want to choose which logic should run on your "object" depending on dynamic conditions.

For example I had ParticleEffect abstract class, Smoke and Fire derived from it. Fire reacted differently to collisions with stuff, than smoke. Fire partices were smaller with each frame to simulate flames, smoke was getting bigger and more transparent with each frame to simulate, well, smoke.

Then I wanted to make fire that turns into smoke after a couple of frames.

Solution 1 - merge both classes, make enum field inside, switch it after a couple of frames [not OO design - behaviour depends on fields not on classes]

Solution 2 - destroy fire object after a couple of frames and create new smoke object in its place [unnessesary allocation and deallocation is bad in games, also this complicates identity - for fire and smoke it doesn't matter, but for player and bullets it's important - I need to ensure player isn't hit by bullets he shoot, that's achieved by keeping "parent" pointer in each object, when the player is recreated because he got new behaviour - all the pointers are wrong and need to be updated].

I can't change class of object dynamicaly, so all the OO divisions are static in time, I have to workaround class hierarchy to model my problem correctly.

Another thing - in collision detection, the logic to run should depend on both colliding objects types, and some of their fields. With OO I have to workaround this again (because most OO languages are single-dispatch).

Another thing - OO data is much harder to serialize. Structural data allows banal serialization. This is solved in some languages (like Python or Java) by providing serialization in the core language, but in C++ or javascript serializing arbitrary object graph correctly is nontrivial. Serializing list of records was trivial even in Turbo Pascal ;)

Re: Go 1.4 is released

#243

Post by xrstf »

rnhmjoj wrote: post #167
xrstf wrote: post #92

Damn, another project giving up on Mercurial and switching to Git. :-/ A few more major ones and basically nobody is using Mercurial anymore. How sad.

I have never use hg. I don't really see much difference. What do you like about it?

I like the simplicity and the better Windows support. Many things in git rely on you having a powerful shell, which is not the case on Windows (who wants to use cygwin all the time?).

In Mercurial I never lost a commit, even as a beginner. In git I managed to accidentally make commits unreachable (yes, I know how to recover, but still, it tooks a bit of googling and trying).

I very rarely need git's "remotes" feature. There's rarely a need for me to know where someone else's master is at the moment. I understand why git is doing this and I get that it's pretty flexible, but most of the time Mercurial's simple branching model is enough for me (I don't like bookmarks, they confuse the hell out of me).

Also, my repositories are usually small enough that I don't notice the Python overhead compared to Git. My ultra slow old disk is more of a problem in that case.

Mercurial's help is MUCH better than git's. Git's manpages are so famous for being mostly useless that people even write joke tools that generate gibberish manpages. Mercurial has a very clean documentation, with `hg help ...` just showing you what you need to know instead of (on Windows) using your browser to render an HTML manpage.

And lastly: Will git 2.0 ever come out for Windows? Seems like nobody is working on that, so we Windows users still get some preview version 1.9.4 at the moment. That doesn't look to me as if Windows was a first-class citizen in git.

Fun fact: Converting from git to mercurial is the easiest thing in the world (`hg convert my-git-repo new-hg-repo`), but the other way around is weird and complicated to setup (talking about hg-git).

Re: Go 1.4 is released

#244

Post by NateDad »

jacques_chester wrote: post #240
natefinch wrote: post #232

Earlier quoted context omitted.

Most of the questions about "how do I do X in Go?" are answered with "just write a loop". Yes, that means map/reduce, filter, fold, zip, etc. If writing simple loops gets your hackles up, Go is not the language for you. For me, I worry about the hard stuff, not easy loops.

> If writing simple loops gets your hackles up, Go is not the language for you. What gets my hackles up is claiming that "it's just the same". The same argument works for any language that satisfies the structured programming theorem, including assembler. "If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."

For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.

Re: Go 1.4 is released

#245

Post by NateDad »

marianov wrote: post #145
rivo wrote: post #74

Earlier quoted context omitted.

It's Go's simplicity that really struck a nerve with me. I've been coding for over 30 years now (Basic, ASM, C/C++, Java, Python, PHP, JS, Clojure) and with Go, I just love how everything is laid out for you: idiomatic Go, formatting, commenting, unit testing, concurrence, standard libraries etc. I don't have to research the basic tools. It keeps me focused on the task at hand. I'm very productive with Go. We have it…

Since you know Python, do you find Gonas expresive an clear as Python? Is there anything like list comprehensions and generators in Go? And anything simple like the Flask web framework? How does it compare to deploying a python app using uwsgi+nginx in terms of performance / reliability?

There are no list comprehensions, but they're just trivial loops, anyway. Generators of a sort can be created, but are not commonly used. There are several web frameworks, I don't know flask, so can't answer if any are like that, but even with just the standard library you can trivially put up a web server that has routes and responds appropriately, plus json and html & text templates are in the stdlib too.

Deployment is where Go shines. You don't need nginx or a specific runtime, or uwsgi. You just deploy the file and run it. It runs its own web server. The web server is on par with nginx for performance, and is as stable as your code is (which is generally very stable, since Go's error handling is very explicit). And of course Go code in general is approximately 10x as fast as python.

Re: Go 1.4 is released

#246

Post by andrewchambers »

thomasahle wrote: post #142
andrewchambers wrote: post #117

Earlier quoted context omitted.

Why do they need to add support for this? it already exists... https://github.com/bradfitz/iter/blob/master/iter.go

I don't think that would be considered good Go code. It's no shorter than writing out the 3-part for loop, and it is probably slower.

what extra operations do you think range on a slice would do? The generated assembly is probably the same. Stylistically it is odd however.

Re: Go 1.4 is released

#247

Post by jacques_chester »

NateDad wrote: post #244
jacques_chester wrote: post #240

Earlier quoted context omitted.

> If writing simple loops gets your hackles up, Go is not the language for you. What gets my hackles up is claiming that "it's just the same". The same argument works for any language that satisfies the structured programming theorem, including assembler. "If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."

For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.

> For most people's uses, it's the same.

I look forward to seeing how I can chain multiple operations on a set into a single line of Go.

Re: Go 1.4 is released

#248

Post by JulianMorrison »

I think they ought to add a one argument version of the copy() keyword to bitwise-duplicate and fix up the pointers on the built-in slices and maps. This would support the copy-change-replace semantic their example for Value follows.

Re: Go 1.4 is released

#249

Post by natefinch »

jacques_chester wrote: post #247
NateDad wrote: post #244

Earlier quoted context omitted.

For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.

> For most people's uses, it's the same. I look forward to seeing how I can chain multiple operations on a set into a single line of Go.

Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language.

Also see the aforementioned "the answer is to write a loop".

Re: Go 1.4 is released

#250

Post by jacques_chester »

natefinch wrote: post #249
jacques_chester wrote: post #247

Earlier quoted context omitted.

> For most people's uses, it's the same. I look forward to seeing how I can chain multiple operations on a set into a single line of Go.

Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language. Also see the aforementioned "the answer is to write a loop".

As I said, I've seen people say "it's the same".

It is not the same.

Saying "supports higher level and lower level" programming when you don't actually support most higher level programming primitives is also, from my point of view, untrue.

Go's design choices are what they are, which is fine. But I just see a lot of people who argue, in all seriousness, that a loop has the same level of abstraction as map, filter etc. It simply doesn't.

Post reply on HN