3 ms·
I sincerely hope not. The last thing we need is another down-in-the-weeds language for bit twiddling. Moore's law is practically dead now, so most of the newe
by jstewartmobile 9y ago
I sincerely hope not. The last thing we need is another down-in-the-weeds language for bit twiddling.
Moore's law is practically dead now, so most of the newer CPU-bound algorithms start off using GPUs (where you're stuck with GLSL), then move on to custom chips (like Google's tensor units for ML, or Bitmain's ASICs for bitcoin mining).
If we're headed back to the mainframe architecture of putting the inner-loop stuff in hardware, then this is a wonderful time to start doing more with higher-level languages.
Even as things stand, Java and some Lisps are as fast a C for many applications, and they take care of the memory issues just as well as Rust does, but without the effort or cognitive overhead that Rust requires.
- oconnor663 9y agoObligatory quibble: Java and Lisp take care of memory safety issues, but not thread safety issues.
- jstewartmobile 9y agoI'll quibble back several things: Clojure has immutability on top of atoms/refs/agents, so while Rust is doing Nerf mutation with the borrow-checker, Clojure avoids it in the first place. That, and generally I think threads are overused. Mostly because spawning a new process has been needlessly slow in the past (especially on Windows). Even in C-land, I've seen so many cases where forking and IPC would be more than fast enough, yet far safer. And getting back to the hardware aspect, having a single thread and a badass SIMD instruction is usually faster and easier to reason about than multiple threads and general-purpose instructions where your performance gets fetch-execute-cache-hierarchy-memory-bandwidthed to death. Worst of all, I think this entire mode of computing survives primarily due to marketing reasons. Explaining how something works smarter rather than harder is a difficult sell. Printing "MORE CORES!" "MORE GIGAHERTZ!" on a brochure is an easy and effective way to make the sale.
- oconnor663 9y agoAll fair :)
- burntsushi 9y ago> And getting back to the hardware aspect, having a single thread and a badass SIMD instruction is usually faster and easier to reason about than multiple threads and general-purpose instructions where your performance gets fetch-execute-cache-hierarchy-memory-bandwidthed to death. ripgrep benefits from both having multiple threads and badass SIMD instructions.
- codeNoob 9y agoWhich implementations of Lisps are you talking about? I have been really interested in learning LISP and the only one I found that is used at production was Clojure.
- jstewartmobile 9y agoBack in the day, Chez Scheme was pretty damn fast: https://github.com/cisco/chezscheme https://github.com/cisco/chezscheme Dybvig went to Cisco and open-sourced it. Last I read, Racket lang is swapping over to use Chez as its foundation: https://racket-lang.org https://racket-lang.org I've also heard that HN is written in Arc, which is a Lisp dialect that runs on top of Racket.
- geezerjay 9y ago> The last thing we need is another down-in-the-weeds language for bit twiddling. I disagree. Currently, the best programming language for "bit twiddling" is C, and throughout the years C has essentially remained the same language that was developed four decades ago. In spite of C remaining one of the most popular programming languages in history, the language could be improved. Graydon Hoare and the good people at Mozilla Research have decided to put in the legwork themselves and pick up the slack. They managed to do a commendable job, and the quality of their work is being increasingly recognized. The reason is quite clear: the whole world was eagerly looking for "another down-in-the-weeds language for bit twiddling" that helped circumvent the lack of progress imposed on the C programming language. Rust does just that and more.
- jstewartmobile 9y agothe whole world was eagerly looking for "a new hipster safety language because Haskell was too hard" There. Fixed it for you.