Hacker Newsnew | comments | show | ask | jobs | submit | bradfitz's comments login

Glad you liked it! We enjoy making them.

-----


Please keep them coming. Will watch every single one, multiple times! Loved hearing your thought process and confidence with what was being typed. Now when I code I pretend I'm talking to either of you. It's not weird, right?

-----


Not to take away from the awesome videos now, but I'm a bit sad we won't see anything like this from the LiveJournal/memcached/Danga era - that would have been great watching, I suspect, from my memory of yours and whitaker's posts :-D

-----


Could I suggest also recording an episode when you actually gear up to merge this into master?

-----


We committed it straight to master after we finished the video. The code has been worked on quite a bit since.

-----


I was referring to something which Brad mentioned at the start of the video. About making this client reuse an underlying connection for multiple requests.

-----


Please make more of them.

-----


And despite me silencing the master bedroom one, the other four didn't shut off. That's my major complaint.

-----


They can take it. Or they can build better products.

I don't put on kid gloves when a product is this bad.

I'm nicer when it's a beta or unreleased. But I paid $500 for these, for a final product. This is unacceptable.

-----


I now believe that conclusion to be false, after talking to more people.

-----


Can you share what you found?

-----


I'll be sharing more but not yet. Still gathering information.

-----


Okay, fair enough. Thank you.

-----


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 upstream dev.cc branch. I intend to propose for inclusion into Go 1.5 after finding a way to test it (either build each test as an App, or use the open source xnu/arm port). Brad mentioned that inclusion of iOS support might happen in Go 1.5 in his talk the state of the gopher (http://talks.golang.org/2014/state-of-the-gopher.slide#40), now I believe it really will happen.

The iOS port is my first Go OS port, but it's the only one that takes almost 3 years to complete. :)

Go build iOS Apps. Let's see when can we see a Go based App in the store.

Minux

-----


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.

-----


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

-----


I'm not sure what you define as a build system, but it's even in the description of the go build tool (https://golang.org/doc/articles/go_command.html):

> An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed.

And the hope is that go generate would be a hook into the dependency graph of go build. Much like the architecture switches, the naming conventions, etc, it seemed like it really could have solved my project's protobuf problem.

But it's not, and for reasons that rob pike's doc and the mailing list did not make clear. It looks like a mis-step to me, and I don't think it's due to my misunderstanding of what `go build` and 6g/gccgo are

-----


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.

-----


No it's not if you ever intend to type `go`.

The go team has decided that the go language doesn't depend on any build system, but pushes a single build system one that requires source code compatibility and provides no benefit over many existing and easy to use build systems (makefiles, tup, etc).

-----


The original motivation for putting it into the standard library is so the 'go' command can use it, to watch the filesystem and know what needs to be rebuilt before you even run "go install" or "go build".

-----


"then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults"

-----


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.slide#1

-----


>You can also add numbers on an abacus. It _works_.

Well, I wouldn't go there (C is antiquated/under-equiped like an abacus) if I was advocating Go.

After all, Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter (GC and some basic data structures built-in is so 1980).

-----


> Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter

If you need mainly a large number of features in order to program, Go probably isn't for you. But from the perspective of a C/C++ programmer, this isn't likely to be an important point. Languages with more features than C have been available for 40 years (depends on what you'd count as a feature), so there were plenty of "better" choices in that regard available for said people.

For me, the lack of some "features" is a great asset for Go, I probably wouldn't have bothered to learn a new language if it had boasted the complexity of Rust or Haskell.

-----


> 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 could tell, trying to tug on my leg.

-----


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.

-----


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

-----


I can put the loop a function if you want a nice compact version with a friendly name. Not sure what level of abstraction you're missing.

-----


I can label a GOTO as well.

That languages are turing equivalent doesn't mean that they operate at the same level of abstraction; trying to pass one off as being "the same" as another is just silly.

-----


https://github.com/golang/mobile/tree/master/example

-----


As far as I can tell these samples are immediately bailing out of the Java framework and calling Go using JNI. Which means you don't get the niceties of the UI Framework. You could make OpenGL calls from the Go code like for a game or something. Maybe someone will come up with a Go game engine for Android.

-----


Is there any way to integrate the Java framework? Even something tedious could be crowdsourced with enough help.

-----


That would be the JNI. I have a little bit of experience with making a Python interface to the Android API, and tedious is exactly the right word.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: