Live data from Hacker News

Just Use Go

blainsmith.com

201–210 of 238 posts

Re: Just Use Go

#201
post #200
post #142

Yeah, it breaks when the author decides to move from Github into Gitlab to protest against Microsoft. Time to update all code references to Gitlab across the globe, in every single Go project. Or spend the time configuring redirects between URL mappings, across everything that depends on it. Not to mention that except for lacking garbage collection, even Turbo Pascal 7 for MS-DOS was more modern in language features,…

> Yeah, it breaks when the author decides to move from Github into Gitlab to protest against Microsoft. The import path is disconnected from where the build system looks for the files. Of course, the default is to use the import path as an URL, right, but nothing forces you to do that. And if you do, *you* lock yourself to the hosting you use. But that can be hardly blamed on Go. Documentation here: https://pkg.go.de…

I am well aware, as you might find out in my comment history all the way back to Go pre 1.0.

Additional work that is superfluous in other mature programming ecosystems, that don't have the dumb idea to use SCM urls as import paths.

Re: Just Use Go

#202

I love go, but I find it did little to make concurrency management easier to reason about. Race conditions are easy to write. Go routines have all the same concurrency problems of threads. In the parallel HTTP fetcher, the error is discarded. This will likely result in a panic when the response is nil. Also, what if it a server locks up? Or the underlying socket never connects and never times out? I know it’s a toy e…

Its absolutely laughable that Gophers act like their language solves concurrency when its actually worse than Java because it has data races. Go added nothing and moved backwards.

The language that actually solves concurrency is Rust, but they will never acknowledge that.

Re: Just Use Go

#203

Earlier quoted context omitted.

> No one is impressed if you write some meta magic one-liner. I am very impressed if they can express the entire algorithm succinctly with a one liner. That's the kind of abstraction every piece of code should strive for and be shamed to the ground if they haven't. > I would rather be more impressed if I can read your code and form a mental image on how many paths your code takes to achieve an outcome in a single sit…

> if they can express the entire algorithm succinctly with a one liner > That's the kind of abstraction every piece of code should strive for and be shamed to the ground if they haven This obsession with one liners is inversely proportional to professional experience.

> This obsession with one liners is inversely proportional to professional experience.

Yes, I see this sentiment on every billboard. It is a sign of mediocrity.

Re: Just Use Go

#204

Earlier quoted context omitted.

My experience is directly counter. I've worked in half a dozen very large orgs and moving from interpreted languages to Go in each one made the system easier to reason about, more maintainable, and easier to onboard new team members. Go strikes a balance between all the competing priorities that has, in my personal experience, improved the engineering velocity across half a dozen companies comprised of hundreds of de…

Compared to a language like Python or Ruby, yes it's better for larger programs. Compared to the likes C# or Java? Not a chance.

Most former java devs I have worked with prefer Go after a year or so. Sample size is probably around 40 java devs leading to about 35ish Converts.

However, I have only worked with about 5 or so former C# and while they liked Go, they missed C#. Only one preferred Go.

C# is on my shortlist to pick up.

Re: Just Use Go

#205

Earlier quoted context omitted.

Compared to a language like Python or Ruby, yes it's better for larger programs. Compared to the likes C# or Java? Not a chance.

Most former java devs I have worked with prefer Go after a year or so. Sample size is probably around 40 java devs leading to about 35ish Converts. However, I have only worked with about 5 or so former C# and while they liked Go, they missed C#. Only one preferred Go. C# is on my shortlist to pick up.

I think this entirely depends on what kind of Java is being written. If you are Java developer on say Spring stack, moving to Go never ends up well in my experience. On several projects I worked on there was a push (strong word, more like investigation/POC) to start writing some services etc in Go and there was almost universal rejection at the end. So I think there is more to just language selection/preference but more like an entire ecosystem depending on what you are hacking

Re: Just Use Go

#206
post #197

Earlier quoted context omitted.

> Most of that was written by the Go team, not Google management, and even has the famous Rob Pike take on it. I am unable to understand your point or you seem to be making arguments that have nothing to do with the article nor with my earlier replies. I wonder why. Are you expecting sundar pichai to announce golang to his shareholders in his quarterly call? Which language does that? This article and my replies are t…

Because your narrative is wrong, it wasn't a Google project, it was a group of Google employees that rebeled and were lucky to have their line manager support, given being UNIX idols. Google upper management was, and is, perfectly fine with Java, Kotlin, C++ and Rust, for the most purposes. I won't suggest any "technical" answer, because clearly you only want Go.

> I won't suggest any "technical" answer, because clearly you only want Go

You can’t provide me any technical answer.

Re: Just Use Go

#207

I should write one of these for Haskell. Huffing abstractions is great for boring, line-of-business applications. Goroutines? Meh. Software transactional memory and green threads? Heck yeah. An actual type system? Chef's kiss. Scott Wlaschin from the F# world has written and talked extensively about F# for "boring" software. It works equally well in Haskell. You don't need to use type-level meta programming to spit o…

Goroutines are green threads.

Re: Just Use Go

#208
post #87

Earlier quoted context omitted.

My big issue with Go is, the language just isn't that great. Zero values instead of sum types, reflection instead of proper macros, a mediocre module system… Java's warts are far worse than Go. Everything is nullable. There's no module system to speak of. It's so IDE-dependant. I agree with the spirit of "use boring technology." So thank god Go is boring enough that I don't have to write Java anymore.

> Everything is nullable Only reference types, the same as in golang (which also has nullable pointers, and its interfaces interact weirdly with null). Java is getting value types, which can be declared as non-nullable. > There's no module system to speak of. https://dev.java/learn/modules/ > It's so IDE-dependant. Modern Java has been simplified that you can run a hello world program as follows: $ cat Hello.java voi…

> Only reference types, the same as in golang

Everything's a reference in Java except primitives, and even primitives get object wrappers. In Java, String, Long, and Bool can all be null. Go isn't like that—only explicit pointer types and interfaces can be nil. In practice it really cuts down on NPEs.

> https://dev.java/learn/modules/

Ok, granted, but I have never seen these in actual use. Java's ecosystem is big enough that you can use Java for years and not even know it has modules. I find this profusion of features unboring for the same reason that C++ is unboring.

In Go, everything's already in modules. It's just simpler. And when they did add generics, it was backwards-compatible, so there was no Java 8/Java 11 thing.

> Furthermore, any non-trivial project is better served with an IDE

In any other language, I can get by fine with vim + LSP regardless of project size. Java has a uniquely bad LSP story.

Re: Just Use Go

#209
post #51

Earlier quoted context omitted.

how is go a weakly typed version of python or php? or even more generic, how is go weakly typed? explain please.

I suspect that this is breaking type systems out onto separate axes: strong/weak and static/dynamic. Many consider Python to be strong/dynamic.

depending on the definition of static and dynamic, go could arguably be described as static (personally, i prefer declarative, as static is generally defined as something that i understand to be true for C but not for go), but that still does not make it weak.

Re: Just Use Go

#210
post #35

If you like a sort of weakly-typed version of Python or PHP, use Go. As the article points out it can be good for web forms. Not all development is web forms.

Strange position to take. Python and Go are both duck typed but given Go has compile time type checking it is providing another layer of safety. Could you add more detail supporting your stance?

I expressed that poorly. I'm saying Go adds a weak type system. Too weak for its own good. No sum types is the first dealbreaker. Even C had unions.
Post reply on HN