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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

141–150 of 172 posts

Re: The State of Go

#141

Post by learc83 »

pjmlp wrote: post #65
mcgirr wrote: post #50

Earlier quoted context omitted.

Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.

If you can do it with .NET Micro Framework, Java (Atego, MicroEJ, J9, ...) and Oberon (Astrobe), surely Go is also welcomed.

It's not that you can't use Go. It's that Go's probably not the best tool for the job.

Sure you can do embedded development with the .NET micro framework because there are embedded systems that don't have hard real time requirements.

If you're building a hobby robot with netduino, you might not care if you have guarantees about input response time--as long as the delays are usually small enough. But if you move beyond that, you're most likely going to need a real time system.

Re: The State of Go

#142

Post by learc83 »

tracker1 wrote: post #56
mcgirr wrote: post #50

Earlier quoted context omitted.

Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.

If you can do robots with Node.js, I'm pretty sure Go may well be acceptable here.

No one is arguing that you absolutely can't use Go to build a robot, just that it's probably not a good idea.

Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question.

Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?

Re: The State of Go

#143

Post by worklogin »

insertnickname wrote: post #104
rattray wrote: post #92

Earlier quoted context omitted.

> If you really want to install Go via your package manager, Don't most people want to install X via their package manager? > However, this package is naturally on an outdated version of Go I can't tell if you're being sarcastic or not here - why would a package such as this be outdated?

>I can't tell if you're being sarcastic or not here - why would a package such as this be outdated? Because of the way software is packaged in most Linux distributions. The upstream version is frozen in that particular release.

Golang could host a PPA.

Re: The State of Go

#144

Post by microtonal »

Daemon404 wrote: post #136
microtonal wrote: post #47

Earlier quoted context omitted.

go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed. On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.

Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?

The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.

Re: The State of Go

#145

Post by pokstad »

est wrote: post #52

I always have this question: Since a large project like Golang has so many auto-build tools and test OSes, how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You know, not tarballs, but actual static binaries as deb packages installable via apt-get. Good examples: http://wiki.nginx.org/Install https://www.percona.com/doc/percona-server/5.6/installation/... I root for open source movement, but to i…

You can download and install the binaries on Ubuntu: http://pokstad.com/2015/02/03/installing-go-binaries-on-ubun...

Re: The State of Go

#146

Post by AnimalMuppet »

microtonal wrote: post #144
Daemon404 wrote: post #136

Earlier quoted context omitted.

Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?

The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.

Wouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like:

  Create memory in Go-land
  Use memory in C-land
  Dispose of reference to memory in Go-land
That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.

Re: The State of Go

#147

Post by rsc »

lake99 wrote: post #125
rsc wrote: post #123

Earlier quoted context omitted.

What's the rationale for not supporting it, given that the work is done and the maintenance burden is minimal?

I can't offer a rationale, because I have no say in the matter, or even a preference, one way or another. I asked out of mere curiosity. But if you were to tell me that the Go team dropped support for Plan 9, for the same reason they dropped support for dragonfly/386 and OSX 10.6, that explanation would have a very low entropy for me, because apparently, the last release of Plan 9 was in 2002.

Plan 9 is still updated incrementally; there just hasn't been a formal new numbered release. Dropping Dragonfly/386 and OS X 10.6 would be more like dropping the 3rd edition of Plan 9 (except we never supported it).

Re: The State of Go

#148

Post by pjmlp »

learc83 wrote: post #139
pjmlp wrote: post #96

Earlier quoted context omitted.

In CS speak that is actually known as "distributed systems", not "systems programming".

In modern CS speak yes, but the creators of Go were apparently referring to infrastructure types of programs; web servers, database servers etc... Here's a quote from the announcement talk "And it's a systems language in the sense that we intend it to be used to write things like web servers"

If it has servers in the name it is distributed computing.

How modern is modern CS?

I took my CS degree around 20 years ago with focus on computer architecture, compiler design and distributed systems.

Distributed systems literature used in the degree went back to the early UNIX days.

Re: The State of Go

#149

Post by lake99 »

rsc wrote: post #147
lake99 wrote: post #125

Earlier quoted context omitted.

I can't offer a rationale, because I have no say in the matter, or even a preference, one way or another. I asked out of mere curiosity. But if you were to tell me that the Go team dropped support for Plan 9, for the same reason they dropped support for dragonfly/386 and OSX 10.6, that explanation would have a very low entropy for me, because apparently, the last release of Plan 9 was in 2002.

Plan 9 is still updated incrementally; there just hasn't been a formal new numbered release. Dropping Dragonfly/386 and OS X 10.6 would be more like dropping the 3rd edition of Plan 9 (except we never supported it).

I see. Thank you for the clarification. I was hoping you'd tell me that there are quite a few active users who are developing cool stuff for Plan 9.

Re: The State of Go

#150

Post by pjmlp »

learc83 wrote: post #141
pjmlp wrote: post #65

Earlier quoted context omitted.

If you can do it with .NET Micro Framework, Java (Atego, MicroEJ, J9, ...) and Oberon (Astrobe), surely Go is also welcomed.

It's not that you can't use Go. It's that Go's probably not the best tool for the job. Sure you can do embedded development with the .NET micro framework because there are embedded systems that don't have hard real time requirements. If you're building a hobby robot with netduino, you might not care if you have guarantees about input response time--as long as the delays are usually small enough. But if you move beyon…

Do you consider missile guidance systems hard real time requirements?

http://www.atego.com/products/atego-perc-pico/

As a language I am not a fan of Go, but on the context of using strong type languages in embedded scenarios. I think the less C the better.

Just like JavaScript JITs, it is always a matter how much companies are willing to invest to improve the quality of the existing eco-systems.

Post reply on HN