Dude... it's really weird to quote varius tiny details of the natural world as proofs of the existence of a god. At what point is the particular system under observation dull enough for someone to believe that it would not have needed an 'outside' designer?
Because, the amazingly crazy details are present at every tiny bit of matter, alive or not. We don't know how to make life? Yeah, well, we don't know how to make energy either (we just transform it). And organization? Every friggin atom is apparently composed of the same kind of elementary particles that know how to behave with other particular kinds of particles when they interact with them exactly by the same rules.
Matter is not a chaotic soup. It's a dance by very specific rules.
The whole universe is rigged for organization. Why? I surely don't know.
I believe in the universe being awesome. It probably gives me same vibes as the belief in God gives others. I suggest we leave it at that.
But as mind blowing details of the natural world go:
Self similarity is a mathematical artifact of nature and you can observe this in "simple" matter. A one of the most striking examples of this is the von Karman vortex pattern that can be observed at any scale when there is a small obstruction in a 'flat' flow.
If you google 'von karman vortex' the image results will mostly display images of cloud vortices. However, the same pattern can be observed for instance around rocks in streams (even really tiny rocks in really tiny streams).
Because it shows that it just takes simple math and algorithms to make complex beautiful things, and not an all-powerful deity?
Some people see the order behind natural beauty as evidence of a designer, but I think this actually demonstates how beautiful systems can arise on their own without guidance. If something was designed by an all-powerful being, it would be surprising if we mere humans could understand its patterns at all.
Different perspectives, I guess.. you are of course free to believe whatever you want.
Yeah, different perspectives indeed. But to me it seems unreasonable that for example the tablet I'm writing this on somehow came into existence by itself. Touchscreen, CPU, OS and no creator at all? The things we see in nature are much more complex than my tablet?
My point, and one of the lessons of this book, is that the things we see in nature are actually NOT that complex. Sure, they are endlessly varied and superficially very complicated, but the rules that govern them are pretty simple. We're able to describe them pretty well with simple computer programs and don't need to be a god to do so. Complexity and endless variation can result from extremely simple systems that are often easily understandable And follow directly from basic laws of nature.
The fault in your logic is your failure to account for the extrordinary difference in timescales involved in the creation of tablets and ferns.
It's worth remembering that Charles Darwin was a geologist by training. At the time, geology was a relativly new discipline, and the first line of scientific inquiry that demanded any concept of deep time. Its development signaled the dawning realization that the Earth was a lot older than anyone had previously guessed ("possibly a billion years" speculated Charles).
Acquiring an accurate measure of the timescales on which geological events played out is what set the stage for an evolutionary theory of life's development. Indeed, the theory of evolution is virtually inconceivable in the absence of these scales.
Obviously not. And that's for the simple reason that the theory of evolution describes living things. As I'm sure you know, a tablet is not a living thing. Therefore, the theory of evolution doesn't even try to account for its appearance.
Of course, people talk about the evolution of inanimate objects all the time. But most of them are aware that they're using the term loosely, and not it its proper scientific sense. In other words, when people talk about the "evolution" of tablets, they are not asserting that new tablets are the product of existing tablets having sex with each other and producing little baby tablets which ship themselves to retail outlets when they're all grown up and ready for sale. Rather, they are speaking metaphorically, and describing a process which, in many ways, looks like evolution.
Nevertheless, the incremental development of tablets is not actual evolution any more than a person wearing a lion costume is an actual lion. I hope this clears things up
"So what you are saying is that given enough time and some random events my tablet could actually come to existance all by itself?"
Well, no. But there is nothing in the natural world that we know of that is implausible for development over the time scales involved.
Which is really separate from the point here, that the various fractal and fractal-like structures is that complex looking behavior and structure can emerge from very simple rule or encoding.
This is bullshit. Just continue to work 16 hours a day, increase your productivity and your startup will succeed. After that you'll be happy forever. And your investor too.
Were there any code examples provided that show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something.
The issues weren't with Go--which definitely allows for both data races and deadlocks and doesn't claim to eliminate either--but with etcd. And according to aphyr, the team was very responsive and quickly fixed the ones he found.
My point wasn't that Go is _worse_ than contemporary languages like C++ and Java when it comes to data races, only that it doesn't eliminate them. Which, again, it doesn't claim to. Rust does, and it is an important difference between the two languages. Because data race freedom with cheap mutable state requires a garbage-collection free subset of your language [1], I think it's unlikely that Go will ever guarantee this.
> show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something.
You mean file a bug like "issue #1935 -- stop sharing memory between goroutines" (I just made it up to be silly there is no such bug report)
In other words, they have explicitly designed in the ability to share memory between goroutines. You can certainly file an issue or bug report about, somehow I doubt that will lead to much but being kickout and laughed at.
One can also just have 2 goroutines wait on each for results and that's a deadlock. Maybe there is a tool to detect that would be nice. Do you know of one?
If all goroutines deadlock, then the runtime will panic and you'll get stack traces for everything. But yes, you can obviously deadlock one or more goroutines trivially. A simple select{} will just block one goroutine forever, for example. And no, there's no tools currently that will detect deadlocks, AFAIK.
I haven't looked into that (or googled), but how does one detect that everything has deadlocked - is it some kind of profiling/sampling being done, or is it something more system specific? Any pointers? Thanks!
http://golang.org/pkg/runtime/pprof/#Profile
Provides a "blocking profile" that tells you what things blocked and for how long they blocked for.
You can use it to find places where you've deadlocked as well as places where adding buffered channels might help performance.
I also agree with the Go team. Although I am a big fan of functional language constructs like map & filter, adding them to Go does not feel right. One of the great things about Go is that it's simple but it does not hide much from you. You still know exactly what is going on (concurrency& channels being an exception). That's why I find it easy to read Go code.
The go community reminds me of the java community. Blind faith in the design decisions of the language. Any feature it doesn't have is passionately defended as a good decision because the clumsy old way is subjectively clearer, up until the day it gets added.
I found that attitude much more prevalent in the .Net community: for just about anything added since C# 2.0 (I didn't follow discussions about generics after the 1.0 release though I expect it also happened then), the idea was essentially dismissed as pointless ivory-tower wankery useless to developers in the Real World right until MS announced it for the next version, at which point it became an Obviously Great idea and a good way to trash-talk java.
That sort of behaviour is in no way unique to Go or Java, and I think it's unfair to judge a language or community by some posts from an online newsgroup - most people are too busy to post or lurk on lists like golang-nuts.
mapping and filtering are just functions and/or loops. You can write those in go. Making some generic thing to save you 3 lines of (really simple) code is not an incredibly useful use of the Go author's time.
Comparing Go and Rust doesn't feel right. They are obviously designed for solving different kind of problems. Go is a simple language, maybe even too simple for my taste. But simplicity is its greatest strength. And I can understand people who would prefer Go as their go-to language for dealing with specific kind of problems. Go is a boring language but gets you where you want to be in a short time and without much suprises. Rust, on the other hand is designed for systems programming. It's got some nice features but it's also a lot more complex language than Go. I don't want to fight compiler all the time. Sometimes I don't need that kind of safety.
I agree that it doesn't feel quite right, but this post seems to be more of a personal exploration of going from some ignorance of both languages, to having a better understand of where each language sits. His concluding section is nicely written.
