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

41–50 of 88 posts

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

#41

Post by masklinn »

pkaye wrote: post #9
SquishyPanda23 wrote: post #6

Earlier quoted context omitted.

Most modern languages have solved the problem. There are a variety of ways to do it.

Can you list the variety of ways?

I don't know about "variety of ways". You just make it so pointers can't be null, then provide a mechanism for opt-in nullability, requiring an explicit check / conversion to get a non-nullable pointer (which you can dereference) and allowing free / cheap / implicit conversion from non-nullable to nullable. This can be:

* separate pointer types (e.g. C++ pointers v references)

* a built-in sigil / wrapper / suffix e.g. C#'s Nullable / `?` types

* a bog-standard userland sum type e.g. Maybe/Option/Optional

In modern more procedural languages the third option often will have language-level (non-userland) facilities tackled on for better usability but that's not a requirement.

For cases (2) and (3) it can (depending on language and implementation) also provides a mechanism for making other value types optional without necessarily having to heap-allocate them.

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

#42

Post by HALtheWise »

brundolf wrote: post #10

I've wondered what it would be like to write a thin language that compiles to Go and mainly serves to introduce a reasonable type system on top, while benefitting from its performance and garbage-collection. Could prevent null dereferencing, among other things

Long ago I hacked together a weekend project with a friend of "JSX for go" that allowed embedding html tags into Go source like people do for react. We were pleasantly surprised how readable and flexible the Go parser source code was, even for the pretty dramatically different syntax we were trying to support.

https://github.com/8byt/gox

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

#43

Post by masklinn »

izgzhen wrote: post #23
SquishyPanda23 wrote: post #3

Earlier quoted context omitted.

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

Golang doesn’t have a proper generics support at its beginning. It is too late now.

You don't even need generics to avoid nullable pointers, you can special-case it as they special-cased slices, maps, channels, etc… e.g. `*int` -> non-nullable pointer to int; `?int` -> nullable pointer to int, and a tiny bit of flow analysis in nil checks so e.g. `if foo != nil` implicitly creates a new non-nullable version of `foo` inside the block body.

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

#44

Post by logicchains »

tptacek wrote: post #34
SquishyPanda23 wrote: post #3

Earlier quoted context omitted.

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

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.

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

#45

Post by noisy_boy »

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/

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.

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

#46

Post by jmnicolas »

nemo1618 wrote: post #31
brundolf wrote: post #10

I've wondered what it would be like to write a thin language that compiles to Go and mainly serves to introduce a reasonable type system on top, while benefitting from its performance and garbage-collection. Could prevent null dereferencing, among other things

It is super weird to me that no big compile-to-Go languages have emerged. It doesn't seem like anyone is even trying! Why not?

> Why not?

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

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

#47

Post by Nullabillity »

tptacek wrote: post #34
SquishyPanda23 wrote: post #3

Earlier quoted context omitted.

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

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…

Sure, but if they can't even get the boring stuff right then why bother moving on to a deeper evaluation?

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

#48

Post by scns »

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.

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.

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

#49

Post by Zababa »

SquishyPanda23 wrote: post #15
pkaye wrote: post #9

Earlier quoted context omitted.

Can you list the variety of ways?

Basically if you need to manipulate pointers, use safe pointers and keep track of pointer ownership. This is how modern C++ and Rust work. If you don't need to manipulate pointers then nil really just represents a degenerate or optional value. For optional values these can be encoded any number of ways depending on the type system. One common pattern is an optional type. Another is to annotate the type to indicate th…

> So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile.

I think that's a good explanation of why people are so frustrated with this. There are lots of features like go fmt, go vet, the compiler checking that you use all variables and all imports that can feel a bit restrictive. But for something like null pointers, there is nothing. It's incoherent.

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

#50

Post by scns »

smabie wrote: post #27
brundolf wrote: post #14

Earlier quoted context omitted.

That's the idea! I use Rust for a lot of personal projects mainly because of the type system, not because it doesn't have GC. I think GC's totally livable for a great many things, and it would help iteration speed a lot to not have to deal with the borrow-checker, but I just can't stand working in a language with a shaky type system these days. So Go-with-good-types sounds fantastic to me.

How about OCaml?

OCaml will be a viable alternative when multithreading works, hopefully soon.
Post reply on HN