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

191–200 of 265 posts

Re: Go 1.4 is released

#191

Post by Morgawr »

riobard wrote: post #187
Morgawr wrote: post #123

Earlier quoted context omitted.

I've been working with Go daily for a few months now at my job and I'd like to point out that Go stack traces have a really big signal to noise ratio. There is a lot of cruft that mostly nobody cares about and sometimes it can be hard to pinpoint exactly where something crashed (at which line) with a panic. Just saying, they should probably improve it to be less verbose and more concise.

In that case you would say it has a really low signal-to-noise ratio.

Yes, you are 100% correct, I dun goof'd. I would edit the post but apparently I can't, so I'm sorry for that. Same for the other person commenting on it.

Re: Go 1.4 is released

#192

Post by TeeWEE »

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.

The main use of go for android, is to write native apps (games) in go, using a simple draw loop, that calls into OpenGL. In this way you can have one codebase for your game on android and ios (go will support ios too in the future).

I think it was never meant todo UI android development, because that requires calling into java a lot. Since most of android IS java.

Re: Go 1.4 is released

#193

Post by rjammala »

_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++.

I would say one compelling reason is the speed of development/deployment. It is really a very well designed language. You have to try it to know it :-)

Re: Go 1.4 is released

#194

Post by scott_s »

chaotic-good wrote: post #165
Dewie wrote: post #153

Earlier quoted context omitted.

> It is common to use ARC What is unsafe about using atomic reference counting? > and unsafe shared memory access in Rust. That should be provided with a safe interface, or an unsafe interface if calling that code is not safe. As for it being common: I think they are working on minimizing the need for unsafe code. > This defeats the purpose of this complexity. Like having a VM implemented in C defeats the purpose of…

> What is unsafe about using atomic reference counting? Nothing at all. But sharing objects between threads is unsafe. > Like having a VM implemented in C defeats the purpose of the VM for that language being safe. You can prove that VM code is memory safe? Good for you. > Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to…

C++ is unsafe by default. You have to opt-in to obtain all of the safety (by adhering to a particular pattern of use, or using a particular kind of class, etc.).

Rust is safe by default. You have to opt-out to head into dangerous territory.

That difference may be trivial to some, but to me, it's enormous.

Re: Go 1.4 is released

#195

Post by Gracana »

bradfitz wrote: post #30
codemac wrote: post #21

And they actually stuck with their go generate design? What an unfortunate mis-step. Let the makefile's continue. I've seriously thought about moving to gccgo just to try and get a build system where I can actually inject dependencies on .go files builds again.

You seem to be confusing compilers and build systems. You can use whatever build system you'd like and with whichever compiler.

Is it possible to do away with the typical Go project directory structure? I thought all that was enforced by the tools, but it's possible that I didn't dig deep enough to uncover greater flexibility.

Re: Go 1.4 is released

#196

Post by tptacek »

bradfitz wrote: post #39
saosebastiao wrote: post #38

Earlier quoted context omitted.

Did I miss something? I didn't see anything about iOS.

https://groups.google.com/forum/#!searchin/golang-nuts/ios/g... Quote: gophers, I'm happy to announce that the iOS port of Go recently gained full cgo and external linking support. I've also got a simple C based application working on a real iPad. The port lives in ios3 branch of https://bitbucket.org/minux/goios . Read misc/ios/README for some rudimentary documentation. The port is Go 1.4+, and it's based on upstrea…

I love Rob Pike's contribution to the thread:

Ken and I ported Plan 9 to the SPARC in 6 days over one fun Christmas break.

I wrote the disassembler (for the debugger) and Ken wrote the assembler, so we could cross-check each other's work. The hardest problem other than fighting register windows occurred when we both misread the definition of an instruction the same incorrect way.

Re: Go 1.4 is released

#197

Post by fhs »

BarkMore wrote: post #183
JulianMorrison wrote: post #112

"Package glsprite blah blah blah TODO". Okay then :-D

I was going to suggest that you report this as an issue at https://github.com/golang/mobile , but issues are disabled on that repo.

They're using one issue tracker for everything: https://github.com/golang/go/issues Issues for sub-repositories like this go there also.

Re: Go 1.4 is released

#198

Post by platz »

Morgawr wrote: post #135
bsaul wrote: post #130

Earlier quoted context omitted.

Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and…

>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and e…

It's not about imagining what the best UI component would look like removed from any particular framework, but what the practical constraints are working within the already-existing android UI framework. Android APIs were simply designed for inheritance-oo style to work with them, and trying to avoid this will cause pain.

A similar situation has occured in ios development where the functional aspects of Swift do not complement the existing design of the coca framework.

Re: Go 1.4 is released

#199

Post by TheDong »

Morgawr wrote: post #135
bsaul wrote: post #130

Earlier quoted context omitted.

Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and…

>imagine yourself building UI component without classes or inheritance I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and e…

> easy to follow/reason about in a functional language

Go is explicitly not functional. Many builtin functions mutate (look at Sort for an example). There's no map.

https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...

Functions are only almost first-class. For example... http://play.golang.org/p/WB133vrGKD

Go does have powerful constructs, but to call it "functional" is maligned.

I would also argue that it's not always easy to reason about and follow. The reason we build abstractions, which Java allows perfectly, is so that we can ignore the hidden complexity and reason about code more easily.

Go explicitly makes it difficult to hide underlying complexity. If I want to make, for example, a Bimap (which Java has many clean implementations of) I get to pick from two poisons in Go: Either I must force everyone who uses it to type-cast on every get (implement the bimap via taking and returning interface{}), or I must surface the implementation details (two maps) and have users directly manipulate those since the builtin uni-directional map is a type-safe generic data-structure which I can't replicate in the language itself. This might look appealing at first, but since I also need to do some Locking my interface for allowing people to manipulate those maps directly rapidly becomes troublesome.

Neither of those choices sound appealing to me.

Honestly, if you want to avoid java now you have a plethora of options. You can develop for android with Scala and get basically first-class support.

You can develop for android via webview+html+js and use something like http://ocsigen.org/js_of_ocaml/ to write OCaml and have a wonderful actually functional language.

You can wait for Rust to have some android bindings implemented and use a wonderful language that allows powerful features like macros that are excellent for interface-building.

I don't mean to bash on Go since it does have a place somewhere, I just feel that it is not the correct language for something UI heavy nor anywhere that suitably complex abstractions and complexity-hiding are a necessity.

Re: Go 1.4 is released

#200

Post by bpatel576 »

Good god. Seriously, another language. I'm just starting out learning how to program, and I find it irritating that there are so many languages and it's not that easy figuring out which ones you should learn and which ones you shouldn't.
Post reply on HN