Hacker News Reader

Comment by obl | Hacker News Reader

Cool stuff. It's nice to have a somewhat mainstream language using its own backend instead of llvm. You can in fact get pretty far by tailoring your compiler to your specific needs. You end up with much less code, it's also easier to make it fast.

You do cut yourself of from the more advanced optimizations simply for man-hour reasons. I'm guessing it's a trade off they are willing to make.

I have to say that I really dislike the kind of large pattern matching they added for the hash table clear. C compilers do that as well for e.g. memset/copy or bit rotate instructions.

IME it's really brittle and would be more beneficial as some kind of a lint ("you could replace this bunch of code by a call to clear()").

It makes the code simpler and won't inexplicably slow down next time someone does a tautological refactoring.

View on HN

Note: Go has a GCC implementation which is actively maintained.

I've seen some computational-intensive code received a ~10% performance boost thanks to the heavy wizardry of code generation in GCC in past years (but, see also: masklinn's comments). Once gccgo implements Go 1.11, it may be a good idea to run the benchmark and get some new numbers.

> Note: Go has a GCC implementation which is actively maintained.

They are also actively working on a third, llvm based implementation: https://go.googlesource.com/gollvm/

Go actually doesn't have any other way to clear a map!

Go actually doesn't have any other way to clear a map!

Which, actually, is brilliant design! Now, I can find all map clearings with one operation. (I need to implement that syntactic search/rewrite tool I miss from Smalltalk.)

How is not having map.clear() a brilliant design?

In a large project, you'll have all ways of doing any given thing represented in a code base. Reducing that number down to 1 means that searching for all occurrences is reduced to 1 operation. If you are working on a large project, searching for usages/senders/occurrences is one of the most common tasks that you do. In fact, using escape analysis of the same kind used for "Extract Method" refactorings, you can even catch clearing interspersed with other code in the for-range loop.

A 50%+ reduction in programmer work is nothing to be sneezed at.

... but they made one (runtime only) for that particular use case if I understood the slides correctly, and that is the optimization.

yep, that's right. but it's not accessible to user code, so this isn't something that could be handled by a linter (as suggested by GP).

i'm actually happy with the situation. there is literally only one way to clear a map, and it is fast.

No. They should have used LLVM.

Go is a crippled language because it lacks generics and generalized higher-order types. The stated reasons for this are to make the compiler easier to implement. Maybe they wouldn't have had such implementation difficulties if they had just gone with the compiler backend the industry has standardized on, freeing up developer resources to make Go a language suitable for big development tasks and competitive with C++, C#, etc.

Generics are a design problem not an implementation problem.

If folks agreed on a design finding resources to get them added wouldn't be hard.

Not sure what you're trying to imply with your last sentence, but Go is used by many companies large and small for big development tasks. I work for a company where most of the backend systems are written in Go.

That's not an accurate summary of the reasoning. It's not just the complexity it adds to the compiler, but to the type system in general, and to the complexity it may bring to user code.

The Go team is not against adding generics, and there have been proposals for them. They have simply not landed on a proposal that they feel is a strong fit for the language.

Reply on news.ycombinator.com