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

Go 2018 Survey Results

blog.golang.org

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Go 2018 Survey Results

#41

Post by alexkavon »

imetatroll wrote: post #40
mynegation wrote: post #36

Earlier quoted context omitted.

> What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixe…

You can define methods on structs which is not unlike classes. You can define an interface with methods that allow objects to be processed in a more generic fashion. I think that more than anything it would require a change of mindset that people understandably don't want to deal with.

There's also always a package to handle that issue. [0][1][2]

As well as other options. [3]

I like to imagine that the "no generics, no way" crowd would never use the stairway in their building if the elevator broke down.

[0] https://github.com/clipperhouse/gen [1] https://github.com/cheekybits/genny [2] https://github.com/cosmos72/gomacro [3] https://appliedgo.net/generics/

Re: Go 2018 Survey Results

#42

Post by alexkavon »

frou_dh wrote: post #20
alexkavon wrote: post #13

> VS Code and GoLand are surging in popularity and are now the most popular code editors among survey respondents. I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy. I've used VSCode for a while…

At the end of last year, a great systematic rewrite of Sublime's Go grammar was merged. So at that (admittedly surface-) level, it's doing very well. I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to…

Agreed, this is actually on my todos, just haven't executed yet.

Re: Go 2018 Survey Results

#43

Post by chessturk »

mynegation wrote: post #36
chessturk wrote: post #30

Earlier quoted context omitted.

Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would b…

> What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixe…

Thanks for the detailed reply, that helps a lot :)

Re: Go 2018 Survey Results

#44

Post by chmln »

ilovecaching wrote: post #35
chmln wrote: post #32

Earlier quoted context omitted.

It's a bit ridiculous to reduce Rust to the requirement of "performance" or parametric polymorphism. Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions…

> Go doesn't have a proper, complete type system. This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions. We are still not at a place yet where the from first principles, type driven approach is going to a…

> This is nonsense. There's no definition or checklist that defines what a complete type system is

The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics.

Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best.

> We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach.

Why not?

Re: Go 2018 Survey Results

#45

Post by ramenmeal »

chmln wrote: post #44
ilovecaching wrote: post #35

Earlier quoted context omitted.

> Go doesn't have a proper, complete type system. This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions. We are still not at a place yet where the from first principles, type driven approach is going to a…

> This is nonsense. There's no definition or checklist that defines what a complete type system is The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack…

I think I'm misunderstanding, but doesn't Java and C# allow you to pass null in the place of an object?

Re: Go 2018 Survey Results

#46

Post by chmln »

ramenmeal wrote: post #45
chmln wrote: post #44

Earlier quoted context omitted.

> This is nonsense. There's no definition or checklist that defines what a complete type system is The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack…

I think I'm misunderstanding, but doesn't Java and C# allow you to pass null in the place of an object?

Yes, I know Java for sure allows this. There are workarounds to enforce stricter behavior via things like @NonNull and checker frameworks, but it obviously never works as well as it would on a language level.

Re: Go 2018 Survey Results

#47

Post by saagarjha »

ramenmeal wrote: post #45
chmln wrote: post #44

Earlier quoted context omitted.

> This is nonsense. There's no definition or checklist that defines what a complete type system is The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack…

I think I'm misunderstanding, but doesn't Java and C# allow you to pass null in the place of an object?

They do, and this has largely been regarded as a hole in the type system.

Re: Go 2018 Survey Results

#48

Post by aprdm »

ilovecaching wrote: post #34
treis wrote: post #33

Earlier quoted context omitted.

>Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably…

> The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kub…

Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that but you're speaking as if Python or Ruby were usually used in the context of building infrastructure-level services (k8s, dbs, consul, docker, etc.) instead of business logic / applications kind of services ( gitlab, shopify, your usual startup CRUD).

Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.

Re: Go 2018 Survey Results

#49

Post by pjmlp »

Thaxll wrote: post #23
pjmlp wrote: post #16

Earlier quoted context omitted.

Go has not displaced anything around here. Still plain old Java, .NET and C++ as always.

Depends where you work, but if it's related to Kubernetes, service mesh ect ... Go is pretty popular nowdays.

Not everyone is on the K8s, Docker hype.

They are today's NoSQL.

Re: Go 2018 Survey Results

#50

Post by Zancarius »

aprdm wrote: post #48
ilovecaching wrote: post #34

Earlier quoted context omitted.

> The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kub…

Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that but you're speaking as if Python or Ruby were usually used in the context of building infrastructure-level services (k8s, dbs, consul, docker, etc.) instead of business logic / applications kind of services ( gitlab, shopify, your usual startup CRUD). Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like y…

> You wouldn't want to create gitlab V1 with Go

Does Gitea[1] count (fork of Gogs)?

I understand your point (I love Python, too), but I can't help finding some amusement in it since it has been done. :)

[1] https://github.com/go-gitea/gitea

Post reply on HN