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

231–240 of 265 posts

Re: Go 1.4 is released

#231

Post by natefinch »

xienze wrote: post #210
jrockway wrote: post #172

Earlier quoted context omitted.

Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."

Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...

This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing.

The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.

Re: Go 1.4 is released

#232

Post by natefinch »

jacques_chester wrote: post #217
bradfitz wrote: post #7

Earlier quoted context omitted.

You can also add numbers on an abacus. It _works_. Put in a less snarky way, C is often way more low-level and tedious than you need. The great thing about Go is that it lets you blend high-level and low-level programming in the same program, only getting low when you need to. It feels like a great mix of C and Pythonubyerlhphavascript. I've given many talks on this, e.g. http://talks.golang.org/2014/gocon-tokyo.slid…

> The great thing about Go is that it lets you blend high-level and low-level programming in the same program Where are map, reduce, select, filter, fold, zip ...? I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too. And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I…

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.

Re: Go 1.4 is released

#233

Post by noselasd »

alfiedotwtf wrote: post #8
_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

Not having to use Java on Android. This is a major reason. (it's going to interesting to see battery life of not running an interpreted language on small devices like Android Wear).

Dalvik has had a JIT from Android 2.2, you're not running interpreted code.

Re: Go 1.4 is released

#234

Post by curun1r »

jksmith wrote: post #204
omellet wrote: post #163

Earlier quoted context omitted.

Perforce is not Git-style, it's got a single central repository.

Speaking of which, of all the shops moving to Git, prolly only a handful exercise the full value of dvcs.

The one feature I miss from Mercurial is the "hg serve" ability. When combined with the zeroconf extension, it made it really easy to push/pull changes to/from other developers. Since switching to git, I don't think we've had one (vcs) push that included commits from multiple developers, but we used to do that all the time. I know git can coerced into doing something similar, but hg made it so damn easy that developers actually used it.

Addressing your actual point, most shops won't use the full value of a dvcs, but they'll all get some benefit of it being a dvcs because each and every developer's machine has a backup of the central repo which, in the event the main git server dies, can be used to restore everything to it's previously happy state. When you use a vcs like svn, you need to be a lot more paranoid about backing up the central server or you risk losing revision history.

Re: Go 1.4 is released

#235

Post by bsdetector »

gillianseed wrote: post #216
bsdetector wrote: post #203

Earlier quoted context omitted.

Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall. Really, things like concurrency primitives as a point in Go's favor? Running code on several processors at once is where it's good to have a library because there are tons of knobs like priority and scheduling policy for instance; it's been trivial to deadlock or a…

>Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall. C# on Mono certainly isn't significantly better performing than Go from my experience, which is substantiated by Go winning all but one of the 'Benchmark Game' benches, typically by quite a wide margin: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t.…

On many of these benchmarks, with no memory allocation, since Go is compiled with zero dynamic loading (not even modules) it should be only slightly less fast than C due to range checking and lack of controls for fine tuning, but instead it is half as fast. Benchmarks using memory are 1/6th as fast.

Go should be faster than JVM Java at microbenchmarks due to no dynamic loading and precompilation, instead it's only faster on some really tiny algorithms possibly even due to just fitting in the cache better because the GC runtime is so basic. So if you want to write some simple command line tool Go maybe it'll be slightly faster than Java. On anything that uses much memory JVM destroys Go on performance.

So performance is not a reason to write something in Go -- in fact it's just the opposite. Since you can't control the coroutine scheduling you can't do anything about latency spikes or starvation or anything else that can cause performance problems in multithreaded programs.

Re: Go 1.4 is released

#236

Post by ahh »

orbifold wrote: post #113
pjmlp wrote: post #104

Earlier quoted context omitted.

Real systems programming would be possible with a little more help. Meaning a few more operations exposed in unsafe. The problem is that the average developers never saw Oberon line of languages or are unaware how much of libc is actually written in Assembly. Maybe with Go 1.5 fully re-written in Go, it will be easier to sell this scenario.

According to Github 8.4% of glibc is written in assembly. You would actually expect that to be an over estimate, since assembly is guaranteed to be machine dependent.

I suspect this is a significant underestimate: glibc heavily relies on generated assembly (they have a set of scripts to generate boilerplate asm functions for system calls) and inline assembly (which gets defined once, probably counted as C by github, and used many times.)

Re: Go 1.4 is released

#237

Post by vegedor »

bsaul wrote: post #85
alfiedotwtf wrote: post #6

Earlier quoted context omitted.

And now things just got interesting. I'll put my money on the availability of Go on Android being the catalyst for its future hockey stick growth.

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains. Ps : my stand is the opposite for server side dev.

I think success is relative to the goals of the language. As a system language that place is in areas where performance matters. Performance might be an issue on mobile in general, with regards to battery life, but in business terms optimizations costs money and people like to carry datacenters in their pockets anyway, so the benefit of a slightly more efficient language is a moot point.

With low expectations in mind it might be a minor success for anyone who likes to use it for the languages sake. I wouldn't know about that, because I don't use go and should therefore not really comment in a go thread but here we go, I wrote it already. (pun not intended)

Re: Go 1.4 is released

#238

Post by vegedor »

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…

I don't agree with the premises. Teaching in higher classes assumes independent study of the reader as enhancement. For me it's making much more sense to look at a consistent implementation of OOP features in C [1] (understanding less and less to the end of the latest paper). It make sense to understand the data structures behind it to reason about the transformation of your game to OOP.

For your problem there's Multiple Inheritance, but not every OOP-Language supports it. You have movable, visible, etc as objects and game_objects inherit from them as needed. If you have learned OOP with a toy metaphor and dived straight into Java or Python, you might miss out on some formal fundamentals. Some say Java doesn't implement OOP properly, but at least it's running ;). Naturally most students also want to get practical and don't want to dabble in the dire theory.

In C you'd have bitmasks encoding the types and functions called based on that (or how'd you do it? gibe references). If you had your logic wired up to call functions straight away, it might have made sense to encode the functionality as member functions, to have an object being immobile simply by not using the move function. The data would be stored in pools of other objects, like location data, that your functions work on. I'm still learning. If I'm not making sense, tell me, but I think that's what MV* does?

For a simple enough problem there are different probable solutions

[1] http://ldeniau.web.cern.ch/ldeniau/oopc.html but there are others as well

Re: Go 1.4 is released

#239

Post by codexon »

codexon wrote: post #58
mholt wrote: post #10

Earlier quoted context omitted.

Once Go is installed, I can make a simple web app from scratch that displays parameters from the URL or request body in just over 95 seconds with Go, using only the standard library. I can cross-compile it for another OS and architecture, then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults. Try doing that in C/C++. Maybe a better comparison is to more systems-level appl…

You can still get segfaults in Go. "panic: runtime error: invalid memory address or nil pointer dereference"

I'm wondering why I'm being downvoted for a factual statement.

The parent of this comment said "without worrying about dependencies, dynamic linking, or segfaults".

This is blatantly wrong. Pretty sad what HN has become.

Re: Go 1.4 is released

#240

Post by jacques_chester »

natefinch wrote: post #232
jacques_chester wrote: post #217

Earlier quoted context omitted.

> The great thing about Go is that it lets you blend high-level and low-level programming in the same program Where are map, reduce, select, filter, fold, zip ...? I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too. And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I…

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."

Post reply on HN