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

271–280 of 526 posts

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

#271

Post by sshine »

mathw wrote: post #243
Chai-T-Rex wrote: post #180

Earlier quoted context omitted.

If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.

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 .

While that is true, there are clippy::indexing_slicing, clippy::string_slice for that:

  https://github.com/rust-lang/rust-clippy/issues/8184#issuecomment-1003651774

  error: indexing may panic
     --> src/main.rs:100:57
      |
  100 |             rtmp::header::BasicHeader::ID0 => u32::from(buffer[1]) + 64,
      |                                                         ^^^^^^^^^
      |
      = help: consider using `.get(n)` or `.get_mut(n)` instead
      = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#indexing_slicing

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

#272

Post by LinXitoW »

jonathanstrange wrote: post #96
richbell wrote: post #75

Earlier quoted context omitted.

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.

I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy.

Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.

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

#273

Post by sshine »

OtomotO wrote: post #118
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

But with Exceptions you can easily implement multiple return types in e.g. Java ;) I shocked my Professor at university with that statement. After I started laughing, he asked me more questions... still went away with a straight A ;D

When I took the compiler course at university, the professor would have a new coursework theme every year, and the year I took the course, the coursework compiler was exception-oriented. So exceptions were the only control flow mechanism besides function calls. If/else, while, return were all variations of throw.

To me this proved that there's nothing inherently wrong about exceptions.

It's how you structure your code and the implied assumptions you share with your colleagues.

Some people are way too optimistic about their program will actually do.

Happy path programming.

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

#274

Post by SirGiggles »

sterlind wrote: post #250
radicalbyte wrote: post #52

Earlier quoted context omitted.

Go is an iteration of C, not of Java. It's a really bad choice for situations where Java is a good choice as not only is the language limited, the ecosystem around it is also very limited when compared to say Java. I'm maintaining Go, C# and TypeScript as my main languages as that gives me excellent coverage. I'll add Rust to the mix when I have 6 months where I can accept the productivity drop or have a project wher…

How is Go an iteration of C? You can't use Go to write a kernel, or program a microcontroller, or for high-frequency trading or a web browser or a tensor library or a language run-time. It's either a bad idea or simply impossible, depending. Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.

To be pedantic for a moment...

> You can't use Go to write a kernel ...

Not a production kernel, but MIT did use Go to "study the performance trade-offs of using a high-level language with garbage collection to implement a kernel" [1]

There is also gVisor [2] which implements, as best as I can describe, a kernel in user space. It's intent is to intercept syscalls made in containers and to redirect its execution in a sandbox.

> ... program a microcontroller ...

I'm not sure if one would classify this as a microcontroller, but USB Armory did write a, iirc, Go compliant runtime for bare metal ARM and RISC-V [3].

There is also TinyGo [4] with the following listed microcontroller support [5]

[1] https://github.com/mit-pdos/biscuit

[2] https://gvisor.dev/

[3] https://github.com/usbarmory/tamago

[4] https://tinygo.org/

[5] https://tinygo.org/docs/reference/microcontrollers/

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

#276

Post by SirGiggles »

CharlieDigital wrote: post #267
poilcn wrote: post #142

Earlier quoted context omitted.

>and the fact it's so tied to windows Dotnet Core is not tied to windows except for certain frameworks like wpf (and there are alternatives for it that work everywhere), credential store. And it's actually really good to use these days.

Yup, common misconception for folks that haven't used it in a decade. Our team uses C#. We dev on Apple silicon Macs. Some use Rider, others just use VS Code. We build on Linux via GitHub Actions. Ship to prod running AWS t4g Arm64 instances. C# to me is like TypeScript++. The language, syntax, and core constructs are close enough that anyone with a good handle on JS and TS can pick it up easily and be productive.

Sorry for the segue, but how your team's experience with C# on VSCode? Any recommendations for plugins? I've heard of a lot of people recommend Rider but not much, aside from neonsunset, talk about VSCode.

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

#277

Post by cnity »

euroderf wrote: post #220
cnity wrote: post #169

Earlier quoted context omitted.

What do you mean by this? WebAssembly is a low level bytecode which only defines low level types. WebAssembly doesn't "have" types any more than x86 "has" types right? Or have I missed something?

Ah, sorry. Shoulda said: WebAssembly component model.

Oh, I see. Thanks!

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

#278

Post by cmrdporcupine »

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…

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

So OCaml then (ocamlopt to do native code compilation)

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

#279

Post by the_gipsy »

the_gipsy wrote: post #29
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…

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

I forgot:

The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface.

IMO it's okay to make behaviour-exceptions specifically for error handling. Rust for example doesn't really have builtin behaviour exceptions specifically for errors, they're generic to sumtypes and just happen to work well for errors. But then in practice you must resort to thiserror or anyhow helper crates to deal with errors in anything but tiny programs.

If you do make behaviour exceptions for error handling, be honest and upfront about it. Don't say "errors are just values so just use them like regular vars" in docs, if then there are several huge exceptions (tuple-returns and breaking a core tenet). If you make exceptions then you might as well do them right, instead of half-assing them. I believe zig does it right, but I haven't gotten around to try it.

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

#280

Post by devjab »

the_gipsy wrote: post #29
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…

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

I prefer the structure of Rust errors as it’s fully typed, I don’t like that you can chain them though. It’s a cool feature but it leaves you with some of the same issues exception handling does when the freedom is used “wrong”.
Post reply on HN