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

61–70 of 91 posts

Re: Go 2018 Survey Results

#61

Post by bschwindHN »

otabdeveloper1 wrote: post #60
ilovecaching wrote: post #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 pro…

Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start. But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line. If you want a working pain-free solution learn C++17 instead.

> If you want a working pain-free solution learn C++17 instead

A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?

Re: Go 2018 Survey Results

#62

Post by snaky »

vardump wrote: post #37
pjmlp wrote: post #16

Earlier quoted context omitted.

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

Where I'm located, .NET has died years ago. Just Java, Go and C++ now. I guess these things are regional. Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.

> There is an old study about 4.5 million .NET developers in 2004. Today, if I have to guess, there are at least 7-8 million .NET developers in the world.

https://www.c-sharpcorner.com/forums/how-many-c-sharp-develo... (2014)

Re: Go 2018 Survey Results

#63

Post by gray_-_wolf »

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…

> Ruby, which was a one trick pony

citation needed

Re: Go 2018 Survey Results

#64

Post by jbergens »

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…

Aren't there more third party libraries for java than for go? Then that is no reason to go from java.

Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications.

It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.

Re: Go 2018 Survey Results

#65

Post by pjmlp »

raxxorrax wrote: post #58
vardump wrote: post #37

Earlier quoted context omitted.

Where I'm located, .NET has died years ago. Just Java, Go and C++ now. I guess these things are regional. Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.

Same here... .net core is around but the APIs and runtimes MS created aren't really loved by anyone. With WPF seemingly abandoned and UWP being ... itself, there isn't much enthusiasm left. A little sad, since I believe C# to be superior to JAVA, but I haven't used it for anything for about two years now. It maybe won't go away, but I think it lost a lot of relevance.

WPF is one of the corner stones of .NET Core 3.0, and one of the UI frameworks mostly used in life sciences device management UIs.

UWP isn't going anywhere, as much as haters would like to.

Re: Go 2018 Survey Results

#66

Post by hactually »

mynegation wrote: post #14
ntnn wrote: 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…

I've worked on financial applications, and esp in the fintech space here in Sydney, a lot are using go.

Java/net are just not fun and the mentality of the developers seems off-putting to a lot of new devs and those seeking to move fast and ship stable.

Re: Go 2018 Survey Results

#67

Post by ilovecaching »

otabdeveloper1 wrote: post #60
ilovecaching wrote: post #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 pro…

Rust is a nice idea, but as of 2019 C++17 is simply better in every way. Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start. But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line. If you want a working pain-free solution learn C++17 instead.

This is a really bold statement that sounds like it’s coming from someone who is afraid that their knowledge of C++ is going to be obsoleted in a few years.

C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on.

Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.

Re: Go 2018 Survey Results

#68

Post by ilovecaching »

jbergens wrote: post #64
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…

Aren't there more third party libraries for java than for go? Then that is no reason to go from java. Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications. It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that…

For libraries, I have never once found Go lacking. I’ve noticed that because Go jumped to the front of the line quite recently you are more likely to find packages that are being actively maintained than Java.

That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang.

As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors.

As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.

Re: Go 2018 Survey Results

#69

Post by ilovecaching »

pjmlp wrote: post #52
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…

> Go has libraries for pretty much anything you could want to do. Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ... Modern infra is the NoSQL of 2019.

Go has libraries, more than you can count, for CRMs, PDF, GUIs (and TUIs), and DBs (including standard library support for SQL).

I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.

Re: Go 2018 Survey Results

#70

Post by bovermyer »

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…

I really enjoy Go and reach for it first when starting a project.

However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses.

Please don't trash talk other languages just because you have a favorite. It's unprofessional.

Post reply on HN