11 ms·

Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go st

Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection. Go abstracts concurrency, completely removing all concurrent features from a language except for the "go" keyword (that launches a goroutine - which is basically a tiny virtual thread), channels (which are selectable queues) and "select" keyword that waits for the first "input" from a static set of channels.

skohan 4y ago
Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understand. There's a few features that could improve it, like proper ADT's, and it's a bit lacking in expressiveness for me to choose it for personal hobby projects, but I would recommend it any time for general-case professional software development.
- kaba0 4y ago
  > but it's performant enough to run circles around a lot of high level languages and dynamic languages It ain’t running circles around any managed language, with perhaps the exception of Python. C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.
  - bheadmaster 4y ago
    Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.
    - kaba0 4y ago
      Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server). Benchmarks are hard to do right but this one does actually measure GC quite well: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (For managed languages. It is not really a fair comparison between non-GC and GC-languages) So all in all, for bigger programs it is hard to do a good comparison, but there is exactly where JIT compilers shine and the memory tradeoff and the like brings their return.
      - skohan 4y ago
        Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response? It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.
        kaba0 4y ago
        But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.
        paskozdilar 4y ago
        Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.
moffkalast 4y ago
He said "easy to read" not "filled with weird syntax choices that make anyone from a C background barf". What the hell are those channel arrows and why do they point the wrong way.
- bheadmaster 4y ago
  Channel arrows are basically just read/write operations. If `ch` is a channel, then this expression means "value obtained from reading from the channel": <-ch And this expression means "write value x into the channel": ch <- x Both expressions can be used as a case inside select statement: select { case val := <-ch: // ... case ch <- val: // ... } Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading if there is another goroutine blocked on a write operation, and ready for writing if there is another goroutine blocked on a read operation. You say you're from C background - if you've ever worked will file descriptors you will notice that channels are basically userspace file descriptors. Channel reading and writing is isomorphic to read() and write() syscalls, and select keyword is isomorphic to select() syscall. Hopefully this clears up the whole channel syntax thing. I just hope you weren't trolling.
  - morelisp 4y ago
    > Channel reading and writing is isomorphic to read() and write() syscalls This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).
    - paskozdilar 4y ago
      While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well. The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.

skohan 4y ago

Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understand. There's a few features that could improve it, like proper ADT's, and it's a bit lacking in expressiveness for me to choose it for personal hobby projects, but I would recommend it any time for general-case professional software development.

kaba0 4y ago
> but it's performant enough to run circles around a lot of high level languages and dynamic languages It ain’t running circles around any managed language, with perhaps the exception of Python. C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.
- bheadmaster 4y ago
  Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.
  - kaba0 4y ago
    Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server). Benchmarks are hard to do right but this one does actually measure GC quite well: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (For managed languages. It is not really a fair comparison between non-GC and GC-languages) So all in all, for bigger programs it is hard to do a good comparison, but there is exactly where JIT compilers shine and the memory tradeoff and the like brings their return.
    - skohan 4y ago
      Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response? It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.
      - kaba0 4y ago
        But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.
        paskozdilar 4y ago
        Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.

moffkalast 4y ago

He said "easy to read" not "filled with weird syntax choices that make anyone from a C background barf". What the hell are those channel arrows and why do they point the wrong way.

bheadmaster 4y ago
Channel arrows are basically just read/write operations. If `ch` is a channel, then this expression means "value obtained from reading from the channel": <-ch And this expression means "write value x into the channel": ch <- x Both expressions can be used as a case inside select statement: select { case val := <-ch: // ... case ch <- val: // ... } Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading if there is another goroutine blocked on a write operation, and ready for writing if there is another goroutine blocked on a read operation. You say you're from C background - if you've ever worked will file descriptors you will notice that channels are basically userspace file descriptors. Channel reading and writing is isomorphic to read() and write() syscalls, and select keyword is isomorphic to select() syscall. Hopefully this clears up the whole channel syntax thing. I just hope you weren't trolling.
- morelisp 4y ago
  > Channel reading and writing is isomorphic to read() and write() syscalls This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).
  - paskozdilar 4y ago
    While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well. The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.