HomeLog InSource

notes.public

[View] [Short] [Hash] [Raw]

EarthFS 2014-09-16

hash://sha256/42897a0ef6ce6a5bf0075d661639bda0751e03bb09b86790fd020900eb1ba798[#]

https://news.ycombinator.com/item?id=8315996
https://gist.github.com/kachayev/21e7fe149bc5ae0bd878
Channels Are Not Enough (github.com)

Whoa. The good times just don’t stop.

This article seems Golang’s equivalent of the takedown of Node.js[#] from a while back. I knew enough about Node to recognize the truth in that article, and I know enough about async, fibers and C to recognize the truth in this one.

https://news.ycombinator.com/item?id=8316520
spion

Go doesn’t let you build abstractions - it offers what it does, and if its not enough - tough luck.

This comment in particular made me smile[#]. Go actually seems worse than C because at least C lets you do crazy stuff with pointers and the preprocessor when you feel like it’s necessary, whereas Go comes more from the bondage and discipline school of design (from what I’ve heard).

From the article:

// deliverer
calculation.WhenDone(func(state string, w Weather) {
  broker.Publish("CA", w)
})

// client
ch := broker.Subscribe("CA")
for update := range ch {
  w.Write(update.Serialize())
}

This is quite a coincidence, because we just did something very similar in EarthFS:

void EFSRepoSubmissionEmit(EFSRepoRef const repo, uint64_t const sortID) {
	assert(repo);
	async_mutex_lock(repo->sub_mutex);
	if(sortID > repo->sub_latest) {
		repo->sub_latest = sortID;
		async_cond_broadcast(repo->sub_cond);
	}
	async_mutex_unlock(repo->sub_mutex);
}
bool_t EFSRepoSubmissionWait(EFSRepoRef const repo, uint64_t const sortID, uint64_t const future) {
	assert(repo);
	async_mutex_lock(repo->sub_mutex);
	while(repo->sub_latest <= sortID && async_cond_timedwait(repo->sub_cond, repo->sub_mutex, future) >= 0);
	bool_t const res = repo->sub_latest > sortID;
	async_mutex_unlock(repo->sub_mutex);
	return res;
}

That’s the real code, copied and pasted with no cleanup.

It turns out that locks (whether “async” for fibers or real locks for preemptive kernel threads) are simple as hell and completely amazing?

Back to Minecraft for a minute:

https://news.ycombinator.com/item?id=8319088
exDM69

Minecraft is very heavy on the CPU and would benefit from running on native code rather than a managed bytecode based virtual machine environment.

It isn’t heavy duty graphics, so you don’t need a super strong GPU (it’s still quite heavy), but Minecraft is very CPU and memory intensive. Graphics can be fast regardless of the programming language if you unload things to the GPU, but Minecraft requires a lot of CPU side work to prepare the voxel graphics (ie. building GPU vertex buffers, etc from the voxel octree in CPU/main memory).

There are huge potential performance benefits of rewriting it in native code. I don’t think that will happen, though.

Minecraft shocked everybody when it was a popular browser game written in Java when Java was already considered obsolete. It’s easy to dismiss it as a fluke or say that using C++ would’ve been better, but I think there’s more to programming than what gets proclaimed on internet forums, and I think Notch knew something the rest of us didn’t.

Likewise, I’ve learned a lot of stuff they don’t teach you on Hacker News by building EarthFS (first in JavaScript and then in C).

Incidentally the only reason I saw this comment was because the author’s name was in purple. I checked their profile recently because they had some other comment that seemed very good. So it’s a bit weird to see this one and realize that it probably isn’t true.

We only have a sample size of one but the reasonable thing to conclude is that Java was perfect for Minecraft.

This also ties into a talk by Jonathan Blow that I listened to again the other day.

http://www.reddit.com/r/TheMakingOfGames/wiki/index
http://www.reddit.com/r/TheMakingOfGames/comments/21813r/jonathan_blow_how_to_program_independent_games/
https://www.youtube.com/watch?v=JjDsP5n2kSM
How to program independent games - Jonathan Blow - CSUA Speech

There’s an issue here that goes beyond being smart. There’s some kind of issue of operational wisdom. […]

Here’s some guys who made this really cool game that I… don’t know how to… make… And it’s made by a couple programmers… If I think something’s wrong with what they did, but what they did is kind of beyond my capability, maybe I just don’t understand why they did what they did. Why am I saying they suck when all concrete evidence in the universe says that they don’t suck?

This is a pattern I see… Again, talking about the internet, this happens on the internet all the time.

Not saying exDM69 couldn’t program a great Minecraft clone in C++… But there’s something different about programming the original Minecraft.

Keywords: reality, arguing, compelling counter-factual arguments, creative process, tradeoffs

So in summary, I saw a channel implementation in C which didn’t seem very good but it got me thinking about whether channels would be useful… Now I won’t worry about it.

Node and Go are both failed experiments (which doesn’t make them bad). Now I’m just waiting for Rust to topple over, because I already think there’s some signs it will happen.

Will EarthFS start showing cracks eventually too? I don’t think so, because I’ve been taking every precaution to avoid fooling myself. That’s where literally 95% of the time has gone. For example, realizing (kind of at the last minute[#]) that we need to track dependencies.

Keywords: work ethic, ego