Like how Java used to?

Yeah go for it. Nothing could go wrong: https://github.com/scala-native/scala-native/issues/543

It's a few lines of code to get sbt to combine everything into a single jar. Do other languages not requiring including libraries?

Statically compiled languages like Go do not.

Well, there are two separate questions here:

1. What should the default be? Java build systems default to building dynamically linked, though it's a few lines to change. IMO dynamic is a better default for large projects, as you usually have more library modules than executable modules. On the other hand a large project is likely to already involve a fair bit of build config, so maybe the defaults should be optimized for small projects.

2. Whether you allow dynamic at all. To my mind it's always worth having the option, and I think Go will come to regret not having it if and when it ever gets used for large projects.

There are plenty of large projects like kubernetes/docker/rkt/influxdb/tidb/cockroachdb and so on. Go is providing quite large memory efficiency and sub-millisec GC as compared to Java.

As of Go 1.8 it also provide plugin support though I am not sure if they are any where near Java in term of dynamic libraries loading support.

Only works on Linux as of now.

Or gholas.

Now someone has to sound exasperated at everyone jumping to blame managers.

You mean the machine learning stuff, that's been around since 1959?

That machine learning stuff which has been around for the past 60 years out of humanity's, what, 10,000 years of 'modern' humans (starting with the invention of agriculture)? That's only really reached parity with humans on a broad range of cognitive tasks in the past within the last 5-10 years?

Yes, that stuff.

In theory, but we didn't have enough data or computing power for machines to compete with human performance (also algorithmic improvements).

I feel that the disruption isn't going to be completely new compared to past changes but probably across more industries at the same time because machines can soon move and think e.g. Driving, diagnosis, planning (through better prediction), assembly.

and now is finally energy efficient enough for practical usage.

> And are there disadvantages to reference counting that make it a bad idea?

I thought it had a performance cost.

Maybe in the non-atomic case. Atomic refcounts force synchronization between CPUs when different threads access the same data, even if they only read it; that can have a quite significant cost.

They also tend to prohibit some smart gc optimisations like moving your shit while you're not looking, and the cache behaviour can be bad because either,

- the data isn't stored next to the count so you get two pointer indirection per access, or

- the data is stored next to the count, and the object gets cached-in when it gets collected.

Piggybacking on the thread because I haven't had much concrete experience with smart pointers: how does the "circular chain" problem seem to manifest? Is it

- "goes wrong quickly," usually picked up and fixed without too much trouble,

- "like any old memory leak" -- maybe a problem if processes run a long time, hard to track down, or

- devs are usually smart enough to see them coming, knowing to keep the "has a pointer to" relation a partial order (either by type or some other natural hierarchy.)

?

For a post on HN the tone was ok but not great, if one of my team spoke like that in a meeting I would commend them on their technical knowledge but remind them that their effectiveness and influence depends more on tone than technical skill, because people.

ot was being a gentleman, not pandering. It's unfortunate that the subthread went off topic but the reasons are understandable and the disagreement resolved nicely. Please don't be rude in comments here.

My elementary school library class teacher is turning over in her grave.