Announcement

Collapse
No announcement yet.

Intel Unleashes Clear Containers 3.0, Written In Go

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by sad_coala View Post

    I'm a full time Go developer.

    The Go compiler cannot prove that there are no data races in your code. Of course you can use the race detector, but the program slows down so much that it cannot be used in production. If you race condition happens only with a good amount of load, then you are out of luck.

    I'd seen a lot of nil pointer dereferences as well. Ignored errors, type assertions around interface{} types are all safety hazards. Rust beats Go here. However, I do accept that the container ecosystem is dominated by Go with a good reason.
    I'm doing Go professionally at the moment myself. And I do some Rust for fun.

    The Go race detector is pretty good at catching everything if your unit tests cover all the code, and of course, run the goroutines at the same time. Or maybe those are integration tests. Whichever they are, things are tested.

    Almost all of the nil pointers and interface{} errors in Go aren't safety problems because they just cause a panic and abort the program. Of course, you can write "unsafe" in Go, and that is just as bad as doing it in C. But the same is true of Rust.

    Go seems very safe overall. The worst bugs I've seen are hangs, panic crashes and unlimited memory usage. Nothing that would be a security problem. Just denial of service.

    Comment


    • #12
      Originally posted by Zan Lynx View Post

      I'm doing Go professionally at the moment myself. And I do some Rust for fun.

      The Go race detector is pretty good at catching everything if your unit tests cover all the code, and of course, run the goroutines at the same time. Or maybe those are integration tests. Whichever they are, things are tested.

      Almost all of the nil pointers and interface{} errors in Go aren't safety problems because they just cause a panic and abort the program. Of course, you can write "unsafe" in Go, and that is just as bad as doing it in C. But the same is true of Rust.

      Go seems very safe overall. The worst bugs I've seen are hangs, panic crashes and unlimited memory usage. Nothing that would be a security problem. Just denial of service.
      Could the unlimited memory usage you mention be a security problem? I've seen many many bug reports about memory usage being the cause of various security flaws.

      EDIT: Generally speaking of course, I've never seen anything specific about Go memory usage causing a problem.

      Comment


      • #13
        Originally posted by caligula View Post

        Keep in mind that many phoronix readers cannot even develop code. We have all sorts of rastermans happy with void* types all over the place.. the guys have zero knowledge of algebraic types and strong types, proofs, invariants etc.
        And you are?

        Any one piece of well known software we should know you by?

        Comment


        • #14
          Originally posted by duby229 View Post
          Could the unlimited memory usage you mention be a security problem? I've seen many many bug reports about memory usage being the cause of various security flaws.
          It is eventually a denial of service problem. Not a security problem. This is the only kind of memory bug that GC languages get. Unless there's a bug in the GC of course, heh.

          The program has some kind of problem, like maybe it keeps adding to a memory buffer but never releasing references to it. So the program just keeps adding more and more gigabytes until it runs out, usually at 3 AM. This can happen in Go if someone tries to be a bit too clever with buffers and slices. A tiny slice of just 4 characters or so can keep alive a 64 KB buffer.

          Comment


          • #15
            It seems a bit disingenuous for intel to use the term "container" for what is clearly VM technology, where each virtual node runs it's own kernel, to manage it's own imaginary hardware. These are not containers, they are VMs.

            Comment

            Working...
            X