6 ms·
Agreed too for your opinion about how to do a startup. But I want to add C to your full stack suggestion. Sometimes it pays off to know low-level details about
by ardfard 13y ago
Agreed too for your opinion about how to do a startup. But I want to add C to your full stack suggestion. Sometimes it pays off to know low-level details about your choice of technologies. Almost every important technologies that I know is implemented in C.
- gizmo 13y agoNo doubt, knowing C always helps. gdb and strace work where other tools fail. In order to be a well rounded developer you ideally have familiarity with functional programming, declarative programming, lisp, and a much more. You hit diminishing returns pretty quickly though.
- collyw 13y agoWith the exception of SQL, are there any mainstream declarative languages?
- chriswarbo 13y agoI hear that HTML is becoming popular these days.
- pestaa 13y agoIt's more like a markup language, though.
- erichocean 13y agoI'm rewriting our Node.js based server in a combination of C and LuaJIT as we speak. The performance difference is absolutely astounding, in part because our Node.js app relies heavily on compiled modules, and the cost to cross from JavaScript to C++ and back is obscene. The straight C implementation looks like it'll be over 1000 times faster for our use case, which involves tons of buffer manipulation and usage of compiled modules.
- ilaksh 13y agoHave you seen Nimrod? http://nimrod-lang.org/manual.html#foreign-function-interface http://nimrod-lang.org/manual.html#foreign-function-interfac... https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers http://nimrod-lang.org/ http://nimrod-lang.org/
- erichocean 13y agoI hadn't, looks interesting! We're actually building on top of Snabb Switch[0], which is giving us another 10x improvement on beefier hardware (2x$2600 CPUs, vs the single socket, $800 CPU we're using now). Our current engineering goal is 1 million full transactional, ACID-compliant writes per second, and 10 million reads per second, on a single dual-socket E5-2697 v2 box. That's a line rate (for our application) of just under 24Gb/second, which we're handling with a single 40Gb Ethernet adaptor. Obviously, we did not think Node.js would get even close to this, but we did think it would at least work for a month or two for 10,000-50,000 users. Sadly, it's only got us through development and now that we've submitted the app to Apple, the server is being rewritten from the ground up for adequate performance. If Node.js's performance had been closer, I probably would have spent time optimizing the Node.js server, but it's so far off right now that it's just not worth the effort. The Snabb Switch port is expected to take less than 10 days total (we're already 5 days into it). For better or worse, the way we've been designing even high performance servers like nginx is just out-of-date. Intel made a huge push to replace custom, ASIC-based network processors with E5 Xeons, and the software development in the larger community just hasn't caught up yet. Snabb Switch, for example, has a wire-to-wire latency, in LuaJIT, of just 26 nanoseconds. For reference, that's about how long it takes a photon of light to travel 25 feet. When messaging speeds are that fast, the Linux kernel is an enormous source of inefficiency, and even TCP is less than ideal (we use a UDP-based protocol with full public-key encryption per packet). [0] https://github.com/SnabbCo/snabbswitch https://github.com/SnabbCo/snabbswitch
- pjmlp 13y agoFunny, I was doing Tcl + C + Apache back in 1999, what is old becomes new.