Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GoKart: A static analysis tool for securing Go code

github.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: GoKart: A static analysis tool for securing Go code

#61

Post by pjmlp »

logicchains wrote: post #44
tptacek wrote: post #34

Earlier quoted context omitted.

Then it boggles your mind that Go functions the way most popular languages work. You don't see so much dunking on Python, Java, Clojure, Ruby, &c, over this, even though these languages dominate the leaderboards. Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, de…

>You don't see so much dunking on Python, Java, Clojure, Ruby, &c, One of the common arguments now for why C# is superior to Java is that it supports non-nullable references. As does C++, which for large latency-sensitive projects is generally picked over C.

Which almost no one uses, because it is more trouble than it is worth on existing code bases, and requires everything to be on latest versions.

Re: GoKart: A static analysis tool for securing Go code

#62

Post by pjmlp »

radicalbyte wrote: post #54
scns wrote: post #48

Earlier quoted context omitted.

I'd say it has been a better designed language for sure, which wasn't that hard since they just needed to take a look where Java messed up. So many things are obvious in hindsight so it's not a fair comparison. Regarding platform and reach, Java still wins i guess. Disclaimer: Using neither.

C# has a higher rate of change than Java and a very strong ecosystem - albeit not quite as strong as Java. The tooling - if you pay for it - is in my opinion much better. The thing is, the Java ecosystem is insane. What else comes close to it in breadth and quality? Python, Go, Ruby etc certainly don't. C++?

C++ yes. That is why despite its flaws and complexity, it will be around for decades to come.

Even on the places where Java and .NET languages took over C++ hegemony, it is still there on the implementation of native/extern methods and COM/UWP libraries.

Also don't forget if your favourite compiler is a LLVM/GCC frontend, many of its improvements require a bit of C++ code changes as well.

Re: GoKart: A static analysis tool for securing Go code

#63

Post by pjmlp »

Zababa wrote: post #52
jmnicolas wrote: post #46

Earlier quoted context omitted.

> Why not? Why? What would be the point except as a personal challenge?

Most criticisms of Go could be adressed by a language with a Hindley-Milner type system: https://go.dev/blog/survey2020/missing_features.svg from https://go.dev/blog/survey2020-results . Having a ML-like that compiles to Go could solve all those issues, while still keeping the great ecosystem that Go managed to build. Just like with Scala, this new language could allow people to see if that's what they really want, a…

For that I already have OCaml, Haskell and F#, so why bother?

Re: GoKart: A static analysis tool for securing Go code

#64

Post by pjmlp »

still_grokking wrote: post #26
noisy_boy wrote: post #22

Earlier quoted context omitted.

I wrote one component in go - it does everything that is expected from it with good performance without having to deal with virtualenv/jvm dependencies. However I don't want to write that much code again. Only of there was a language with ecosystem/brevity/garbage collection of Java, strong type system/pattern matching of Rust, excellent multi-threading of go and produced a dependency free binary.

Scala Native probably. But I've never used it so not sure how mature it is. https://scala-native.org/ The other Go alternative I see is D. Close to the metal but with high level features. Runs in a managed runtime. Creates native code. https://dlang.org/

D is more than that, think of C# as version 1.0 should have been all along.

Re: GoKart: A static analysis tool for securing Go code

#65

Post by pjmlp »

noisy_boy wrote: post #45
still_grokking wrote: post #26

Earlier quoted context omitted.

Scala Native probably. But I've never used it so not sure how mature it is. https://scala-native.org/ The other Go alternative I see is D. Close to the metal but with high level features. Runs in a managed runtime. Creates native code. https://dlang.org/

Thanks for reminding me about D - I've always heard about it but never checked it out. Will try it out to see how it feels.

Be prepared that D kind of struggles with having a small community, other than that, it is a very nice C# like language with systems programming capabilities and AOT compilation.

Re: GoKart: A static analysis tool for securing Go code

#66

Post by Zababa »

pjmlp wrote: post #63
Zababa wrote: post #52

Earlier quoted context omitted.

Most criticisms of Go could be adressed by a language with a Hindley-Milner type system: https://go.dev/blog/survey2020/missing_features.svg from https://go.dev/blog/survey2020-results . Having a ML-like that compiles to Go could solve all those issues, while still keeping the great ecosystem that Go managed to build. Just like with Scala, this new language could allow people to see if that's what they really want, a…

For that I already have OCaml, Haskell and F#, so why bother?

OCaml and Haskell don't have Go's ecosystem in terms of quantity. For F#, can it be compile to a binary like Go? I searched for a bit and couldn't find a good answer. Another thing is that people like to stay in their ecosystems. If you already have a large codebase in Go, internal libraries, etc, switching could be difficult.

Re: GoKart: A static analysis tool for securing Go code

#67

Post by pjmlp »

Zababa wrote: post #66
pjmlp wrote: post #63

Earlier quoted context omitted.

For that I already have OCaml, Haskell and F#, so why bother?

OCaml and Haskell don't have Go's ecosystem in terms of quantity. For F#, can it be compile to a binary like Go? I searched for a bit and couldn't find a good answer. Another thing is that people like to stay in their ecosystems. If you already have a large codebase in Go, internal libraries, etc, switching could be difficult.

Quantity isn't a synonym for quality.

There are a couple of ways to compile .NET code into native code. Since version 1.0 NGEN was part of the SDK, although its main purpose was faster startup with dynamic linking.

On Microsoft side there has been CoreRT, NativeAOT, .NET Native.

Mono has had AOT support since ages and it is anyway required for iOS deployments.

Other than that several community efforts have taken place as well, for example WebAssembly.

https://fsbolero.io/

Re: GoKart: A static analysis tool for securing Go code

#68

Post by Zababa »

pjmlp wrote: post #67
Zababa wrote: post #66

Earlier quoted context omitted.

OCaml and Haskell don't have Go's ecosystem in terms of quantity. For F#, can it be compile to a binary like Go? I searched for a bit and couldn't find a good answer. Another thing is that people like to stay in their ecosystems. If you already have a large codebase in Go, internal libraries, etc, switching could be difficult.

Quantity isn't a synonym for quality. There are a couple of ways to compile .NET code into native code. Since version 1.0 NGEN was part of the SDK, although its main purpose was faster startup with dynamic linking. On Microsoft side there has been CoreRT, NativeAOT, .NET Native. Mono has had AOT support since ages and it is anyway required for iOS deployments. Other than that several community efforts have taken plac…

You're right about quantity and quality, that's why I mentionned quantity precisely. Quantity usually means that most of the stuff has already been made by someone, and people seem to value that a lot. I'll add that the documentation of your average OCaml or Haskell library is not the best, while from experience Go is a bit better (usually there are a few basic examples).

Thank you for the information on .NET AOT.

Re: GoKart: A static analysis tool for securing Go code

#69

Post by maleldil »

hnlmorg wrote: post #53
nyanpasu64 wrote: post #38

Earlier quoted context omitted.

- MyPy doesn't have pervasive nullability, but distinguishes nullable and non-nullable types in the type system. A function declared to return int but randomly returns None has a bug in its type hints. - I dunk on Java for pervasive nullability too (though there are tools that add @Nullable xor @NonNull annotations used for analysis, possibly sound). But Go has over a decade more hindsight and should've known better.…

> [Python] distinguishes nullable and non-nullable types in the type system. A function declared to return int but randomly returns None has a bug in its type hints. Go distinguishes between the two too. You cannot pass nil as a value to int. In fact in Go you'd get a compiler warning[0] so you don't even need to rely on type hints and a properly set up CI/CD pipeline to catch said faults: The problem with Go is that…

The int example was a bit misguided, seeing as int is a primitive type in Go, different from pointer types. In Python, both are references.

Basically, it's the difference between returning None from a function `def f() -> MyClass` in Python (which is type error) versus returning nil from `func f() &MyClass`, which is completely normal in Go.

Having `Optional` in the function signature makes it explicit that one has to check for Nones. Go lacks that.

Re: GoKart: A static analysis tool for securing Go code

#70

Post by drvd »

SquishyPanda23 wrote: post #3
the-smug-one wrote: post #2

Go has some nice tooling which is quite easy to use w.r.t. static analysis. I started writing a nil pointer analysis tool which was going to take advantage of and provide some more advanced information*. I "unfortunately" had a lot more fun stuff to do during my vacation, but it was very easy to get started with! So kudos to the Go team for making this kind of stuff possible for a 1-man team. * Just a forward-style a…

> I started writing a nil pointer It still boggles my mind that Go decided to force programmers to worry about nil pointers.

Programming in Go since 10 years and I do not have to worry about nil pointers. You seem to assume that the possibility of a pointer being nil is something that is complicated, a burden to the programmer and a source of runtime bugs. It's not. At least not in Go. At least not something you have to worry about in practice.
Post reply on HN