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

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

421–430 of 526 posts

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

#421

Post by zaptheimpaler »

amai wrote: post #419
zaptheimpaler wrote: post #392

Earlier quoted context omitted.

The present is already mobile but the backends serving those mobile devices run on servers. There's also no reason mobiles can't run Rust/Go/Python - Android already runs Java.

You are right there is no reason mobiles can't run Rust/Go/Python. But actually they don't, because there is no infrastructure and no tooling to build mobile apps using these languages. And this is the big oversight of the creators of these languages. All these languages we love so much as developers will die. Not because they are missing generics or error handling or coroutines or a static type system or other nifty…

I think you're vastly overstating the case saying these languages will die..

The majority of code we write runs on servers, even if its ultimately in service of a mobile/web client. Even if mobiles didn't support them, that doesn't mean these languages will die. The servers still have to run.

Creating the tools to run them on mobile is a solvable problem. Rust is already supported in the Android platform [1]. It takes more work to write an application in a non-standard language but its doable. Just saying don't worry about every other language dying out because of mobile, that won't happen :P

[1] https://source.android.com/docs/setup/build/rust/building-ru...

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

#422

Post by the_gipsy »

9rx wrote: post #414
the_gipsy wrote: post #346

Earlier quoted context omitted.

Yes exactly, that rather useless feature just makes the whole thing even weirder.

A function that passes tuples, or multiple arguments as they are more commonly referred to as, is not particularly weird, and has pretty much been the norm since the addition of functions to programming languages. But you are right that languages whose functions only accept tuples, but not return tuples, is a strange curiosity. In practice, you end up with developers packing multiple, unrelated items into a single va…

I meant weird/useless in the sense of that it's used virtually nowhere in practice.

There is a nice func Must(value, err) { if err { panic(err) } else { return value } that you can use in tests to get around the inane regular error handling. But that's about it, to my knowledge. Sad that there isn't more to it. If literally everything returns error as last return value, there could well be some syntax sugar there.

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

#423

Post by clausecker »

lionkor wrote: post #313
clausecker wrote: post #126

Earlier quoted context omitted.

I dislike sum-type based error handling. It is annoying syntactically and only really doable with lots of high-level combinators, which in turn hinder debuggability.

Have you tried the approach that Zig has, or the approach that Rust has? They are easy to debug and do not use any crazy stuff, just simple syntax like `try x()` (Zig) or `x()?` (Rust)

Yes and that syntax sucks.

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

#424

Post by the_gipsy »

wbl wrote: post #382
Yoric wrote: post #295

Earlier quoted context omitted.

Interestingly, every time (and I mean _every_ time) that I've tried to use `errors.As` on errors raised by lib code, I found out that the lib just went with "nah, I'm just going to use `errors.New` or `fmt.Errorf`", which makes the error impossible to match. So... I'd say that this is a fumble in the design of Go.

%W exists to solve this

How? Stringly matching? That's not typesafe at all.

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

#425

Post by the_gipsy »

iamcalledrob wrote: post #193
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…

Kotlin is interesting as a middle ground, but I still find it much less productive than Go for most tasks, and unsuitable for tasks where you'd reach for Rust. In practice, Kotlin is extremely complicated, and you end up spending time being clever. There are 1000 ways to do things. Operator overloading. Proxies. Properties. Companion objects. Exceptions AND result types... The build system (assuming you use Gradle) i…

Don't forget that it's made by someone trying to sell you an IDE!

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

#426

Post by Ygg2 »

quotemstr wrote: post #316
pwdisswordfishz wrote: post #238

Earlier quoted context omitted.

In most languages with exceptions: • they may propagate automatically from any point in code, potentially breaking atomicity invariants and preventing forward progress, and have to be caught to be transformed or wrapped – Result requires an explicit operator for propagation and enables restoring invariants and transforming the error before it is propagated. • they are an implicit side-channel treated in the type syst…

> they may propagate automatically from any point in code, potentially breaking atomicity invariants and preventing forward progress A failure can propagate in the same circumstances in a Rust program. First, Rust has panics, which are exceptions. Second, if any function you call returns Result, and if propagate any error to your caller with ?, you have the same from-anywhere control flow you're complaining about abo…

> A failure can propagate in the same circumstances in a Rust program.

What do you consider failure? A result or a panic? Those are worlds apart.

> First, Rust has panics, which are exceptions.

That's not how exceptions work in Java. Exceptions are meant to be caught (albeit rarely). Panics are meant to crash your program. They represent a violation of invariants that uphold the Safety checks.

Only in extreme cases (iirc Linux kernel maintainers) was there a push to be able to either "catch panics" or offer a fallible version of many Rust operations.

The Rust version of Java Exceptions are Results. And they are "checked" by default. That said, Exceptions in Java are huge, require gathering info and slow as molases compared to returning a value (granted you can do some smelly things like raising static exceptions)[1].

[1] https://shipilev.net/blog/2014/exceptional-performance/

> Non-specific criticism. If your complaint is that exceptions don't appear in function signatures, you can design a language in which they do. The mechanism is called "checked exceptions"

And everyone hates checked exceptions. Because rather than having a nice pipe that encapsulates errors like Result, you list every minute Exception possible, which, if we followed the mantra of "every exception is a checked exception" would make, for example, Java signatures into an epic rivaling Iliad.

> Besides, in the real world, junior Rust programmers (and some senior ones who should be ashamed of themselves) just .unwrap().unwrap().unwrap().

If this is a game who can write worse code, you'll never find Java wanting. As a senior Java dev, I've seen things... Drinking helps, but the horrors remain.

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

#427

Post by jll29 »

quotemstr wrote: post #323
mathw wrote: post #243

Earlier quoted context omitted.

I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option .

One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.

One of my dreams is for someone to create a Rust stdlib, full stop.

I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way).

I'm not against alternative implementations, but I'd rather have one "official" implementation that everyone knows that covers most cases and makes for the idiomatic reading of source code.

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

#428

Post by jll29 »

Too wrote: post #402
quotemstr wrote: post #122

Earlier quoted context omitted.

No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere. Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is jus…

I think your conclusion is on the right track. Syntax sugar propagating results is in a way equivalent to exceptions. What you are missing it isn’t just equivalent to ordinary exceptions. It’s more equivalent to checked exceptions. A very powerful concept, that unfortunately got a bad rap, because the most widespread implementation of it (Java) was unreasonably verbose to use in practice. You might claim Rust is stil…

Yes, Java is too verbose, but Kotlins cleaned up much of that boilerplate and runs on the same VM.

I'd be curious to see examples for where you think Rust is still to verbose.

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

#429

Post by 9rx »

the_gipsy wrote: post #422
9rx wrote: post #414

Earlier quoted context omitted.

A function that passes tuples, or multiple arguments as they are more commonly referred to as, is not particularly weird, and has pretty much been the norm since the addition of functions to programming languages. But you are right that languages whose functions only accept tuples, but not return tuples, is a strange curiosity. In practice, you end up with developers packing multiple, unrelated items into a single va…

I meant weird/useless in the sense of that it's used virtually nowhere in practice. There is a nice func Must(value, err) { if err { panic(err) } else { return value } that you can use in tests to get around the inane regular error handling. But that's about it, to my knowledge. Sad that there isn't more to it. If literally everything returns error as last return value, there could well be some syntax sugar there.

I see it used often, even in languages that don't formally support multiple return arguments – with some hacked up array/object single value return to try and emulate what would be better represented as multiple return arguments.

Like I mentioned in another comment, Go does seem especially prone to attracting developers familiar with other languages who insist on trying to continue to program in those other languages even after working in a Go codebase. That may create a condition whereby the developers you regularly come across don't have a good grasp of where to use multiple return arguments effectively, and thus end up avoiding them, even where they would be appropriate.

With respect to the syntax sugar, there have been a number of proposals for exactly that. While the proposed syntax itself has been well received, nobody has come up with a good solution for the rest of the problem. Syntax is only about 10% of what is needed, of course. Rust, for example, has well defined traits and other features to go along with its '?' operator to fill in the remaining 90%. Presumably there is a good solution out there for Go too, but until someone proposes it...

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

#430

Post by abtinf »

vaylian wrote: post #321
bazoom42 wrote: post #294

Earlier quoted context omitted.

Is “goto” just used to mean “bad and evil” here? Because exceptions are not a goto anymore than a return is a goto. The problem with goto is it can jump to any arbitrary place in your code. Exceptions will only go to catch-blocks up the call stack, which presumably you have written on purpose.

> Because exceptions are not a goto anymore than a return is a goto Not true at all * goto goes to a specific hard-coded address * return looks up the previous address from the stack and goes there * exceptions are a complex mess that require branching logic to determine where to resume execution

Very well put.
Post reply on HN