Go 1.4 is released

https://blog.golang.org/go1.4

by ahochhaus • 12 years ago

453 257 12 years ago

blog.golang.org

The most notable new feature in this release is official support for Android. Using the support in the core and the libraries in the golang.org/x/mobile repository, it is now possible to write simple Android apps using only Go code.

This is fantastic! Are there any example Android apps released by the Go team to help get started ?

bradfitz6• 12 years ago

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

guelo• 12 years ago

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.

alfiedotwtf2• 12 years ago

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.

pjmlp8• 12 years ago

For that really to happen, the Android team needs to give some love to alternative languages.

From their Fireside talk I won't expect any change.

Dewie6• 12 years ago

I don't really see it - a language made for systems programming (read: non-application development) being used for developing Android apps? Or is there some other kind of Android development in mind, here?

bsaul6• 12 years ago

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.

tormeh3• 12 years ago

They'd have to make Dalvik a compiler target. Could work, though.

thechut• 12 years ago

I'm not sure how much more 'hockey stick' it can get. Android already has 85% market share.

hyp0• 12 years ago

If go code can now run on android, the go compiler can run on it...? Allowing go coding on-the-unit.

lrem• 12 years ago

Not necessarily, this could still be cross-compilation. On the other hand, why wouldn't it?

howeyc• 12 years ago

There has been some work by the community. A user created an app with a button and a webview using go 1.4beta[0]. I modified it to only be a webview with a Go web server[1]. I also wrote an app for myself in the same manner here[2].

I found the whole android developer ecosystem a bit of a pain to setup, but it works now. The amount of java I have to worry about is quite low, so that's a win for me.

---

[0] https://github.com/MarinX/godroid [1] https://github.com/howeyc/godroid [2] https://github.com/howeyc/spipedmobile

_RPM• 12 years ago

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

bradfitz6• 12 years ago

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

coldtea2• 12 years ago

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

jacques_chester5• 12 years ago

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.

alfiedotwtf2• 12 years ago

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

pjmlp8• 12 years ago

Last time I checked Java was being compiled to native code.

noselasd2• 12 years ago

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

cnbuff410• 12 years ago

For Go, I don't think what you need is a compelling reason from someone else. One compelling reason to one is not necessarily compelling to others.

Instead, since Go is a very simple language with very easy learning curve, I encourage you to spend a weekend to check it out. Pick a side project and do it in Go, then you will know if it's the language for you.

I would even argue that the joy of writing Go would be magnified by working as a team and the joy of reading Go would be demonstrated by exploring any Go project from any team. But I would not go that far for a Go novice who just want to check it out

mholt• 12 years ago

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 applications like you might code up in C. The same benefits carry over to those, without a significant performance hit (usually).

(And to be fair, sometimes C/C++ is the better tool for the job. But give it a shot; Go is pretty handy when you don't need to drop down to lots of unsafe memory and CPU operations.)

By the way, your existing C skills will be very useful in Go. For example, struct fields will still be padded unless you pack them carefully. Your experience with buffers, streams, memory allocation, and data structures will definitely not be wasted in Go.

howeman2• 12 years ago

And if you want to use external code, you can download it with and integrate it into your main package in about 90 seconds (go get + go install). In order to learn to use it, godoc is there.

cheepin• 12 years ago

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

NodeJS runs on top of C++ :P

blakecaldwell• 12 years ago

Concurrency with goroutines and channels in Go is pretty awesome, as is the tooling: race detection, code formatting, PPROF performance monitoring, vetting (finding incorrect printf strings), and a great test framework with parallel execution support. The standard library is enough for most of what you'll need, and it's all open source, so you can learn to write idiomatic Go from it.

codexon3• 12 years ago

You can still get segfaults in Go.

"panic: runtime error: invalid memory address or nil pointer dereference"

hk__2• 12 years ago

You can get static linking in C/C++ with `gcc -static`.

fit2rule• 12 years ago

>>>Try doing that in C/C++.

Lua.

zyang• 12 years ago

A really crisp way to model concurrency. Most real world performance problems stem from the inability to model concurrency correctly.

I also found it's faster to read the library code than the docs. A lot of thought has gone into making the language and library clean and easy to understand.

Cyph0n• 12 years ago

Doesn't that mean that the docs are lacking?

vowelless• 12 years ago

Concurrency is the most compelling reason. You will miss templates though. Try experimenting with the concurrency and network communication stack in the go standard lib.

gtani• 12 years ago

there's lots of old HN threads and a blog and a couple books to give you the flavor (and yeah some people are less than enthusiastic); also Oreilly and Manning are coming out soon with "In Action" books, you can read a 8 of 14 chapters draft:

https://news.ycombinator.com/item?id=8332835

https://news.ycombinator.com/item?id=8356677

http://blog.senko.net/learning-go

_________

Books:

http://golangbootcamp.com/

http://openmymind.net/The-Little-Go-Book/

http://www.manning.com/ketelsen/

pentelkuru• 12 years ago

You should be able to get up and running with Go extremely quickly if your default language is C.

If there's a reason you must be using C rather than another language (require manual memory management, require code to be as fast as possible, etc.), then Go might not be applicable. Otherwise, Go feels like an updated C and I don't see a compelling reason not to invest a little time in checking it out for yourself.

draven• 12 years ago

require code to be as fast as possible

It's also pretty easy to write the performance critical parts of the code in C and call them from Go.

wyager• 12 years ago

If you're doing networking, it's worth looking into. It has a good standard library with good networking features. It has pretty solid concurrency primitives.

Beyond that, I would not recommend it. I think a lot of people get caught up in the fact that A) it's hip and new and B) it's managed by Google. Without knowing what you want to do with it, I would recommend any number of languages (Rust, Haskell, Julia, etc.) before learning Go.

MichaelGG• 12 years ago

If you're using C/C++ and need the performance, look at Rust. Fairly expressive, good type system (and they figured out generics), and C++ like or better performance. All the power of manual memory control, with none of the downsides.

chaotic-good4• 12 years ago

It's too complex, we're already have C++.

matt_trentini• 12 years ago

"or better performance"?

I'd like to see some evidence if you have any.

Rust has great performance in general - and I also agree that it is an appealing language - but I haven't heard anyone claim better than C++ performance before. I'd be very dubious of anyone making that claim...

jbergens2• 12 years ago

It would be easier if you explain what type of programs you develop today in C or C++. In general terms Go is probably an easier and more productive language but you might lose some performance.

rivo• 12 years ago

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 in production and I'm super happy with it. (Btw, I never missed generics. If you pick a language based on its number of features, Go may not be for you.)

marianov• 12 years ago

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?

jksmith4• 12 years ago

Preach it! Been using Go for a while now, and I haven't been able to keep this much of the problem domain in my head since my days coding in M2. IMO, that's the point of Go.

shurcooL• 12 years ago

No need for header files.

myg2042• 12 years ago

and very fast compilation! Almost feel instantaneous.

myg2042• 12 years ago

No #ifdefs :)

pjc503• 12 years ago

You can write a network-facing application and the language will help rather than hinder you in making it secure.

lmm3• 12 years ago

If garbage collection is acceptable, you'd learn more from trying OCaml - or even Haskell, if you want to really expand your comfort zone. I'm not saying don't learn Go eventually, but for the "second language" you should try something more different from C/C++ so you get more of an idea of the range of stuff out there.

Dewie6• 12 years ago

Doesn't OCaml have bad support for concurrency, though? Concurrency is one of the features that people who look into Go are often after.

melling2• 12 years ago

OCaml is been around for almost 2 decades. Something must be holding back its adoption. Microsoft's version F# seems to be doing better but developers aren't adopting it en masse.

lazyjones2• 12 years ago

- garbage collection

- safe and easy programming (really!)

- no more shooting yourself in the knee with hard to debug problems

- lean but quite complete standard library

- native strings (proper unicode/utf-8 handling)

- very little boilerplate, sane defaults

- concurrency primitives (no tacked-on libraries)

- high performance - not far behind C/C++

- extremely easy and practical documentation features (via comments)

bsdetector2• 12 years ago

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 arbitrarily delay an entire Go program just by having GOMAXPROCS busy loops and there's no scheduling control at all last time I checked. Meanwhile shared data locking isn't even in the language despite being at a very fine level where using libraries can be cumbersome.

And Go comments as good documentation is another mind-boggling claim. It's a mostly free-format with few machine-readable parts. Most functions don't even explain what types of errors can be returned, just "err Error". It's so bad it isn't even comparable to JavaDoc or C#. How can you have "safe" programming when you have to dig through sources to even find out what the error conditions are?

There is a good reason to use Go and that's to feel like a pioneer. But few technical reasons.

rjammala• 12 years ago

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 :-)

kyrra• 12 years ago

It s really simple language to learn but a bit more to master because you have to solve some common problems in a different way (especially if you have a strong OOP background). To learn the basics, check out the tour[0]. It's really simple to go through and will explain the basics of the language.

[0] http://tour.golang.org/

hanief2• 12 years ago

Can you build Android UI using Go? I have not found a good UI library in Go.

kev61682• 12 years ago

Also can someone please give a brief description of whole process to write a simple Android app in Go? What are the bare bone setup(Go, JDK, Android SDK??, etc.), so I can develop and compile? Is the final result an apk file? Thanks.

faitswulff• 12 years ago

I'm not an Android developer, but have you seen the examples yet?

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

tjohns• 12 years ago

You can access OpenGL, but the full Android framework isn't directly exposed. It's similar to developing in C++ using the Android NDK.

From the documentation (https://godoc.org/golang.org/x/mobile/app):

  An app can be written entirely in Go. This results in a significantly
  simpler programming environment (and eventually, portability to iOS),
  however only a very restricted set of Android APIs are available.
  
  The provided interfaces are focused on games. It is expected that the
  app will draw to the entire screen (via OpenGL, see the go.mobile/gl
  package), and that none of the platform's screen management
  infrastructure is exposed. On Android, this means a native app is
  equivalent to a single Activity (in particular a NativeActivity) and on
  iOS, a single UIWindow. Touch events will be accessible via this
  package. When Android support is out of preview, all APIs supported by
  the Android NDK will be exposed via a Go package.

Alternatively, you could write your UI code in Java and call into a Go shared library via JNI methods, if you aren't worried about graphics and just need code portability. Again, this is similar to working in the NDK.

hanief2• 12 years ago

Thanks for the link. I just read about it. So probably it's not a substitute for Java (yet) right? I guess it's kind of a replacement of C++ for multi-platform games development.

Kabukks• 12 years ago

Just to make sure I'm not missing it: fsnotify didn't make it into Go 1.4, right? 1.5 maybe? :)

dsymonds5• 12 years ago

It didn't make it in, but there's no real strong moves for it to be in the standard library anyway. It works well enough in a go-gettable package.

bradfitz6• 12 years ago

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

krat0sprakhar2• 12 years ago

Pardon my ignorance but if fsnotify is not available how is Hugo (static site generator) listening for events in the filesystem (to reload the server)

mischanix• 12 years ago

By using platform-specific cgo calls.

Laremere2• 12 years ago

Looking at Hugo's dependencies, the copy on my machine (possibly outdated) uses this library: https://github.com/howeyc/fsnotify

However, there's a moving notice on that page for this repo: https://github.com/go-fsnotify/fsnotify

Fsnotify will probably make it into the standard library or other core golang repository at some point, given that it could help speed up the compiler. However there's nothing particularly mystical about it that prevents a 3rd party library from being just as good.

vially• 12 years ago

fsnotify is not available in the go standard library, but you can still use it like any other third party library (e.g.: go get)

bgentry2• 12 years ago

Doesn't look like it's been pushed to the canonical git repo or Github just yet: https://go.googlesource.com/go https://github.com/golang/go/releases

Aside from that, this is yet another great release! :)

dsymonds5• 12 years ago

It will be soon. I'm working on it.

bgentry2• 12 years ago

Looks like it's up now :) Thanks!

codemac3• 12 years ago

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.

bradfitz6• 12 years ago

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

Gracana• 12 years ago

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.

codemac3• 12 years ago

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

noselasd2• 12 years ago

If you want or need to use makefiles to do whatever you want to do, use makefiles.

nXqd• 12 years ago

Now you can write Android application and eventually iOS ( I don't know if I need that ), this is quite interesting. Congrats go team !

saosebastiao• 12 years ago

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

bradfitz6• 12 years ago

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

cryptos• 12 years ago

I wonder why they didn't move the main code repo to GitHub as well. https://go.googlesource.com/ is somewhat poor compared to GitHub.

dsymonds5• 12 years ago

Because we want a good code review system, and GitHub doesn't have that.

More discussion: https://news.ycombinator.com/item?id=8715529 https://news.ycombinator.com/item?id=8605204

touristtam• 12 years ago

Gerrit looks pretty horrid to use to be honest.

smegel• 12 years ago

What is google source? Is it a successor/alternative to google code?

frik2• 12 years ago

Powered by Gitiles (footer on https://go.googlesource.com ) and links to:

https://code.google.com/p/gitiles/

  Gitiles is a simple git repository browser built on JGit. 
  Emphasis on simple: the goal is to make it easy to see 
  your files and changes, leaving complex tasks to other 
  tools. 

  Gitiles is the source browser used by the Android Open 
  Source Project. To see it in action:

https://android.googlesource.com/

makeramen• 12 years ago

At first glance it seems like you will be able to use go on Android the same way you can use C and C++ through a jni bridge between the java and go code: https://github.com/golang/mobile/blob/master/example/libhell...

I'm very curious to how the go runtime and GC will work.

pjmlp8• 12 years ago

Even if I don't agree with all design decisions, Go is certainly coming forward.

Congratulations to everyone involved.

teddyh11• 12 years ago

This relatively recent trend of company-specific languages annoys and disturbs me.

I don’t ever want to be tied to a language and library ecosystem under the thumb of a single (large) corporation. Not Visual Basic, not .NET, not C#, not Objective C, not Go (It’s even named after the company, for crying out loud! Yes it is. Don’t try to claim otherwise).

I’ve used Basic, I’ve used Pascal, I’ve used C, I’ve used Python, I’ve used Lisp, and so on and so on. Those were open platforms, with different companies in the “lead” position in any one time (Microsoft Basic, Turbo Pascal, Borland C, GNU C Compiler, CPython, PyPy, etc.), but the language was not “owned” by a single company which would loom in everyone’s mind, always the unspoken fear being “what if <company> doesn’t like it?”.

I will not use tools which make me afraid. I will not live a life in fear.

nodata• 12 years ago

It's open source.

teddyh11• 12 years ago

While technically true, this has almost nothing to do with what I wrote. Huge code bases thrown over the wall, while technically “open source” does not a community make. A language named after a company with the overwhelming majority of development sponsored by that same company is not something you realistically envision someone forking, so the fear I spoke of is still there.

Now, if the language was, say, maintained by 80% or more by submissions and monetary contributions from outside the company (and if the name was changed), then it would approach being a neutral platform to the benefit of all.

As it is, we’re all being invited into Google’s yard to play, but we don’t own the house.

bodyfour• 12 years ago

I'm generally in agreement, but it's hard to say what languages will be considered "company-specific" in the future.

Go back in time 35 years and C could have been called that "AT&T specific language" Or the opposite: Objective C looked like a hopeful contender to be a widely-used language but it just never caught much traction outside the NeXT/Apple (and NeXT ended up buying the developer) and today it's almost completely associated with a single company's ecosystem.

Maybe in 4 years we'll be talking about the new features coming in "ISO Go19" and complaining that VisualGo still doesn't support all of Go18 yet. Who knows?

teddyh11• 12 years ago

True, but today Go is still specific to Google. If it really catches on in the way you describe, then it will be a viable language. But not today.

jbergens2• 12 years ago

If the non-company-specfic languages cannot keep up with the evolution company-specific languages show they will have a problem getting or keeping their users. I know it takes a lot of investment to build great tools, do marketing, evolve a language etc and currently some large companies seems to think that they get more of what they want by funding their own languages. If someone fund the free languages they same way they will probably evolve faster and get more users. There is also a problem of getting large groups of people and organizations to agree on something. This also slows down progress in some open/free projects. Sometimes it is easier to just decide for yourself.

teddyh11• 12 years ago

There are certainly advantages for companies to develop languages in-house, but there are also, as I wrote, disadvantages for outside developers to use that company-specific language. This lesson was learned long ago about assembly languages and machine code: If you could program the Burroughs Whatzit 220, you could not program the Data General WhizJig 3000, and all the software ecosystem you (and others) had written over the years became obsolete when technology advanced. This was a large part of why programming languages were invented, and why they were always meant to be platform and vendor independent – so that this would not happen again¹.

It’s possible that we are due for another generation of developers to make the same journey of discovery of why vendor-specific technology solutions have larger drawbacks than what is initially apparent.

① This is also, incidentally, why Unix proliferated as an operating system – it was and is, for all intents and purposes, a vendor-independent platform for development at the operating system level.

tete• 12 years ago

But look at other examples.

JavaScript became ECMAScript, where ECMA is there to define standards, but still there are a couple of big players from certain companies and still they do Dart, which is mostly a Google thing and is a direct competitor to ECMAScript.. well, ECMAScript 6 at least. Even though it's not a bad language one can see a lot of company interest there.

And when you look at Go you see that it is controlled by people who work for Google, but don't exactly depend on them. I think it's more a language of Ken Thompson or Rob Pike than Google.

What do you think about Rust? It's affiliated with Mozilla, but Mozilla is (also) a Foundation and Rust is not a Mozilla Product like Firefox, where it often is really hard to get your changes in. There are a lot of people who got interested, even outside of Mozilla and at least to me it appears that they have influence.

And the last thing is what matters. Microsoft has huge interest on controlling C#, Visual Basic .Net, etc., because their income is related to data. They create the major platform for it, get income via selling the OS, the IDEs, etc.

If you look at Go then that doesn't seem to be the case. Google's main benefit (tell me if I am wrong!) appears to be being able to replace C++ and Python where neither seems to fit for one reason or another. If you look at the state of both the Android version now and Google App Engine then Google doesn't show huge interest into using it for money.

Of course that is only now and maybe this changes, but it doesn't look like it for now.

My personal opinion is that Dart was more to worry, also because of the approach being similar to Microsoft, when they create a standard (be it for documents or a language) and then create their incompatible extension or are always ahead of the others, because of their strong involvement. I really don't see that with Go.

Another thing that is slightly related to go is NaCl (Native Client, not the crypto library), being Google's version of ActiveX. But that's more because it of course is a target platform for Go, not a thing that's wrong with the language. Else you'd also have to worry about C.

teddyh11• 12 years ago

Since you ask: Rust, being a Mozilla thing and Mozilla being a foundation, is certainly a less risky and “fearful” (so to speak) platform in this regard. Go, however light a hand Google might have on it at the moment, still has Google’s hand on it, which makes me wary. Sure, it’s better than Dart (or C#), but everything can point to something which is worse – that is not a good enough reason to accept a thing’s drawbacks.

slm_HN• 12 years ago

but the language was not “owned” by a single company which would loom in everyone’s mind, always the unspoken fear being “what if <company> doesn’t like it?”. I will not use tools which make me afraid. I will not live a life in fear.

This is a very emotional response. It uses the language of emotion: fear, afraid, even the odd emphasis of the words owned and loom. Unfortunately for you Hacker News tends to be logical and analytical.

Personally I don't fear any tools, except for table saws, which combine extreme sharpness with a dangerous axis of rotation that can lop off fingers or propel a 2x4 through your abdomen with ease.

Oh, I also fear C++, which is the table saw of the mind.

rcarmo2• 12 years ago

Nice. Now all I need is for someone to turn https://github.com/jcla1/gisp into a slightly more complete LISP and I'll have a nice environment for all kinds of ARM systems.

Edit: typo/autocorrect

rxaxm• 12 years ago

this your project? i'm down to do this

rcarmo2• 12 years ago

Nope, just something I've been keeping track of. Needs macro support, for starters, and this fork (https://github.com/masukomi/gisp) is adding tests.

frik2• 12 years ago

What's the current roadmap for dynamic linking / shared library support?

Is this the current one? https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...

valevk• 12 years ago

There is a new range syntax[1]. The release notes say it's rarely used, but makes code cleaner. In which cases would the syntax be useful?

[1] https://golang.org/doc/go1.4#forrange

thomasahle2• 12 years ago

If they added support for `range 10` to iterate 0-9 this would be useful for doing things a certain number of times. Now it's probably mostly useful for emptying iterators.

andrewchambers2• 12 years ago

Why do they need to add support for this?

it already exists...

https://github.com/bradfitz/iter/blob/master/iter.go

dsymonds5• 12 years ago

One use case would be to exhaust a channel (that is, read everything off it until it is closed). Another might be to loop over something of a fixed size to correlate with a corresponding number of other things.

Laremere2• 12 years ago

Here's a search of the go source for use of that: https://github.com/golang/go/search?p=3&q=%22for+range%22&ty...

Most of them are tests, but I see a couple genuine use cases:

1. Draining a channel until it closes.

2. Since range of a string gives utf8 runes, the RuneCountInString function in the utf8 package simply has an integer count, and does a range through the string increasing the count in every loop.

rakoo2• 12 years ago

It's useful if you want to schedule a function every x seconds:

    for range time.Tick(1 * time.Second) {
      fmt.Println("tick")
    }

fxbois• 12 years ago

Mobile development will soon be exciting with the fight Go vs Swift

cyber1• 12 years ago

Super!

xrstf2• 12 years ago

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.

pjmlp8• 12 years ago

I am you there.

Mercurial was more friendly to us Windows developers.

But with Microsoft embracing Git this isn't any longer the case.

swah• 12 years ago

Git is equally hostile to everyone! Long live Git.

(Maybe the way to advance the poor Gui user interaction experience is to write frontends for it?)

simias• 12 years ago

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.

topstarnetwork• 12 years ago

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

rnhmjoj• 12 years ago

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

McP• 12 years ago

There isn't much of a difference. The underlying principles of how they work are essentially the same. However hg has IMHO a more pleasant UI, and it's easier to customise. I believe Facebook chose hg for the latter reason: https://code.facebook.com/posts/218678814984400/scaling-merc...

xrstf2• 12 years ago

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

JulianMorrison5• 12 years ago

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

BarkMore• 12 years ago

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.

fhs• 12 years ago

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

bpatel576• 12 years ago

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.

FraaJad• 12 years ago

focus on

step 1. getting good at solving problems in one language

step 2. get really good at that language. (ie., know how to avoid pitfalls, get best performance, know corner cases)

step 3. learn new languages that expose you to newer paradigms (ie., you know "OOP" languages, learn FP langauges next).

JulianMorrison5• 12 years ago

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.

Go 1.4 is released

Related Stories