4 ms·

> Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). I thought we killed this notion already but it st

> Python is high level language while Go is low, system level language (I think it’s fair to say it’s C 2.0). I thought we killed this notion already but it still seems to be lurking around. It doesn't support volatile, doesn't let you specify what goes on the stack vs heap(or pin anything for that matter). Great for web services? Sure. Low level C replacement? Nope, for my money that's Rust.

lucb1e 10y ago
> I thought we killed this notion already but it still seems to be lurking around. I don't have experience with Go beyond reading some snippets, but the Asciinema developers clearly developed with it and they seem to think it so. It's not some notion going around but something an (at least moderately) experienced developer says. I'm not saying they must be right, they might simply be more experienced in Python and prefer Python because of that, but I don't think it should be dismissed as "some notion that's still going around". Edit: You just got downvoted it seems; I didn't.
- vvanders 10y ago
  Yeah, not knocking their choice in Python. I think they made the right evaluation there. It's more that Go keeps getting held up as a replacement for C without understanding what makes C/C++/Rust viable in their domains. It's all down the the memory model and if you don't have control over that then it isn't a replacement. Take volatile for instance, there's certain pieces of hardware that you'll never be able to use Go for without wrapping some parts of the hardware in C because there's fundamental memory IO semantics that volatile provides but Go doesn't support.
- jackmott 10y ago
  Very many developers today do not fully understand what low level means, so very many things get called 'fast' or 'low level' or 'C-Like' that really are not.
- lgunsch 10y ago
  Until you can load up Go code on a microcontroller, or build an OS kernel in it, it is not going to replace C in many circles. Go is also garbage collected, which rules it out for being low by some definitions of "low level". Low level is a very ambiguous term, for some it simple means anything to do with CLI. For others, it means kernels, drivers, etc.
  - collyw 10y ago
    C used to be considered a high level language a few decades ago.
010a 10y ago
Go is far lower level than Python, which makes the term "low level" fine. Its like calling some color swatch "black" then arguing "that's not black _enough_ to be black". Any definition we give for an absolute term like that will be fundamentally arbitrary, but we know right from wrong when we see it. A language does not have to replace C to be "low level". You sound like the type of person who, thirty years ago, would argue that C isn't low-level because it isn't assembly.
- vvanders 10y ago
  Notice I'm being careful to mention semantics not performance(although those semantics largely help with the latter). The ASM<->C bridge is much smaller since you're talking about registers and possibly custom instructions that are usually exposed via intrinsics. For me the dividing line is if your language abstracts away memory management. If I don't get control over where memory lives and how I access it not low level. PC is this nice homogeneous memory structure but there's many systems that have specific semantics around different address spaces and you may need to be able to access and manipulate them in specific ways.
- justinsaccount 10y ago
  I don't think go is much more low level than python, to me it is just much more explicit and verbose..
- ssebastianj 10y ago
  Yeah. As a side note, I remember what Steve Klabnik once said: "Basically, Go is like a lower level Ruby or Python and Rust is like a higher level C or C++".
- douche 10y ago
  Is Go a low-level language, or a slightly lower-level language? Woodhouse, fetch a rug!
wahern 10y ago
C doesn't allow you specify what goes on the stack or heap, either. The "stack" in C is called automatic memory. What differentiates automatic memory is that it's automatically released when it falls out of scope. But it can very well be allocated using the same machinery as malloc. Yes, it behaves in some sense like a logical stack, but it needn't reside in some sequentially allocated storage, and the order of allocation or deallocation of objects in the same scope is completely undefined. Indeed, clang supports a mode with two "stacks", so that buffer overflows of automatic array variables can't easily overwrite function invocation bookkeeping. Go is a fully GCd language with lexical closures. All memory is automatically released when it's no longer _referenced_. So the distinction is irrelevant. As for volatile, it doesn't really do what most people think it does. volatile prevents _logical_ loads and stores from being moved. What that means for when you're dipping into assembly can vary from compiler to compiler. For typical code the volatile qualifier is only relevant when using setjmp/longjmp, for signal handlers, and in the C11 standard, for some kinds of threading. In design and spirit I think Go is very much the successor to C. Though, I've never written a line of Go in my life and code primarily in C most days, so I'm only half informed. But if you look at the history of both C and Unix, they were never about performance, per se. What distinguishes them is ease of implementation, ease of portability, and a philosophy of achieving _easy_ performance gains by shifting a subset of hard problems onto the caller (the so-called "Worse is Better" theory). Thus, C was designed so that it could be compiled in a single pass (without an AST). Similarly, one of the reasons the Go compiler is so fast is because of very intentional language design decisions. Those approaches result in all manner of unintended consequences in addition to the intended consequences, and it's important not to conflate the two.
- vvanders 10y ago
  I don't think you can conflate intent with real world application. Certainly they didn't intend for Javascript to take over the server-side world when they built the language. I don't think you can compare a GC memory model with heap/stack. There's a sliding scale of tradeoffs that you get from a fixed stack -> heap -> GC. There's also a set of hardware out there that doesn't have a unified memory model. There's millions of these types of devices out there in your set-top box, game console and many other places. If you don't have direct control over memory you'll never be able to work with them and will always need a C/C++/Rust wrapper around the low level bits. Lastly, I'd never want to use volatile for threading[1]. There's no memory barrier semantics, instruction ordering semantics(aside from with other volatile reads). If you need thread synchronization you should to use the platform specific atomics otherwise you're in for a world of pain(and god help you if you're going from x86-win32 -> ARM, there's an implicit memory barrier in x86-win32 that most people don't know about). [1] Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering. A read from a volatile variable that is modified by another thread without synchronization or concurrent modification from two unsynchronized threads is undefined behavior due to a data race. - http://en.cppreference.com/w/c/language/volatile http://en.cppreference.com/w/c/language/volatile

lucb1e 10y ago

> I thought we killed this notion already but it still seems to be lurking around. I don't have experience with Go beyond reading some snippets, but the Asciinema developers clearly developed with it and they seem to think it so. It's not some notion going around but something an (at least moderately) experienced developer says. I'm not saying they must be right, they might simply be more experienced in Python and prefer Python because of that, but I don't think it should be dismissed as "some notion that's still going around". Edit: You just got downvoted it seems; I didn't.

vvanders 10y ago
Yeah, not knocking their choice in Python. I think they made the right evaluation there. It's more that Go keeps getting held up as a replacement for C without understanding what makes C/C++/Rust viable in their domains. It's all down the the memory model and if you don't have control over that then it isn't a replacement. Take volatile for instance, there's certain pieces of hardware that you'll never be able to use Go for without wrapping some parts of the hardware in C because there's fundamental memory IO semantics that volatile provides but Go doesn't support.
jackmott 10y ago
Very many developers today do not fully understand what low level means, so very many things get called 'fast' or 'low level' or 'C-Like' that really are not.
lgunsch 10y ago
Until you can load up Go code on a microcontroller, or build an OS kernel in it, it is not going to replace C in many circles. Go is also garbage collected, which rules it out for being low by some definitions of "low level". Low level is a very ambiguous term, for some it simple means anything to do with CLI. For others, it means kernels, drivers, etc.
- collyw 10y ago
  C used to be considered a high level language a few decades ago.

010a 10y ago

Go is far lower level than Python, which makes the term "low level" fine. Its like calling some color swatch "black" then arguing "that's not black _enough_ to be black". Any definition we give for an absolute term like that will be fundamentally arbitrary, but we know right from wrong when we see it. A language does not have to replace C to be "low level". You sound like the type of person who, thirty years ago, would argue that C isn't low-level because it isn't assembly.

vvanders 10y ago
Notice I'm being careful to mention semantics not performance(although those semantics largely help with the latter). The ASM<->C bridge is much smaller since you're talking about registers and possibly custom instructions that are usually exposed via intrinsics. For me the dividing line is if your language abstracts away memory management. If I don't get control over where memory lives and how I access it not low level. PC is this nice homogeneous memory structure but there's many systems that have specific semantics around different address spaces and you may need to be able to access and manipulate them in specific ways.
justinsaccount 10y ago
I don't think go is much more low level than python, to me it is just much more explicit and verbose..
ssebastianj 10y ago
Yeah. As a side note, I remember what Steve Klabnik once said: "Basically, Go is like a lower level Ruby or Python and Rust is like a higher level C or C++".
douche 10y ago
Is Go a low-level language, or a slightly lower-level language? Woodhouse, fetch a rug!

wahern 10y ago

C doesn't allow you specify what goes on the stack or heap, either. The "stack" in C is called automatic memory. What differentiates automatic memory is that it's automatically released when it falls out of scope. But it can very well be allocated using the same machinery as malloc. Yes, it behaves in some sense like a logical stack, but it needn't reside in some sequentially allocated storage, and the order of allocation or deallocation of objects in the same scope is completely undefined. Indeed, clang supports a mode with two "stacks", so that buffer overflows of automatic array variables can't easily overwrite function invocation bookkeeping. Go is a fully GCd language with lexical closures. All memory is automatically released when it's no longer _referenced_. So the distinction is irrelevant. As for volatile, it doesn't really do what most people think it does. volatile prevents _logical_ loads and stores from being moved. What that means for when you're dipping into assembly can vary from compiler to compiler. For typical code the volatile qualifier is only relevant when using setjmp/longjmp, for signal handlers, and in the C11 standard, for some kinds of threading. In design and spirit I think Go is very much the successor to C. Though, I've never written a line of Go in my life and code primarily in C most days, so I'm only half informed. But if you look at the history of both C and Unix, they were never about performance, per se. What distinguishes them is ease of implementation, ease of portability, and a philosophy of achieving _easy_ performance gains by shifting a subset of hard problems onto the caller (the so-called "Worse is Better" theory). Thus, C was designed so that it could be compiled in a single pass (without an AST). Similarly, one of the reasons the Go compiler is so fast is because of very intentional language design decisions. Those approaches result in all manner of unintended consequences in addition to the intended consequences, and it's important not to conflate the two.

vvanders 10y ago
I don't think you can conflate intent with real world application. Certainly they didn't intend for Javascript to take over the server-side world when they built the language. I don't think you can compare a GC memory model with heap/stack. There's a sliding scale of tradeoffs that you get from a fixed stack -> heap -> GC. There's also a set of hardware out there that doesn't have a unified memory model. There's millions of these types of devices out there in your set-top box, game console and many other places. If you don't have direct control over memory you'll never be able to work with them and will always need a C/C++/Rust wrapper around the low level bits. Lastly, I'd never want to use volatile for threading[1]. There's no memory barrier semantics, instruction ordering semantics(aside from with other volatile reads). If you need thread synchronization you should to use the platform specific atomics otherwise you're in for a world of pain(and god help you if you're going from x86-win32 -> ARM, there's an implicit memory barrier in x86-win32 that most people don't know about). [1] Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering. A read from a volatile variable that is modified by another thread without synchronization or concurrent modification from two unsynchronized threads is undefined behavior due to a data race. - http://en.cppreference.com/w/c/language/volatile http://en.cppreference.com/w/c/language/volatile