Hacker News Reader

Comment by sleepydog | Hacker News Reader

Can you name a few? Genuine question. I've only really written a lot of tests in Python and Go, and I really dislike the python tests I've had to write. I don't think it's so much the language itself, but that python is so flexible with the mocking you can do that it enables code that is really tedious to test. With Go you have much more limited ability to mock things, so there are added constraints for code to be testable.

Similarly, with documentation, I really like that the godoc toolchain has resisted all the markup and annotation syntaxes that you see in Java. And I like that Go's convention of using a public URL as the module import path helps enable sites like godoc.org.

I find the language itself slightly more than mediocre. But I really like the toolchain and the restraint of the maintainers.

View on HN

Testing wise, elixir is fantastic. I have a relatively large codebase where I run what are effectively full on simulations of the system in sharded-by-test partitions of state to verify correctness and robustness of the code. There are about 60 of those that run concurrently with the unit tests and the whole thing closes in 10 seconds.

Docs for elixir are pretty, too: here's a library that I wrote. The doc system is extensible enough that I could patch in docstrings from another language and also hyperlink (the </> buttons link to github) the GitHub code across languages (the `zig structs` section in the sidebar is autogenerated by parsing zig code) https://hexdocs.pm/zigler/Zigler.html

My joke is that you want to write documentation that's pretty and html-responsive enough that you can read it on the can between coding sprints.

> With Go you have much more limited ability to mock things, so there are added constraints for code to be testable.

I agree Go makes things more difficult to mock, but it's also the language I've used where it's easiest to avoid mocks and test the real thing. We have tests for REST and RPC services that... just make a service. There's relatively little boilerplate to make a gRPC or HTTP service with some basic expectations/fake data attached and just run your real client against that real fake server. ("Relatively" meaning, less than the equivalent mocks in Java, for a substantially more realistic test outcome.) And once you have this fake server, it's probably useful in multiple projects, while mock setup tends to be suite- or even case-specific.

Must be a matter of preference but this is exactly what I hate about godoc. I'd love to use markdown or any other structure, really. Just a wall of plain text is sometimes good, but most of the time bad idea for readability. And the idea of starting each godoc comment with function/variable name is terrible. YMMV.

Reply on news.ycombinator.com