121–130 of 172 posts
Earlier quoted context omitted.
Didn't you get the memo? It got revamped into Go after a conversation with Oberon-2. :)
Robert Griesemer is the Oberon guy in the Go team. He worked for Wirth on Oberon at ETH Zürich.
I was lucky enough to be able to use Native Oberon back in the day.
Earlier quoted context omitted.
> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter... The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly. Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly…
This has NOTHING to do with shared libraries vs. statically-linked code. The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Dynamic linking changes nothing.
I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
Earlier quoted context omitted.
I don't think you can compile go to a C archive that runs without the runtime.
Presumably the necessary parts of the go runtime would be embedded in the C archive (or a DLL'd libgo.a file); how else would you be able to use the C archive in a C application?
I was surprised to see Plan 9 still supported. Are there any core Go developers who still use Plan 9 as one of their primary work machines? Is Plan 9's userbase growing?
What's the rationale for not supporting it, given that the work is done and the maintenance burden is minimal?
Earlier quoted context omitted.
Furthermore, the years they spent where dynamic linking were not allowed incubated the culture -- even though dynamic linking is now allowed, it really will be a special case!
Special case?
I know it's an open topic, and there's no true "one way", but I'm wondering how people here would handle this situation. And perhaps it's my Python-addled brain that's the problem, since GOPATH is kinda sorta like PYTHONPATH, maybe enough to confuse me.
I have a repo at github.com/user/repo. It consists of independent but related applications, most in Python, one in Go. The Go project would be rooted in a "service" subdirectory.
I feel like I'm really missing some critical piece of a Go workflow, because I could never get that to build reliably when I started adding external libraries as a dependancy. It seems like I'd have to put the project in github.com/user/repo/service/src/github.com/repo/service, which is what makes me think I don't understand what I'm talking about!
To bring this rambling lazyweb back on topic, I guess I was a little disappointed that vendoring/packaging wasn't mentioned in this state-of-Go talk. I was really hoping I could easily give Go another shot, but in the absence of that, anyone have a suggestion for my setup above?
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.
Earlier quoted context omitted.
You created a burn account just to complain about this? As you know, generics won't appear before 2.0, if ever. It's fine if that's a nonstarter for you. Perhaps you'll like Rust instead. It needs a big community too.
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.
People get bent around the wheel all the time with the tiny niches but both seem well equipped for writing user land applications and are designed to be safer than C and it's cousins. Both have some legitimate interest in them which is what really differentiates them from like D or Ada. Neither is going to be used for kernels (maybe I should say 'serious kernels') and drivers any time really soon. They have a lot of similarity in those regards.
Seems like a golden era to have 2 competing languages that are aiming at C and C++ and have legitimate community interest.
Slide 10 shows the benchmark differences, and I found them a little suspect. The "binary tree" benchmark is the only one that is 25% worse than the old version, but in my opinion it is an important benchmark, because I suppose that this benchmark actually creates a lot of objects that need to be garbage collected. At least that is what I suppose, based on the fact that this holds for binary tree algorithms. The other…
It's not really suspect. The benchmarks reflect execution speed. The new GC trades a little raw throughput for lower GC latency. So you would expect a GC-heavy benchmark to show the greatest speed loss. What matters for go users, though, is the behaviour of real programs. Real programs benefit from the reduced latency of the GC and other compiler optimisations we have made since 1.4. The outcome, in our measurements, is roughly equivalent performance for most programs but with significantly shorter GC pauses.