supersillyus

12 ms·

91.
by supersillyus 16y ago
Awesome. Thanks for the update, and nice work.
92.
by supersillyus 16y ago
I think a Go backend was added a while ago, but since there hasn't been a release in 2009, it isn't part of the official release yet.
93.
by supersillyus 16y ago
I think I agree, but I'm not good enough at language design to be sure. :) In the current language, all uses of type literals need to be known at compile time; if I could pass a variable containing a type to "make" or use it to instantiate
94.
by supersillyus 16y ago
Why should Slice be fully implementable within the language? C++ is another systems language that decided that everything should be able to be done in libraries, and we've all seen the complexity that results.
95.
by supersillyus 16y ago
I don't agree with #1. I prefer Go error handling to pretty much any other style I've seen.
96.
by supersillyus 16y ago
Out of curiosity, what resources were you not finding? The language itself and the standard libraries are pretty well documented on golang.org, and searching for "golang <keyword>" has always worked quite well for me to find any thi
97.
by supersillyus 16y ago
Funny you ask. It's far from perfect, but I threw together a quick Go version to entertain myself: http://pastie.org/1504399
98.
by supersillyus 16y ago
Why not learn both? Pick a small but non-trivial application, and write it in both languages. I am pretty familiar with and a fan of both languages. I started with Haskell, and found it to be really exciting. Go is very different, but after
99.
by supersillyus 16y ago
That's the trolliest headline I've read on a tech site in a while.
100.
by supersillyus 16y ago
For some definitions, yes, they are operating at a higher level of abstraction. However, abstraction isn't by itself a good thing.
101.
by supersillyus 16y ago
You're probably right. I took 500ms for 1B iterations and saw that you're looking at ~0.25ns a call, and that seemed a bit low. However, based on your code, you ran it 100M times, not 1B (1e8 vs 1e9). That changes it to 2.5ns per call. I ra
102.
by supersillyus 16y ago
I've seen that quote in a number of threads criticizing OO, and I don't think I fully understand it. Could someone explain what the practical edge of his argument is here? Or is it just a theoreticians complaint, taking a (perhaps simplist
103.
by supersillyus 16y ago
I think those are reasonable descriptions, but they're not quite how I see them. I think OO is orthogonal to imperative vs functional. You can program OO in a pure functional language, and you can do pretty typical C programming with OO.
104.
by supersillyus 16y ago
It seems very likely to me that the JVM is recognizing that "bar" and "baz" don't do anything and (after some warm-up) optimizing them away. Microbenchmarking JVM is hard.
105.
by supersillyus 16y ago
How often does one need/want requests to take longer than 30s? If it takes me more than ~5s to load a site, I typically go elsewhere.
106.
by supersillyus 16y ago
... he is trying to be funny, right?
107.
by supersillyus 16y ago
Awesome. Thanks for the link. Didn't realize that existed.
108.
by supersillyus 16y ago
I think Rust is very interesting and quite exciting, but it's hard to evaluate in relation to other languages (for me, at least) because it is really really young. I've never seen a useful program written in Rust. All of the features sound
109.
by supersillyus 16y ago
I don't know that all of the Go bullet points are correct. For one, Go doesn't have RAII or destructors specifically, but it has "defer" and runtime.SetFinalizer which provide similar capabilities. Also, does Go necessarily have global GC?
110.
by supersillyus 16y ago
Indeed. Go seems inspired by the last 20 or 30 years of computer engineering (it is built from concepts that have been proven to work (and often not work) in the past), and Rust seems to take into account the last 20 or 30 years of research
111.
by supersillyus 16y ago
> I don't know a single person who's done substantial systems programming who takes Go seriously in terms of their field. Not surprising, since it is a very young language. However, as a counterpoint, I do.
112.
by supersillyus 16y ago
I'd like to hope that the Go performance improved, but I doubt it. My guess is that Go wastes most of its time in memory management and in goroutine scheduling, and I don't think either of those have improved significantly in the last year.
113.
by supersillyus 16y ago
What bars do you go to where people discuss server-side javascript frameworks?
114.
by supersillyus 16y ago
What do you think needs cleaning up?
115.
by supersillyus 16y ago
Citation?
116.
by supersillyus 16y ago
Interesting. Can you elaborate?
117.
by supersillyus 16y ago
In your end rant, you could replace "Perl" with just about every other language out there.
118.
by supersillyus 16y ago
In the last decade, I think I've pulled out a debugger only a handful of times. Apparently many people use them, but for me, understanding my code, writing tests, and tossing in some printfs has always been the way. I don't have a problem
119.
by supersillyus 16y ago
Any complexity not covered over by the language will end up only in the programs that need it, as opposed to being included in every program. If the complexity is common enough, it's probably worth centralizing (like, say, an object system
120.
by supersillyus 16y ago
Seems like an instance of the well-known "Michael Bolton Problem" from Office Space. You had a name, you were using it, but something significantly more notable comes along with the same name. They didn't steal your name, but by virtue of b

More ›