Live data from Hacker News

Go 2018 Survey Results

blog.golang.org

21–30 of 91 posts

Re: Go 2018 Survey Results

#21
post #16
post #11

I'm a big fan of both Go and Rust, and it's really interesting to see Rust ranked #3 in preference but #17 in expertise. Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)

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

I agree with you, but I still think you're going to see Go, Rust and friends eating away at that code base.

FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.

Re: Go 2018 Survey Results

#23
post #16
post #11

I'm a big fan of both Go and Rust, and it's really interesting to see Rust ranked #3 in preference but #17 in expertise. Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)

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.

Re: Go 2018 Survey Results

#24
Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow.

When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects.

Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C.

Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment.

Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done.

Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.

Re: Go 2018 Survey Results

#25
post #23
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.

That's largely because it's the easiest way to deal with Custom Resource Definitions within Kubernetes, and because many of the tools that make writing a Controller or Operator easy are only exposed as internal APIs.

Re: Go 2018 Survey Results

#26
post #25
post #23

Earlier quoted context omitted.

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

That's largely because it's the easiest way to deal with Custom Resource Definitions within Kubernetes, and because many of the tools that make writing a Controller or Operator easy are only exposed as internal APIs.

It's also because a k8s daemonset or sidecar takes 5 to 10x less memory to run using Go. No one wants to run small pods with JVM and xms / xmx settings to 512MB.

Re: Go 2018 Survey Results

#27

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large pro…

> Your company should be pivoting or have a strategy to get on deck with these languages.

That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.

Re: Go 2018 Survey Results

#28
post #27

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large pro…

> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.

I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.

Re: Go 2018 Survey Results

#29
post #27

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large pro…

> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.

Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo.

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) or use stuff that has security holes or that will change out from under us (npm).

Re: Go 2018 Survey Results

#30
post #6

Earlier quoted context omitted.

The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting. Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team kn…

As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and li…

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 be useful in that space, is it?

Post reply on HN