Hacker News Reader

Hacker News

Comment by contextfree | Hacker News Reader

Full thread

contextfree

"- It is "garbage-collected" (which is uncommon for a compiled language: The only other example is "D") "

wat?

View on HN

Don't let the facts get between you and faint praise!

Also: Common Lisp, Scheme, Erlang, SML, OCaml, Haskell, Lua, Prolog, and Java, and no doubt numerous others.

For all of the above, many (if not most) implementations compile natively.

I didn't know about llvm-lua (an AOT compilation option for lua.) Neat!

Something which has been neglected, but which has clearly shown its value in VMs is the information gained by runtime tracing.

We should make this more available to the programmer! It should be possible for a programmer to highlight a section of code in an IDE and choose "Apply Trace," whereupon the IDE will apply static type annotations based from saved runtime trace information. The IDE should be also able to present the same information as profiling data to let the programmer quickly home in on the 15% or so of the app which is most performance critical. Using techniques like this should let us get C-like speeds from many dynamic languages.

(Admittedly, this sort of thing would also be highly dangerous. One couldn't apply such semi-automated annotations in ignorance. This could also break otherwise correct programs.)

Directing programmers to hotspots based on programming info is pretty reliable. In your case, it depends on how confident the annotations are. The Self papers have a lot about that - JIT compilers can nonchalantly make riskier optimizations, because they can also easily undo them.

My idea is that the programmers can add expert knowledge and human intelligence into the mix. They have the ability to just let the VM know: "Okay, in this part these things are always going to be this type and things go like that, so just go to town and optimize the bejesus out of it!"

In other words, a good programmer should be able to just let the VM know ahead of time what's up in critical sections of stable production code. Even better, we should be able to combine datasets from many different runs of many VM instances! This sort of technique would allow us very high degrees of confidence for things like web apps in server farms, where getting 10's of thousands of runtime tracing datasets would be easy to do.

This is where a dynamic language with optional type annotations would really shine.

Sounds like how some people use Cython.

Snippet from [0], which is unfortunately temporarily down (I got to it through Google Cache[1]):

  cpdef double integrate_f(double a, double b, int N):
  	cdef double dx, s
  	cdef int i
  
  	dx = (b-a)/N
  	s = 0
  	for i in range(N):
  		s += f(a+i*dx)
  	return s * dx

[0]: http://www.behnel.de/cython200910/talk.html

[1]: http://webcache.googleusercontent.com/search?q=cache:7NvoUHh...

I'm not sure about Go specifically (as I have yet to write a non-trivial project in Go) but D at least allows you to do manual memory management, if you so desire--down to using std.c.stdlib.malloc, which is exactly what it sounds like--although garbage collection is on by default. I usually tell people it's "...mostly garbage-collected," which tries to convey the flavor of a choice between fine-grained systems-level control and instantiate-and-forget application-level control.

To be fair to the author, I'm going to assume that the most esoteric (read: non-C-like) language he knows is probably Python, because he doesn't compare it to anything besides Python, C, C++, or Java. I also assume he left out Java because by "compiled languages" he meant "compiled to native code without relying on a runtime which is external to the compiled application." He's still missing a whole swath of compiled languages, but there is a point of view from which his comment makes sense, i.e. native-code compilation of C-like systems or applications languages.

("...you will find that many of the truths we cling to depend greatly on our own point of view.")

x = new(foo) ... x = nil

There. Manual memory management. What? It's not as if when you free() something that was malloc()'ed, it gets returned to the operating system right away. It just goes back on the free list. Garbage collection amortizes that.

Well, by the same token, you can take Python's

    x = Foo()
    ...
    del x

as manual memory management, after a fashion (which it is). The kind of manual memory management I'm concerned about is less about having precise control over when memory passes in and out of my program's control, and more about controlling fragmentation and time spent searching for unused memory. For example, would slab allocation--an extremely useful technique for operating systems, databases, &c--be possible in Go?

Addendum: I'm not trying to denigrate Go, and I don't mean to suggest having or not having fine control over memory makes or breaks a programming language, because it's a valuable tool in certain instances and a hindrance in others. I honestly don't know whether or not it's possible in Go; I suspect it is, to some extent, although it would no doubt be discouraged by the design of the language.

"What", exactly. If Go really deleted the object pointed to by x when you set x to nil, it would be seriously flawed (though I wouldn't actually be surprised if this was the case, it certainly is flawed in many other ways).

Not sure why the downvotes - perhaps the "wat" sounded too trollish - but yes, this strikes me as a very ignorant statement... even good old Java is another example. So are many compiled Lisps, Haskell, Lua...

Yep.

I still haven't read one article from Go aficionados that hasn't made me bang my head against a wall repeatedly.

Reply on news.ycombinator.com