Lies we tell ourselves to keep using Golang (2022) • Hacker News Board

Re: Lies we tell ourselves to keep using Golang (2022)

#371

Post by devjab » Tue, Nov 26, 2024, 5:55 PM UTC

zozbot234 wrote: post #317

devjab wrote: post #285

Earlier quoted context omitted.

I think it’s because Go is an alternative to Java and C# more so than an alternative to Rust. It is for me at least. As I said, Rust isn’t seeing any form of real world adoption in my region while Go is. Go isn’t replacing C/C++ or even Python though, it’s replacing Typescript, C# and Java. Now, there are a lot of good reasons as to why Go shouldn’t be doing that, a lot of them listed in the article, but that’s still…

> Now, there are a lot of good reasons as to why Go shouldn’t be doing that I disagree. Typescript, C# and Java are terrible languages (as are Python/Ruby/etc. in other ways). Golang is bad by OP's standards but there's nothing wrong with it gaining ground on those languages. Besides it's also easier to convert a codebase to Rust from Golang than Typescript or C#/Java.

It was meant more as an observation than my opinion. I would pick Go over Java/C# any day of the week, but it’s not like talented JVM engineers won’t run in circles around you as far as performance goes.

I’d frankly pick Python for most things though. It’s a terrible language, everyone knows it’s terrible but it gets things done and everyone can work with it. I view performance issues a little different than most people though. To me hitting the wall where you can no longer “make do” with C/Zig replacements of Python bottlenecks means you’ve made it. The vast majority of software projects will never be successful enough to get there.

Re: Lies we tell ourselves to keep using Golang (2022)

#372

Post by Terretta » Tue, Nov 26, 2024, 6:15 PM UTC

zapnuk wrote: post #196

tessela wrote: post #181

Earlier quoted context omitted.

> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Swift.

If they'd drastically improved their tooling then yes. But sadly it's not that easy to create a statically liked binary in swift. The last time i did it it also included the whole runtime, and the resulting "hello world" binary was 50mb large. Annoying at least. For years I wished they got their stuff together, but at this point I'd be very suprised. They probably have too much technical dept already due to the suppo…

> For years I wished they got their stuff together, but at this point I'd be very suprised.

This is a thing that's having work done, but still too large depending:

https://www.swift.org/documentation/articles/static-linux-ge...

See here for sizes of various languages as of August 2024 when I'm commenting, but this is Swift 5.10 for Windows:

https://github.com/MichalStrehovsky/sizegame

Build actions here:

https://github.com/MichalStrehovsky/sizegame/blob/master/.gi...

What you want, instead, is Swift 6 for Linux, while e.g. Alpine, as of summer, still too large:

https://mko.re/blog/swift-alpine-packaging/#:~:text=Package%....

In this thread on Swift for AWS Lambda, a dev gets a Linux static build to 5.9 megabytes:

"Then, I stripped it and it's now 5.9Mb. That's an impressive 86% reduction. Given that musl libc.a is 2.4Mb and libc++.a is 10Mb, I find that 5.9Mb for an executable that contains both libc and the Swift runtime is not that bad :-)"

https://forums.swift.org/t/aws-lambda-functions-and-the-linu...

> They probably have too much technical dept already due to the support of XXX edge cases Apple need for iOS/MacOS development.

Re: Lies we tell ourselves to keep using Golang (2022)

#373

Post by Yoric » Tue, Nov 26, 2024, 6:15 PM UTC

cowl wrote: post #354

Yoric wrote: post #292

Earlier quoted context omitted.

Do you have examples for the latter?

the most basic example was the declined proposal https://github.com/golang/proposal/blob/master/design/32437-... Some people didn't like the "try" keyword it reminded them too much of exceptions, some people didn't like that they couldnt see a return inline (which was the purpose of the proposal in the first place). it's not that there are no solutions. the main problem is the go team's insistence to have "one true w…

This doesn't look meaningfully different from current error handling in Go.

It's basically the same syntactic sugar as `try!` in Rust, isn't it?

Re: Lies we tell ourselves to keep using Golang (2022)

#374

Post by optician_owl » Tue, Nov 26, 2024, 6:35 PM UTC

bobertlo wrote: post #359

optician_owl wrote: post #167

The worst thing - default values as a solution for absent values. What can go wrong with implicit value assignments?!

Would you rather have undefined initial values?

I would. Not because it's something pleasant.

There is a huge difference between no value and default value. I had plenty cases where I needed to distinguish them because absent value is a violation of a contract. Defaults are not a solution.

And more. Defaults bring their own problem. Chosen values are neutral only for some operations. The most simplest case - int default value is 0, but it kinda "works" only for sums. With nulls you'll get an error in production. With defaults discovery of the error is postponed even more. It's literally the same as making up values ignoring clients will (and this decision even not ours but designers of the lang).

Defaults are implicit. It's simplifies mistakes due to human factor.

Re: Lies we tell ourselves to keep using Golang (2022)

#375

Post by thot_experiment » Tue, Nov 26, 2024, 6:42 PM UTC

zwnow wrote: post #145

instig007 wrote: post #69

Earlier quoted context omitted.

> The industry is still built upon people who can build fast. Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality c…

Commercial software is what pays my rent though. Why would I bother about open-source software other than personal interest?

You should bother because of the externalities that aren't captured by capitalism. Also OP never called anyone a poor programmer, he said the language was made FOR poor programmers. Rob Pike, one of the people who came up with golang (and unix) is quoted as saying:

> They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language

Dude brought receipts, it doesn't get any clearer than the language creator stating his intent. Just because something is designed for idiots doesn't make you an idiot for using it.

In any case, you should probably read https://paulgraham.com/identity.html

Re: Lies we tell ourselves to keep using Golang (2022)

#376

Post by prmph » Tue, Nov 26, 2024, 6:43 PM UTC

sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

So here is my take on this, once again:

Start with JavaScript. The basic syntax is delightfully direct, it has massive adoption already, the ecosystem is large, the runtimes are getting better all the time, compilation is here with WASM,

Now remove the weird parts (e.g., too much flexibility to redefine things, too much use of the global scope, too much weirdness with numbers, etc.), and add:

- Types (including sum/product types, Result, Maybe, decimals, etc.)

- More functional features (everything-is-an-expression, pattern matching, currying, etc)

- A comprehensive standard library.

Already this starts to yield a language that has the best chance to be what a lot want.

The other major advance in developer tools that I'm wanting to see is revamping HTML to have proper sophisticated controls built-in, controls that can be easily styled with inline CSS. This will reduce the amount of JS needed on the client.

These two things will yield a massive advance in programming productivity, at least as far as web-related development is concerned, IMO

Re: Lies we tell ourselves to keep using Golang (2022)

#377

Post by 9rx » Tue, Nov 26, 2024, 6:59 PM UTC

pdimitar wrote: post #340

packetlost wrote: post #338

Earlier quoted context omitted.

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches.

Technically, Go v2 signified the transition away from Google control to the project being directed by the community. That happened several years ago. Go v2 is already here and has been for a long time. The stdlib is also at v2 now (e.g. math/rand/v2).

You must mean the language? They said that a language v2 (go2) is probably unnecessary – that any future additions could be added without breaking the existing language. I don't expect simple tagged unions would need to break anything. A v2 (or even v3, perhaps) stdlib would be necessary to take advantage, like the parent suggests, but that has never been ruled out and is already the status quo.

Re: Lies we tell ourselves to keep using Golang (2022)

#378

Post by amai » Tue, Nov 26, 2024, 7:05 PM UTC

Sorry to spoil the party, but the future is mobile and none of your favorite programming language ( Rust, go, Python, Nim, Lisp, Zig, Smalltalk ...) is ready for this. The future will be Kotlin, Swift and Javascript and I already hate it.

Re: Lies we tell ourselves to keep using Golang (2022)

#379

Post by wbl » Tue, Nov 26, 2024, 7:14 PM UTC

the_gipsy wrote: post #368

9rx wrote: post #339

Earlier quoted context omitted.

> The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. To be fair, that expression came from a blogger who often wrote about Go. It is not a tenet held by the Go project. In fact, Rob Pike has made clear that he considers it to be misguided advice. It is only violated in the same way returning Result in Rust violates the assertion I made up for this comment: Do not re…

https://go.dev/wiki/CodeReviewComments#interfaces

How on earth is that violated by error?

error is implemented by types all over the standard library and beyond and consumed by functions that wrap errors in the errors package. It's exactly an example of what you claim is violated.

Even more obviously your link isn't talking about functions but packages. There are some violations out there but generally when included packages define interfaces they are ones that get consumed like in io or it's dissolution.

Re: Lies we tell ourselves to keep using Golang (2022)

#380

Post by majormajor » Tue, Nov 26, 2024, 7:15 PM UTC

cowl wrote: post #179

devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

this part of error handling is pure religion. it goes even against one of the most basic go tenents. that code should be easy to read not write. Try reading and understanding the logic of a particular method where 75% of the lines are error noise and only 25% are the ones you need to understand what the method does. yes it's noise because whenever read a codebase for the first time you are never interested on the the…

> yes it's noise because whenever read a codebase for the first time you are never interested on the the error edge case.

maybe this has something to do with how bug-prone it usually is for a new hire to modify a codebase for the first time in most orgs

you could also just do things fail-fast style and panic everywhere if you REALLY wanted to stop inlining error conditions. or ignore error checks until some sort of guard layer that validates things.

IME you usually don't want to do either of those things, and the go approach at least encourages you to think about it closer to the site than checked exceptions (which you can more easily toss up and up and up and auto-add to signatures of callers). unchecked exceptions are arguably less-bad than "just ignore go return errors" - they'll get seen! - but terrible for a reliability/UX perspective.

optional-esque approaches are nice but just a different flavor of the same overhead IMO.