Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

311–320 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#311
post #254

Earlier quoted context omitted.

> Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boile…

I don’t think I’ve ever seen Java used in isolation without spring boot

Y'all need to get out more often! ;)

Yes, Spring Boot is very popular, but there is a whole world of Java outside Spring, even if you confine yourself to just web apps (which is far from the only domain in which Java is used).

Re: Lies we tell ourselves to keep using Golang

#312
post #260

The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examp…

I haven't used Go or Rust seriously, but have written some Go toy code. This part of your post struck a nerve with me. I modified it slightly, to relate to Go's error handling, for me at least: > often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of [Edit] adding if err != nil to every l…

> If something blows up in production

The problem is if it doesn’t quickly blow up, but instead silently corrupts data or causes other problems down the line that are hard to backtrack to that specific missing check.

Re: Lies we tell ourselves to keep using Golang

#313

Earlier quoted context omitted.

I find it difficult to see a standard where Rust is not ready for "serious work" but Haskell is.

I can install a working Haskell toolchain with my package manager instead of the farcical `curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh`. If you're an automation-oriented kind of person like it's my job to be, setting up repeatable toolchians based around the above is a total crock of shit.

[deleted]

Re: Lies we tell ourselves to keep using Golang

#314
post #92

Earlier quoted context omitted.

This has perhaps been my biggest pain-point with Golang.. Woe unto those who do not follow the idiosyncrasies of how golang handles versioning, package management, tooling etc. if this is really your most important part of a language I would whole-heartedly recommend looking at rust which has been a breathe of fresh air in terms of package management and tooling.

Golang has the most hilarious approach to date formatting

[deleted]

Re: Lies we tell ourselves to keep using Golang

#315

Earlier quoted context omitted.

If you think this is one of your stronger arguments, I think my point has been made.

Getting this right should be table stakes. Every non-Rustacean who has suddenly had Rust forced into their workflows asks for this to be solved, specifically, and the Rust community keeps digging its heels in. Haskell has its warts but it's not 101-level shit like this.

What is your threat model that isn't solved by some combination of a rust-toolchain file and using your package manager (nix or whatever) to install rustup?

If you want to isolate your build machines from the internet entirely, you're either going to use a hermetic build system and have some equivalent of vendoring your compiler, or manage your own internal package repository in which case you can just add your own Rust + Cargo build to it.

If you're paranoid about building the Rust compiler from source, you can even put in the effort into bootstrapping your own lineage. But given that you're ok relying on your package manager for Haskell, it seems like this isn't a huge problem for you.

Re: Lies we tell ourselves to keep using Golang

#316

Earlier quoted context omitted.

Also honestly it's very toxic to anybody right of center. It's the type that says "we're so accepting" when really they only are of certain stuff. Lots of pronoun people and making the mascot "non binary" is needlessly shoving their ideology down people's throat. Not a problem in the U.S. because it fits with the corporate woke ideology but sure as hell gonna be if they want more worldwide community. It's also way to…

"pronoun people" What, you cant handle queer people existing?

No post body was provided.

Re: Lies we tell ourselves to keep using Golang

#317
post #28
post #13

Earlier quoted context omitted.

I might not agree with fasterthanlime's opinion on Go (9/10 times I would opt to use Go over Rust), but calling this post a "shitpost" is unnecessarily dismissive. The post, like his previous post on Go, contain well thought out points that add to the discussion at the very least. Also I like his sense of humour :) Edit: though, I suppose saying Go is not designed is also equally unnecessarily dismissive and hyperbol…

> Portland Oregon, the capital of grunge, coffee, poor weather and whiteness it's kinda a shitpost

yeah the actual titleholder to those is seattle

Re: Lies we tell ourselves to keep using Golang

#318
post #7

Earlier quoted context omitted.

> the Rust community used to be known for its politeness and always being fair to other language communities I have no particular affinity for Go or Rust. As an outsider this is not how I’ve ever perceived the Rust community, because the most present and visible parts of the Rust community were people showing up and complaining that Project X didn’t use their preferred silver bullet

Also honestly it's very toxic to anybody right of center. It's the type that says "we're so accepting" when really they only are of certain stuff. Lots of pronoun people and making the mascot "non binary" is needlessly shoving their ideology down people's throat. Not a problem in the U.S. because it fits with the corporate woke ideology but sure as hell gonna be if they want more worldwide community. It's also way to…

good

Re: Lies we tell ourselves to keep using Golang

#319
post #94

Earlier quoted context omitted.

But he doesn't dive deeper! If anything, he's more shallow. This just doesn't read like an honest appraisal of Go's pros and cons to me, he already has his mind set from the beginning (ok, we knew that two years ago already) and is just heaping on invectives: "one really good bit does not a platform make", "Evidently, the Go team didn't want to design a language", "Go is not adequate for production services unless yo…

> What makes me angry about all this Go-bashing It's just a language! Take it easy. The guy is not "heaping on invectives" - he's not criticizing you or someone you care about. He's pointing out some flaws in a language in a sarcastic way.

I would consider "Evidently, the Go team didn't want to design a language" to be at least borderline invective. From dictionary.com, definition 3: "an insulting or abusive word or expression". Yeah, that's pretty clearly insulting.

Re: Lies we tell ourselves to keep using Golang

#320
post #65
post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."

As developers get more and more senior they tend to ignore more and more problems because they realize the majority of them actually don't matter very much to doing useful work.
Post reply on HN