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

81–90 of 91 posts

Re: Go 2018 Survey Results

#81

Post by pjmlp »

ilovecaching wrote: post #69
pjmlp wrote: post #52

Earlier quoted context omitted.

> 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.

Most of them of "Hello World" quality hardly usable in production.

Re: Go 2018 Survey Results

#82

Post by pjmlp »

ilovecaching wrote: post #77
pjmlp wrote: post #49

Earlier quoted context omitted.

Not everyone is on the K8s, Docker hype. They are today's NoSQL.

You mean Google of a decade ago. Borg is old and containerization is ancient. I'm guessing your job relies on people sticking with Java SQL stacks.

My job relies on people that don't have ghost dreams about their business being web scale.

Re: Go 2018 Survey Results

#83

Post by pjmlp »

raxxorrax wrote: post #72
pjmlp wrote: post #65

Earlier quoted context omitted.

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.

Maybe not. But users might go somewhere else. I have yet to meet anyone in real life that developed anything with UWP because it allegedly (has been a while) still lacks very basic features relating to UI at least (i know it is not restricted to that). I have nothing against WPF, although I am not a fan of XAML. But I think MS isn't really focusing on it. We will see. I used WPF in medical applications like you said,…

Yeah, I guess Adobe, startups creating HoloLens content, might be told otherwise then.

Re: Go 2018 Survey Results

#84

Post by erik_seaberg »

ilovecaching wrote: post #69
pjmlp wrote: post #52

Earlier quoted context omitted.

> 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.

If you reuse a library, you reuse all the debugging work and fixes invested in it. "Shoulders of giants" and all that.

If everyone rewrites their own, nobody will ever help you with yours.

Re: Go 2018 Survey Results

#85

Post by newalexandria »

alexkavon wrote: post #41
imetatroll wrote: post #40

Earlier quoted context omitted.

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/

Maybe language communities are formed from people that need or don't-need those kind of affordances. e.g. Imagine the office environment you'd have if all your cohort were people that walked 20 flights without making it an issue.

Re: Go 2018 Survey Results

#86

Post by ilovecaching »

bovermyer wrote: post #80
ilovecaching wrote: post #78

Earlier quoted context omitted.

Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide th…

But why would they need to move to Go, if what they have works? To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?

Businesses don't stand still, you're either actively working on a product, or you're building a new product and the old product is in maintenance mode. So to follow your analogy, a businesses is always trying to get itself into a new car. If electric cars are the future, they don't want to be in a gas powered Honda Accord while their competition is riding around in Teslas.

In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.

Re: Go 2018 Survey Results

#87

Post by bovermyer »

ilovecaching wrote: post #86
bovermyer wrote: post #80

Earlier quoted context omitted.

But why would they need to move to Go, if what they have works? To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?

Businesses don't stand still, you're either actively working on a product, or you're building a new product and the old product is in maintenance mode. So to follow your analogy, a businesses is always trying to get itself into a new car. If electric cars are the future, they don't want to be in a gas powered Honda Accord while their competition is riding around in Teslas. In larger companies, spending less on gas ca…

So what would you say to Basecamp, then? "Get thee to Go, heathen!" ?

Re: Go 2018 Survey Results

#88

Post by treis »

ilovecaching wrote: post #75
treis wrote: post #73

Earlier quoted context omitted.

You said: >we don’t get stuck in frameworks that become legacy (rails) And now advocate >Go has a massive ecosystem of third parties libraries What is so special about these libraries that prevent them from becoming legacy?

Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choice for supposed convenience. Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface. Libraries are replaceable, frameworks are usually not. In Go, if…

This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries.

>Frameworks trade choice for supposed convenience.

It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained.

>Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.

What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense.

And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.

Re: Go 2018 Survey Results

#89

Post by brrt »

zaphirplane wrote: post #56
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…

There is a strong narrative around rust being suitable for “extracting/wringing/squeezing” the last drop of performance. Why do people pushing those claims think a go program compiled down to native executable is slower then rust Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w

No horse in the race, but:

- The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining).

- Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types.

- Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust.

So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language.

Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.

Re: Go 2018 Survey Results

#90

Post by pjmlp »

ilovecaching wrote: post #67
otabdeveloper1 wrote: post #60

Earlier quoted context omitted.

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…

Those same people are less likely to throw their company jewels away and rewritte everything from scratch, specially if they are using UI toolkits, graphical debuggers, game engines or GPGPU.
Post reply on HN