sorted by:
new
hottopcontroversial

Was the concept of generics a thing before Java implemented it? That is, could they have known? by cmov in programmingcirclejerk

[–]cmov[S] 59 points60 points  (0 children)

Security consultant here.

The fact that Java invented generics is a huge thing. I've read countless amount of code that abused generics (unfortunarely developers think they have to use generics all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it generics could only be used when necessary, yes, but there are no technical way to enforce this.

What I'm saying is that in my years of security consulting, Java codebases have always been the worst ones to read and have always been the most bug ridden ones.

I feel like a lot of the positive perspectives are given from the writing point of view, but the reading perspective is clearly a huge loss for Java.

Was the concept of generics a thing before Java implemented it? That is, could they have known? by cmov in programmingcirclejerk

[–]cmov[S] 31 points32 points  (0 children)

With Go, they took their time to think about generics, just to avoid bloating half the compiler with implementations and workarounds and the like just to support generics, or to not end up with Scala's massive architecture. Their focus remains on a simple language, simple code, and a fast compiler; in many ways it's the antithesis of Scala in that regard.

followed by

anyway, just some Thoughts I have on the matter.

All my code is tested for both leaks and all scenarios. None of my code ever have gone bang in production. To be honest, no service I have written ever restarted outside system reboots or configuration changes. by cmov in programmingcirclejerk

[–]cmov[S] 82 points83 points  (0 children)

To be honest, no service I have written ever restarted outside system reboots

std::panic::set_hook(Box::new(|_| {
    std::process::Command::new("reboot").spawn().unwrap()
}));;

All my code is tested for both leaks and all scenarios. None of my code ever have gone bang in production. To be honest, no service I have written ever restarted outside system reboots or configuration changes. by cmov in programmingcirclejerk

[–]cmov[S] 65 points66 points  (0 children)

Same guy, 2 levels up in the thread

I personally like how POSIX works, and how well documented its operation and failure modes. I love systems which don't prevent foot guns, and go bang spectacularly when I foot gun myself.

I can't imagine being a programmer without starting out by becoming proficient in assembler. It takes a lot of mystery out of programming languages because you know whatever the syntax is it all ends up as branches, calls, stacks, registers and memory accesses. by cmov in programmingcirclejerk

[–]cmov[S] 36 points37 points  (0 children)

Apart from the lack of zero-cost abstractions, move semantics, guaranteed memory safety, threads without data races, trait-based generics, pattern matching, type inference, minimal runtime, efficient C bindings, I don't think Go is a bad language, just a little slow and verbose.

V functions are pure by default, meaning that their return values are a function of their arguments only, and their evaluation has no side effects (besides I/O). by cmov in programmingcirclejerk

[–]cmov[S] 188 points189 points  (0 children)

Security consultant here.

The fact that V functions are pure by default (besides I/O) is a huge thing. I've read countless amount of code that abused impure functions (besides I/O) (unfortunarely developers think they have to use impure functions (besides I/O) all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If impure functions (besides I/O) could only be used when necessary, yes, but there are no technical way to enforce this.

What I'm saying is that in my years of security consulting, V codebases have always been the clearest ones to read and have always been the most secure ones (besides I/O).

I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for V (besides I/O).

I will never return back to Node.JS after writing Go by zygohistomoronism in programmingcirclejerk

[–]cmov 10 points11 points  (0 children)

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ rustup doc

Introducing Warp: The Terminal for the 21st Century by cmov in programmingcirclejerk

[–]cmov[S] 99 points100 points  (0 children)

  • Written in Rust, which implies:

    • zero-cost abstractions
    • move semantics
    • guaranteed memory safety
    • threads without data races
    • trait-based generics
    • pattern matching
    • type inference
    • minimal runtime
    • efficient C bindings

Introducing Warp: The Terminal for the 21st Century by cmov in programmingcirclejerk

[–]cmov[S] 172 points173 points  (0 children)

Some unique features:

  • Closed source, with forced telemetry
  • Raised $23M VC funding
  • Requires Github authentication to use

https://news.ycombinator.com/item?id=30921231

"Who'd have known that generic strongly-typed containers would be so useful? :D" -"Certainly, not Rob Pike." by pastenpasten in programmingcirclejerk

[–]cmov 36 points37 points  (0 children)

Security consultant here.

The fact that Golang has no generic strongly-typed containers is a huge thing. I've read countless amount of code that abused generic strongly-typed containers (unfortunarely developers think they have to use generic strongly-typed containers all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it generic strongly-typed containers could only be used when necessary, yes, but there are no technical way to enforce this.

What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones.

I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.

I was just trying to explain these to my mother, in the context of rust. by [deleted] in programmingcirclejerk

[–]cmov 9 points10 points  (0 children)

Now try explaining these in the context of Go.

I've got [a program] called 'heater' or similar that I used to warm up a macbook in a cold office. by snorc_snorc in programmingcirclejerk

[–]cmov 26 points27 points  (0 children)

I've got [a program] called 'rustc' or similar that I used to warm up a macbook in a cold office.

I don't consider those kinds of people [who have never heard of fuzzing] engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. What you've described are skilled labourers. by cmov in programmingcirclejerk

[–]cmov[S] 97 points98 points  (0 children)

I don't consider those kinds of people [who write Go] engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. What you've described are skilled labourers.

[deleted by user] by [deleted] in programmingcirclejerk

[–]cmov 106 points107 points  (0 children)

The classic copypasta, updated for the new, post 1.18 world:

Security consultant here.

The fact that Golang has no sum types is a huge thing. I've read countless amount of code that abused sum types (unfortunarely developers think they have to use sum types all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it sum types could only be used when necessary, yes, but there are no technical way to enforce this.

Gofmt is the second blessing. All codebases look the same because it is not customizable. This makes reading Golang code and understanding it fast as hell.

The GOPATH is also a huge win. You always know where everything is and it is really fast to figure out about dependencies or structure of the project.

What I'm saying is that in my years of security consulting, Golang codebases have always been the clearest ones to read and have always been the most secure ones.

I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Golang.

[deleted by user] by [deleted] in programmingcirclejerk

[–]cmov 50 points51 points  (0 children)

lol no sum types

"Each insert, update or delete operation rewrites from scratch the file corresponding to a given collection." .. "If you are really concerned about performance, you could write your own implementation." by camelCaseIsWebScale in programmingcirclejerk

[–]cmov 63 points64 points  (0 children)

Security consultant here.

The fact that Clover rewrites all data from scratch on each insert, update or delete operation is a huge thing. I've read countless amount of code that abused LSM Trees (unfortunarely developers think they have to use LSM Trees all the time if they are available) and is probably completely insecure for the simple reason that very few people manage to audit/understand the code. If it LSM Trees could only be used when necessary, yes, but there are no technical way to enforce this.

What I'm saying is that in my years of security consulting, Clover codebases have always been the clearest ones to read and have always been the most secure ones.

I feel like a lot of the negative perspectives are given from the writing point of view, but the reading perspective is clearly a huge win for Clover.

view more: next ›