Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Isn't basically all of this shortcomings of Go's standard library, not "Go the language"?

The Go standard seems to be heavily geared towards doing work on the server-side, and "server-side" essentially means "Linux" today.

If I'd need to write "client-side" cross-platform code that also needs to run on Windows, Go wouldn't be my first choice, also not my second or third.

And TBH, most other languages are not that much better (Python might be the only notable exception, and even this requires different code paths for "Windows vs the rest of the world" here and there).

For this type of cross-platform code, it's almost always better to talk directly to the underlying OS APIs and put those under a thin custom wrapper library instead of relying on the language's standard library.

View on HN

A standard library says a lot about the language. Even if someone made a much better path/file handling library for Go, another one of its strengths are the ubiquitous interfaces you can rely on across libraries. Unless the superior library gained a lot of adoption really quickly, it would remain largely irrelevant in the face of the standard that was set years ago by the Go authors.

Look at Go’s HTTP library. It’s much lauded for striking a good balance between performance and ease of use, but it’s not as performant as it could be. For that, fasthttp exists and is quite popular although not nearly as popular as the standard HTTP library.

Your comment gives the impression that this is a failure because the library for niche performance cases hasn’t become the go-to library for the general case. I disagree—it’s ideal that we have a canonical general purpose library and another for high performance cases.

Perhaps you would argue that we should have interfaces that allow for a pluggable performant implementation and an easy-to-use general purpose implementation? This is all well and good, but it’s inherently not possible, because the interface is about ease-of-use and the performance is achieved by trading off on friendliness. You might offer Rust as a counterpoint since many of its standard libraries use an interface that is suitable for the general case and the high performance cases; however, this is a lie: these interfaces (and the core language) are manifold harder to use than their Go equivalents. In other words, Rust’s “general purpose” interfaces trade ease of use for the ability to support high performance implementations. This tradeoff isn’t inherently bad, but it is bad to pretend as though it’s inherently good or that there is no tradeoff at all.

I'm not sure there's a meaningful distinction to be drawn there for the vast majority of usage, to be honest. A language's standard library is generally considered to be part and parcel of the language. Everyone's first sample program is "Hello World" which involves printing text to standard output.

That being said, languages that do offer the ability to work without the standard library give you a lot of flexibility for places where you need it (like embedded systems). Rust has a pretty good story there. I don't think C or C++ really do.

C and C++ don't have good stories for working on embedded systems without a standard library?

Not in the language standard they don't, no. The C99 standard basically says "good luck with that":

"5.1.2.1 Freestanding environment

1. In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the minimal set required by clause 4, are implementation-defined.

2. The effect of program termination in a freestanding environment is implementation-defined."

There are obviously numerous embedded toolchains that provide facilities for writing C/C++ to target embedded systems but they're generally all doing nonstandard things and every one is its own unique fork of GCC.

And that's all perfectly fine.

If I'm running embedded with no OS, I'm in a very specific environment. My code is going to be tied to my specific hardware, including almost certainly the specific CPU chip. (In this situation, it's usual to have a "CPU" chip that includes several peripherals on-chip, to reduce parts cost. Code is not portable to a CPU with different peripherals, even if it's from the same family.) So, if I can't reuse the code anyway, do I care that I can't reuse the one line that is the "main" function definition?

If I'm running embedded with no OS, what should happen if the program terminates by exiting main? Where is there to go?

We're going off into the weeds here but in C this is implementation defined. In Rust you can use `#[no_std]` and the semantics are all well-defined. There's a thriving Rust embedded ecosystem that's doing just fine. Yes, the specifics of interfacing with hardware are platform-specific, but the language and the `core` bits (under `std`) are well-known.

Those things are implementation-defined because anything else wouldn't make sense. If I'm making a C program for a microcontroller, I will need to know how that microcontroller works. It's probably an ARM core, which expects the first few bytes of flash memory to be a table which contains pointers to functions; it's my responsibility to put a pointer to my main function in that table.

This is completely unproblematic, and not really that different from having to make sure your code is compiled to a valid ELF file with the correct sections and section headers.

"Implementation defined" doesn't mean "nonstandard". A C program which overflows a signed integer is ill-formed, because signed overflow is undefined. A C program which relies on external linker scripts to set up the vector table and make the reset vector point to the main function is well-formed, it just necessarily depends on some implementation-defined behavior.

golang's philosophy leaks everywhere, many things are half-baked for no good reason, even when strictly superior solutions are there (e.g. defer works at the function scope, instead of the local scope). Not to mention interfaces are badly designed, leading to issues like this: https://github.com/golang/go/issues/16474

Good point.

Also, client side in Go is usually web interfaces, which work across any platform.

Reply on news.ycombinator.com