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

151–160 of 172 posts

Re: The State of Go

#151

Post by nickpsecurity »

pjmlp wrote: post #121
mseepgood wrote: post #117

Earlier quoted context omitted.

Robert Griesemer is the Oberon guy in the Go team. He worked for Wirth on Oberon at ETH Zürich.

Anyone on the Oberon world should know that. :) I was lucky enough to be able to use Native Oberon back in the day.

You can still use it: A2 Bluebottle. I proposed it as a solution to the paranoia of "NSA et al subverted everything! What can we use now and to bootstrap better stuff!?"

(raises hand) The well-documented, portable, simple OS and toolchain written by people with no interest in subversion available online for free? Not quite an Ubuntu but more usable than most things people were proposing (eg microcontrollers with hand-written Forth lol). I also thought Modula-2 or Oberon might make a good target for high level languages such as ML or Haskell if we're doing end-to-end safety arguments: one's claims can build on the others.

Re: The State of Go

#152

Post by nickpsecurity »

microtonal wrote: post #59
chowells wrote: post #18

Earlier quoted context omitted.

Why Rust? It doesn't really compete with Go anywhere. Haskell is a much stronger player in the space of high-level, garbage-collected languages. The only thing Rust and Haskell really have in common is not willfully ignoring the last 50 years of programming language design research.

Why Rust? It doesn't really compete with Go anywhere. I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition. Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch. I think your point needs to be re-iterated m…

Great points, esp on Go vs real competition. It's why I'm against their modernized ALGOL68. Languages such as Haskell, Clojure, Rust, Julia, Scala, Ocaml, and others are at least trying to apply lessons learned in programming research to improve things for programmers. Google would've been better off taking one of the more native ones, identifying its worst issues, using their geniuses to fix those, and then building tools + community on that.

Instead, we get an alternative to unsafe, native and safe, scripting languages without most advantages of the best of either. I might still try it out if I do a comparative evaluation of modern work. By that time, it might have gotten better.

Re: The State of Go

#153

Post by nickpsecurity »

pjmlp wrote: post #114
TazeTSchnitzel wrote: post #31

Earlier quoted context omitted.

Rust is a systems-level programming language. Go isn't: it's garbage-collected.

Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.

Good points. People often forget GC languages were often used to write OS's and system software even on constrained devices. A number of languages, such as Modula-2 and Ada, offered the ability to go unsafe in certain modules out of necessity but with safe interfaces. So, where Go or Rust can't cut it, language developers can just use a feature like that (or inline assembler) to solve those problems until the language itself can.

Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.

Re: The State of Go

#154

Post by microtonal »

AnimalMuppet wrote: post #146
microtonal wrote: post #144

Earlier quoted context omitted.

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.

Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs).

To make things work, you have to allocate date used in C in C and pass Go variables only by value.

Re: The State of Go

#155

Post by nickpsecurity »

sacado2 wrote: post #103
TazeTSchnitzel wrote: post #31

Earlier quoted context omitted.

Rust is a systems-level programming language. Go isn't: it's garbage-collected.

Lisp is garbage collected. Yet Lisp machines existed, and they were invented at the same time as UNIX.

And some's details were published for other people to learn from. Anyone wanting to see how they implemented it can google LISP and Scheme machines, hardware, processors, and similar search terms. I recall one implemented cons directly while hiding GC behind memory interface. The programs didn't even know there was collection and it happened in parallel with execution without stopping execution. Great stuff. Many of these give software and hardware implementation details where they could be copied in FPGA's.

Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.

Re: The State of Go

#156

Post by olavk »

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"

Ah, than makes sense.

Re: The State of Go

#157

Post by auto »

fit2rule wrote: post #82
rifung wrote: post #41

"Go 1.5 provides support for Android and experimental support for iOS." I thought this day would never come.

I've been using Go 1.4 for iOS development and it works fine. This is just mainstream'ing the support for iOS, which is needed now because things seem to be quite settled. In fact, I really like using Go on iOS - the ease with which it can be done was astonishing!

As a professional iOS dev and a golang tickerer, I've heard nothing about this, but I'm curious; any projects you can point me at?

Re: The State of Go

#158

Post by learc83 »

pjmlp wrote: post #150
learc83 wrote: post #141

Earlier quoted context omitted.

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.

That's a virtual machine specifically designed for this kind of thing.

So sure, if you want to use go syntax and build a completely new runtime designed for use in real time systems then go ahead.

As for strong typing in embedded scenarios Ada's been doing that for decades.

Re: The State of Go

#159

Post by steveklabnik »

pjmlp wrote: post #138
steveklabnik wrote: post #128

Earlier quoted context omitted.

Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.

Thanks for the heads up. Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right? On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere. All the other modules enjoyed access to an OS wide GC.

Well, it was really just that we didn't get that far, I guess. Mind you, my friends did much more of the work than I did, but like most student hobby projects, at some point, you just stop working on things.

Re: The State of Go

#160

Post by kibwen »

jcranmer wrote: post #118
mkpankov wrote: post #91

Earlier quoted context omitted.

> similar timeframes I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012. 3 years is pretty big difference.

Go was first publicly announced in November 2009, Rust in July 2010.

At the time of its announcement, Go was tremendously further along in its development than Rust was at its own public announcement. Knowing modern Go, you can go back and understand Go code from 2009. Knowing modern Rust, trying to read code from 2010 is essentially impossible.
Post reply on HN