3 ms·

> You are only happy if you look for a better C which most people aren't. I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of expressivene

by cies 9y ago

> You are only happy if you look for a better C which most people aren't. I'd argue Rust is the "better" C. Go is a "simpler" C, at the expense of expressiveness, features, speed (only noticable in very low level usecases) and applicability for certain domains (Go is primarily for networked apps). In the same way Java wanted to be a simpler C++ (which came with it's own drawbacks). And for me Go is more of a competitor to Java (as Java is mostly used for networked applications) than it is to C.

jchw 9y ago
To me, Rust is like C++, Go is like C. Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible. Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.
- cies 9y ago
  > Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that corner. Go obviously isn't.
  - jchw 9y ago
    >C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer. C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?) >I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them. >C, C++, Rust are all in that corner. > >Go obviously isn't. Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ. Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.
    - cies 9y ago
      Good points about C. Thanks. > Go differs most in it's [...] built-in concurrency. That was what I was driving at, as well as Go not being fit for writing a kernel in. Sorry being so inarticulate.
      - jchw 9y ago
        Yeah, that is actually a pretty good point to be honest. Go is not ideal for low-level components such as that. I suppose the analogy of Go and Rust being successors to C and C++ is reasonably flawed, from that perspective. On the other hand, I'm glad things are turning out the way they are. Rust and Go are both filling niches that C and C++ didn't, in ways that they couldn't have. I look forward to Rust-based OS kernels, for sure. It seems like with time, we can build very resilient foundations with Rust that wouldn't have been possible before.
  - efficax 9y ago
    > Go obviously isn't. You can use atomics and syscalls and even assembly in Go to have complete control over the system in the same way that you can in C/C++. It's definitely not trivial to bypass Go's memory model and get raw access to memory, but you can do it if you want. I'd say that Go discourages you from doing so, just the way Rust discourages the use of unsafe memory access even though you can if you want.
    - cies 9y ago
      Go strongly pushes a "way to do it", see concurrency for instance. C/C++/Rust have a (one or more) paradigm, but they leave as much liberty to you as a programmer as possible. This I see as a stark difference. Wrt concurrency, Go is more like Node: one way to do it.
  - vardump 9y ago
    > C was also king of the zero cost abstractions. Seriously? That's news to me. Only C zero cost abstractions I know of are based on external code generators. Or some macro abuse, but that's rather limited way to create abstractions. But then again, when you really need to understand everything that is going on, abstractions are often not helping you. (I write kernel drivers and bare bones embedded, where memory measured in kilobytes, not megabytes.)
    - cies 9y ago
      To now C's abstractions, you'd have to compare it to assembly I guess.

by cies 9y ago

jchw 9y ago

To me, Rust is like C++, Go is like C. Rust loves zero cost abstractions, and isn't afraid to be complicated. It gives the programmer as much power as possible. Go is simple and actually very fast. The garbage collector is probably the biggest hurdle for performance and it's still best in class. Definitely higher level than C, but not enormously so.

cies 9y ago
> Rust loves zero cost abstractions C was also king of the zero cost abstractions. > and isn't afraid to be complicated. C sure is not afraid to be complicated. But at the time it was huge simplification. I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). > It gives the programmer as much power as possible. C, C++, Rust are all in that corner. Go obviously isn't.
- jchw 9y ago
  >C was also king of the zero cost abstractions. C++ has static dispatch classes, templates, constexpr, and macros. C just has macros. Any other abstraction costs machine code. C++ also offers a lot of low cost abstraction like RAII-style scoping. >C sure is not afraid to be complicated. Not sure in what sense you're talking. C is not complicated. It's low level. It's exposing complications in the underlying model of a computer. Example: pointers in C are not complicated. Understanding how they work may be for beginners, but that just reflects how hard it is to understand what's going on in a computer. C is accidentally complicated where it is flawed; the non-orthogonal behavior with arrays and the syntax for function pointers are examples. Go fixes some of these flaws, which is unsurprising since it was informed by people close to the origins of UNIX and C (y'know, like, Rob Pike?) >I'd say Rust's complexity is not there for it's own merit, but has huge advantages (though not that visible in a very small project). Sounds a lot like C++. It isn't accidental or coincidental that it is a favorite for high performance but complicated stuff like game and browser development. This is no surprise since Mozilla wrote it to replace usages of C++ for memory safety and concurrency, not because C++ didn't offer enough. C++ is flawed in ways Rust isnt, but that doesn't mean the two don't share a lot of traits, and it was Not by accident. Complexity is one of them. >C, C++, Rust are all in that corner. > >Go obviously isn't. Since you've offered no reasons for why this would be true, I can't actually refute it. But it doesn't make a ton of sense. Go and Rust both let you shoot yourself in the foot literally as much as you want. Go directly facilitates assembly code and allows direct memory access with unsafe. Rust also does this. Go tries to be memory safe and provide concurrency primitives. Rust goes about this in a different way. I don't see where they significantly differ. Rust differs most in it's superior memory safety model and low cost abstractions. Go differs most in it's simplicity and built-in concurrency. But they both feel close to their own origins.
  - cies 9y ago
    Good points about C. Thanks. > Go differs most in it's [...] built-in concurrency. That was what I was driving at, as well as Go not being fit for writing a kernel in. Sorry being so inarticulate.
    - jchw 9y ago
      Yeah, that is actually a pretty good point to be honest. Go is not ideal for low-level components such as that. I suppose the analogy of Go and Rust being successors to C and C++ is reasonably flawed, from that perspective. On the other hand, I'm glad things are turning out the way they are. Rust and Go are both filling niches that C and C++ didn't, in ways that they couldn't have. I look forward to Rust-based OS kernels, for sure. It seems like with time, we can build very resilient foundations with Rust that wouldn't have been possible before.
- efficax 9y ago
  > Go obviously isn't. You can use atomics and syscalls and even assembly in Go to have complete control over the system in the same way that you can in C/C++. It's definitely not trivial to bypass Go's memory model and get raw access to memory, but you can do it if you want. I'd say that Go discourages you from doing so, just the way Rust discourages the use of unsafe memory access even though you can if you want.
  - cies 9y ago
    Go strongly pushes a "way to do it", see concurrency for instance. C/C++/Rust have a (one or more) paradigm, but they leave as much liberty to you as a programmer as possible. This I see as a stark difference. Wrt concurrency, Go is more like Node: one way to do it.
- vardump 9y ago
  > C was also king of the zero cost abstractions. Seriously? That's news to me. Only C zero cost abstractions I know of are based on external code generators. Or some macro abuse, but that's rather limited way to create abstractions. But then again, when you really need to understand everything that is going on, abstractions are often not helping you. (I write kernel drivers and bare bones embedded, where memory measured in kilobytes, not megabytes.)
  - cies 9y ago
    To now C's abstractions, you'd have to compare it to assembly I guess.