5 ms·

I think the grandparent means that Go is already very abstracted from what's actually happening (e.g. programmers don't have to think about quantum mechanics, v

• stouset 9y ago
  Yes! You have restated my position better than I could have.
• Veedrac 9y ago
  This feels like a false comparison to me. When you write ASM you pretty much know what it's going to do. When you ADD two registers, you really are making two reads in the register file, which really is a piece of physical hardware, and those reads really do go to a physical adder and get written back to the real, physical register file. And languages like Go translate reasonably (but not exceptionally) straightforwardly to assembly. Even if you don't know all of the details that go into making it fast, your first guess of what it's doing is pretty much right. In contrast, adding some lazy FP callback into your latest node.js framework on DOM objects might be doing something, somewhere, but who on earth really knows?
  • stouset 9y ago
    > This feels like a false comparison to me. When you write ASM you pretty much know what it's going to do. This is because it's an excellent layer of abstraction on top of the machine code which is interpreted by the abstraction of microcode which sends it to the abstraction of a physical processor that's itself just an abstraction on top of transistors that themselves are an abstraction around manipulating voltages on a complex network of circuits. Nobody bats an eye at these levels of abstraction. And they're not perfect! Modern CPUs have hundreds of errata. Skylake's alone is almost 40 pages long, at 3-4 per page. But you take them for granted because they're several layers lower than what you have to deal with on a regular basis. Even your example of adding two registers required compiling through an assembler, scheduling execution by a time-sharing operating system that fakes the concept of running hundreds of parallel processes by rapidly looping through running processes, and on and on and on. We are awash in a sea of abstractions more deep and complex than even a dozen of the world's best engineers put together could hope to fully understand. And yet people earnestly defend language design decisions that prevent a single function from comparing two values of any arbitrary numeric type as being too complex, when issues like that are less than a hundredth of a hundredth of a hundredth of a percent of the complexity that are modern computers.
    • Veedrac 9y ago
      Electronics Weekly says[1] > “The M0 is a third of the size of the M3 in its minimal configuration,” ARM CPU product manager Dr Dominic Pajak told EW – 12,000 against 43,000 gates. That same page is 2.8MB compressed, the half of which is Javascript decompresses to 2.6MB. Yes, a big OoO core has a lot more to throw around, but the vast majority is spent on tricks to make things go faster. The layers are thinner than you expect, and they're built that way on purpose. The hardware below assembly is a far smaller jump than the browser in the sky. [1]: https://www.electronicsweekly.com/news/products/micros/arms-cortex-m0-processor-how-it-works-2009-03/ https://www.electronicsweekly.com/news/products/micros/arms-...
      • stouset 9y ago
        Over two-thirds of that is ad-related code. The HTML, CSS, and basic Javascript needed to run the site appears to be on the order of < 250KiB. Images obviously bump that number higher. You are not arguing against abstraction. You're arguing against the user-hostile influence of advertising on delivery of content on the web.
        • Veedrac 9y ago
          And you think adblockers have a legitimate reason for their codebase to be 3x the size of DOOM? If all this abstraction from the low level C code of DOOM to the high level Javascript-on-the-browser bought us anything, you'd think the abstract one that is solving an easier problem would take less code, not more.
          • Veedrac 9y ago
            s/adblockers/adverts and trackers
  • dbaupp 9y ago
    > When you ADD two registers, you really are making two reads in the register file, which really is a piece of physical hardware, and those reads really do go to a physical adder and get written back to the real, physical register file You've elided a pile of abstraction here too, like what it actually means to "read" and "write" the physical register file. Additionally, CPUs do a ton of microcoding of operations, so simple instructions like a 2-register ADD may correspond to the "obvious" thing, but more complicated ones will go through more hardware/do more things. The gulf of abstraction between the physics and any programming language is vastly larger than differences between programming languages, so it's weird that all of the hardware and operating system and C+GC is the right abstraction, but "tiny" extensions, say, like hardware and operating system and C+GC+generics^ is not right. ^ (Any of the common ways to implement them.) > In contrast, adding some lazy FP callback into your latest node.js framework on DOM objects might be doing something, somewhere, but who on earth really knows? This is the false comparison! Even Go can conceal arbitrarily complicated operations behind function calls. I can make a Go API that takes closures to execute later too. (There's even core language support built on this idea, `defer`, that behaves in a way that's resistant to the straightforward (RAII-like) implementation.) If we're going to be talking about things at the instruction-level, you can definitely complain about the dynamism of Ruby forcing even simple + to be (quite) a few more instructions, but you need to consistently look at either the micro-scale or the macro-scale, or explicitly connect the two. If you were doing DOM manipulations in Go, I'm sure, say, listening for some events (like a "lazy FP callback" might be) would be at least a similar order of magnitude in terms of non-obviousness to the JS version. It's fair that different language/ecosystems may encourage/lend themselves towards different coding styles, but this is most evident with apples-to-apples comparisons.
    • stouset 9y ago
      > The gulf of abstraction between the physics and any programming language is vastly larger than differences between programming languages, so it's weird that all of the hardware and operating system and C+GC is the right abstraction, but "tiny" extensions, say, like hardware and operating system and C+GC+generics^ is not right. Yes! This is why I argue that the problem isn't "too much" or "excessive" abstraction. We're already so far down the rabbit hole of abstraction that another layer or two are peanuts to the amount of abstraction we implicitly accept as being totally normal, reasonable, and okay. The issue is bad abstractions. And we as an engineering discipline have lots of them, at all layers of the stack! I'll even happily entertain the notion that generics^ (to borrow your use) are a bad abstraction. I don't agree, but at that point I think we're at least debating something worthwhile — as long as the alternative isn't "no more abstractions", but is some other layer of abstraction that better approximates some high-level concept we want to model. Fighting against more abstractions is a losing proposition. We need to be focused on how to develop good abstractions, so we can progress the field on solid, stable ground instead of on the quicksand it feels like we've been progressing on for the past decade. In my opinion, Rust is a phenomenal leap forward here.