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

Just Use Go

blainsmith.com

Post reply on HN
Print view View original

181–190 of 238 posts

Re: Just Use Go

#181

Post by nurettin »

potato-peeler wrote: post #171
dualvariable wrote: post #136

> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. And these days people probably just type "tab" and their LLM assistant fill…

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go,…

> 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 sitting, instead of pinging you for a quick call to explain yourself.

Does this mean you're impressed by the ability to read go's if spaghetti?

Re: Just Use Go

#182

Post by calcifer »

BadBadJellyBean wrote: post #102
calcifer wrote: post #58

Earlier quoted context omitted.

> I'd like my IDE to tell me when I accidentally stopped implementing an interface I don't know about others, but Goland's analyser is pretty powerful and can navigate from interface to implementation(s) and vice versa.

In my experience only when you implement it correctly. If I add a new method to the interface I can't navigate to the implementations anymore because they don't completely implement the interface.

That's surely the correct behaviour?

Re: Just Use Go

#183

Post by jochem9 »

worldsayshi wrote: post #5

I often think of go as a "better" python. As in, easy to learn and easy to use. But also performant and the module system and package manager seem to be a little neater. (sorry for flamebait) But I wonder how well it can cover similar use cases? Go is great for devops and web backends. But what about AI and data science?

I used to do lots of data engineering in Python, then started doing all kinds of engineering in primarily Go.

The Go ecosystem for data is very limited. There are no widely supported dataframe libraries (like the og pandas and the newer polars written in rust and also available as a crate). Very few data science libs, a few decent gen AI libraries, but not as popular as their Python cousins.

Most of the work I do now is streaming data and very small batches. For that Go is amazing. I don't need dataframes to transform a json, combine it with a bunch of other data and write to a database. I just need to write that logic and make it go fast. Very easy in Go.

Re: Just Use Go

#185

Post by za3faran »

bccdee wrote: post #87
twic wrote: post #6

> The boring choice is the right choice. It always was. Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?

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
    void main() {
        IO.println("Hello");
    }
  $ java Hello.java
  Hello
Furthermore, any non-trivial project is better served with an IDE, regardless of language.

Re: Just Use Go

#186

Post by za3faran »

sethammons wrote: post #114
doodoostew wrote: post #91

I've worked on large Go codebases on large teams at large orgs with large dreams. That garbage us straight up unmaintainable in the large and nobody can convince me otherwise. I have deep knowledge of the language, platform, used it for over a decade. It sucks.

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.

Re: Just Use Go

#187

Post by xnorswap »

2ndorderthought wrote: post #148
xnorswap wrote: post #116

Earlier quoted context omitted.

I've never understood what is meant by "bloated", would you mind explaining, so perhaps I could better understand? If it's "Large standard library", I think that's a selling point. Having anything you need available ( although these days, via optional microsoft.* packages ) helps keep projects consistent between different places. If it means "Different ways to do the same thing", I can understand that criticism bette…

The .net sdk is like 1gb, go is like 60mb or something. It's annoying when that matters. More so, nothing happens quickly with it's tooling, and the tooling isn't friendly. All of a sudden I can't build my project in vsstudio(also bloated but admittedly optional but may be required depending on where you work). Clean build also fails. So I have to go to the command line and type in dotnet restore, dotnet build, magic…

That's quite a rant, but it seems like it's from experience with the old times. For the last decade or so it's been a completely different story.

System.Text.Json is part of the core standard library, the only reason to use Newtonsoft is developing on legacy applications.

Visual Studio isn't necessary or even much recommended any more. VSCode or any LSP editor works fine.

You don't need to install nuget, any more than you need to install cargo in rust, it's part of the SDK. You can also just edit the csproj in the same way you could edit your TOML file. It's XML, and you just add .

You can compile --self-contained to be able to run it somewhere without the runtime installed.

.NET has a long history, but almost none of these are actual points of friction in the current year.

Re: Just Use Go

#188

Post by potato-peeler »

pjmlp wrote: post #178
potato-peeler wrote: post #174

Earlier quoted context omitted.

Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments. The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same t…

Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project. Nothing else. The narrative of Google wanting Go never happened, it gets sold as such by many Googlers. Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android…

https://go.dev/doc/faq#creating_a_new_language

Re: Just Use Go

#189

Post by gib444 »

pjmlp wrote: post #179
gib444 wrote: post #147

Earlier quoted context omitted.

Well, Spring (Boot) is so hard to avoid running into at day jobs. And Spring is hell.

[flagged]

Why did you invent a false dichotomy in your head and stoop to a sarcastic swipe at a straw man? Hardly curiosity is it?

Re: Just Use Go

#190

Post by potato-peeler »

nurettin wrote: post #181
potato-peeler wrote: post #171

Earlier quoted context omitted.

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go,…

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

Post reply on HN