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

Golang on ARM

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Golang on ARM

#51

Post by stcredzero »

4ad wrote: post #33
vox_mollis wrote: post #22

Earlier quoted context omitted.

Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling. It seems they accepted this sacrifice for some other unimportant feature* *edit: Looks as though the feature they sacrificed performance for was writing Go in Go.

> It seems they accepted this sacrifice for some other unimportant feature [writing Go in Go] Writing Go in Go is a huge feature, not an unimportant feature. Writing the runtime in Go means we write the runtime in a much safer language. We found and fixed lots of bugs just by rewriting the runtime. Everybody, every user benefits from this tremendously. Writing the runtime in Go means you can have a precise garbage co…

Golang has managed to replicate a lot of the virtuous things that happened in the early days of Smalltalk, but in a compiled language. (Has a completely different philosophy about debugging, however.)

Re: Golang on ARM

#52

Post by AnimalMuppet »

tedunangst wrote: post #49
pcwalton wrote: post #41

Earlier quoted context omitted.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Why not consult the go faq to find their reasoning for omitting generics? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. The word performance doesn't appear in that paragraph.

Complexity in the type system can easily have a negative effect on compiler performance.

Re: Golang on ARM

#53

Post by skj »

bigdubs wrote: post #39
nickysielicki wrote: post #14

Earlier quoted context omitted.

Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?

go test fully recompiles most of the (large) project i'm working on

go test -i

Re: Golang on ARM

#54

Post by bassislife »

[deleted] wrote: post #48
bassislife wrote: post #47

Earlier quoted context omitted.

> Writing to LLVM in no way restricts you to a backend. You simply need a language-level IR that you can retarget to different backends as you would like. It still ignores toolchain flexibility. Especially given the specific needs of Go's managed runtime.

[deleted]

> which LLVM now supports

Key word being "now".

I think you understood rather well.

Also have a look at the supported architectures paragraph in the documents you linked.

Re: Golang on ARM

#55

Post by [deleted] »

[deleted] wrote: post #50
tedunangst wrote: post #49

Earlier quoted context omitted.

Why not consult the go faq to find their reasoning for omitting generics? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. The word performance doesn't appear in that paragraph.

[deleted]

[deleted]

Re: Golang on ARM

#56

Post by sunnyps »

pcwalton wrote: post #46
arthurbrown wrote: post #43

Earlier quoted context omitted.

Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration. "Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with…

> For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two." LLVM now supports both segmented stacks [1] and precise garbage collection with patchpoints [2]. Tweaking support for segmented stacks is…

Yeah, the point is that it wasn't there at that time.

Re: Golang on ARM

#58

Post by sunnyps »

bassislife wrote: post #54
[deleted] wrote: post #48

Earlier quoted context omitted.

[deleted]

> which LLVM now supports Key word being "now". I think you understood rather well. Also have a look at the supported architectures paragraph in the documents you linked.

And go 1.4+ doesn't just need segmented stacks but also moveable stacks. I do not know if LLVM has that yet.

Re: Golang on ARM

#59

Post by bigdubs »

skj wrote: post #53
bigdubs wrote: post #39

Earlier quoted context omitted.

go test fully recompiles most of the (large) project i'm working on

go test -i

"-i Install packages that are dependencies of the test. Do not run the test."

Does make "go test" complete faster, throws baby out with bathwater though.

Re: Golang on ARM

#60

Post by threemux »

bbrazil wrote: post #36
4ad wrote: post #30

Earlier quoted context omitted.

What is the problem with solaris/amd64?

../../Sirupsen/logrus/text_formatter.go:28: undefined: IsTerminal The logrus library we use for logging doesn't support Solaris.

Looks like it does now:

https://github.com/Sirupsen/logrus/blob/master/terminal_sola...

Post reply on HN