61–70 of 77 posts
It seems that people on hn just fell in love with go. So many new articles lately. It's like the node.js fever all over again.
Or Ruby on Rails, Arc, or whatever is the flavour of the year. Additionally it is funny to see the usual comparisons of young developers discovering execution and compilation speeds already possible in 16 bit systems.
While rewriting things in different language is fun (and fun is a great reason to do stuff), the speed of delivering what is ostensibly static content is a solved problem. This was completely unnecessary. Bake the blog post into static HTML and tune up Nginx to shove it down the wires as fast as possible. Stick it on an CDN somewhere if it's important. Then move on to a problem that doesn't already have an optimal so…
Even if you don't bake it into static HTML, this is a solved problem. I serve my homepage/blog off a small Sinatra (Ruby) app, and while that's not slow, mostly because it caches every single page in memory permanently (my written content grows much slower in size than available memory on dirty cheap servers) just because it's simple to do and makes my testing easy (it does stat to check for modifications), there's p…
Earlier quoted context omitted.
Only if you don't mind paying approximately an order of magnitude penalty in RAM usage, which has long been an achilles heel of JVM languages. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.
The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn lots of GC.
Earlier quoted context omitted.
It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.
Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter. The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn…
Strings aren't traced, so that has no impact on GC time.
Heroku, MongoDB, Go, Revel, Bootstrap, with a sprinkling of overkill..
After playing around with an Arduino in my spare time, I've realized how important it is to start thinking in multi-threaded concepts in programming. Nothing makes a better example than watching delay(); physical prevent your sketch from taking the next step. Golang (Still can't believe Google would release a language so piss poor for SEO) WILL be the language I pursue when I start down this path, but right now I don…
Save yourself the pain and go with Scala and the JVM ... mature platform with battle tested GCs, all the libraries and concurrency idioms you'll ever need and a modern FP language designed for scale.
Scala is many things, but that is not one of them. Scala is an OO language with some FP influence.
Earlier quoted context omitted.
Save yourself the pain and go with Scala and the JVM ... mature platform with battle tested GCs, all the libraries and concurrency idioms you'll ever need and a modern FP language designed for scale.
Scala problems (in the old days): - You can't find people to work on it - Unbounded complexity, type-masturbation - Slow compilation (you need a better computer/SSD) - Might as well use Java, the tooling for Java is great Do you know if those are still true?
If you felt that was a problem before, you will almost certainly still feel that way.
>Unbounded complexity, type-masturbation
No idea what you mean.
>Slow compilation
Still terrible.
>Might as well use Java, the tooling for Java is great
The tooling for java is better, but java the language is unbearable.
Earlier quoted context omitted.
I was surprised at how amazed people on one of the recent Go threads was with Go compilation speeds, given that gcc delivers similar compilation speeds for C code per line of code for me on my old, slow home server. As for 16 bit systems, I'd love to see a comparison with the Turbo Pascal compiler, for example, on modern hardware. Maybe my memory is deceiving me and the program sizes just weren't comparable, but it s…
Is this true? I'm not sure about C, but it's definitely the case that Go compiles magnitudes faster than C++, for any reasonable sized project. For example, the ~200k lines of Go standard library compiles in about 14 seconds on my workstation, while random C++ libraries frequently take much longer (just my anecdotal impression from waiting on "brew install").
Also the language is quite complex and requires multiple analyses at parse time to decide what the developer is really trying to do.
C code can be compiled fast if not many optimizations are being made. For example the Tiny C compiler was compiling the Linux kernel around 15s in 2004, not sure about which modules were configured though.
Any proper compiler for a language with modules should anyway be able to beat C and C++ compilers hands down.
Earlier quoted context omitted.
Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter. The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn…
> strings as UTF-16 (vs Go's UTF-8), etc. Strings aren't traced, so that has no impact on GC time.
"I am now loading less static assets. I removed the Disqus comments and the many many lines of CSS from the old site and replaced it with only a couple of lines of CSS alongside a CDN-hosted copy of Twitter Bootstrap. Finally, the Go site is deployed to a free instance of Heroku and the MongoDB hosted on a developer version of Mongolab, while the old Django site was hosted on a Webfaction shared server." So...the Pyt…
I recently benchmarked an uncached remote ASP site versus a local Node.js copy that returned identical HTML. Of course, Node was 100x as fast. (1ms vs 200ms) However, in the browser, they felt like the same site. The 199ms head start resulted in only 50-75ms difference in the browser. Anyway, it turned our focus from backend work to CSS and image improvements.
If your back-end is slow, just cache it and forget about it. Front-end is almost always the bottleneck (the exceptions to this rule being near-real-time dynamic sites like New Relic or GoSquared).