SeirdyOct 16, 2023
Go is spectacular in every way except the actual language itself
Show threadHazel CoraOct 16, 2023
@Seirdy LMAO what is this supposed to mean
Show threadSeirdyOct 16, 2023

@h top of the line:

  • fuzzers
  • linters
  • formatter
  • language server
  • native cryptographic libraries (not just bindings)
  • build speed
  • portability (far better than most LLVM langs)
  • property testing (literally in the stdlib)
  • sanitizers
  • HTTP protocols (conformant native libs for HTTP/2, HTTP/3)
  • large ecosystem
  • docs
  • stability (the Go Compatibility Promise)
  • a spec
  • other usable (mediocre but still usable!) implementations
  • dead-simple OS/arch cross-compilation
  • green threads

Go has everything except a good language.

Show threadHazel CoraOct 16, 2023
@Seirdy i see very few flaws with the language besides things like "i want ternary operators" and "i want try-catch" (slowly realising its for the best that we dont have try-catch though so i wouldnt actually want this to change) so i just cannot understand this take i think
Show threadLisPiOct 16, 2023

@h @Seirdy That's mostly because try/catch is a very weak paradigm for error handling and profoundly limiting.

The #CommonLisp #ConditionSystem is rather the way to look.

Show threadSeirdyOct 16, 2023
@lispi314 @h just use formal verification to prove that the function always returns its return type correctly. /hj
Show threadLisPiOct 16, 2023

@Seirdy @h That works right up until you have to rely on hardware systems that can fail.

So even in Ada SPARK (which has such formal verification apparatus) you still need to handle such failures.

But more importantly, the Condition System isn't solely limited to signaling error conditions, it can be used to handle a variety of other conditions. You can also vary how you decide to respond to them (if at all), and you can even make that dynamically configurable.

Show threadLisPi
@Seirdy @h Of course "hardware failure" doesn't necessarily mean permanent or catastrophic failure, transient faults are a thing too.
Oct 16, 2023 at 4:45amWeb
Show threadSeirdyOct 16, 2023
@lispi314 @h /me cries in non-ecc ram
Show threadLisPiOct 16, 2023

@Seirdy @h I will never forgive Intel. <insert anime meme>

Seriously though, it should be the least of things for the CPU and memory to be both able to detect and *correct* errors, and signal faults to the operator.

Mainframes do it. They also support hotswap of the components involved.

Workstations fail on the hotswap and CPU fault tolerance parts.

PCs fail on everything. Thanks Intel⸮

At least even on PCs it's possible to put redundant and hot-swappable storage.

Show threadSeirdyOct 16, 2023
@lispi314 @h cries in the inevitable drive failure during a RAID restore operation
Show threadLisPiOct 16, 2023

@Seirdy @h That's only a problem if you foolishly use parity-based redundancy.

Mirrored pairs or larger tuples have no such issue.

Error recovery or restoring is a straight copy off other correct copies on other media.

A slight bit less storage-efficient, perhaps, but oh so much more reliable.

Show threadLisPiOct 16, 2023

@Seirdy @h Something file/record-aware does best, as you can only correct the one record that has gotten corrupted (like ZFS & btrfs do).

Then you can also do things like storing said records on blocks of a given size so you can more easily support diverse hardware while respecting policy constraints the user configured (btrfs uses 1GB blocks, which means you don't have to use identically-sized or larger drives in tuples, it dynamically allocates according to the profile constraints).