feffe

Everyone will have different gripes based on previous experience.

I once religiously wrote Doxygen (aka javadoc) comments for all my C code. Eventually I realized it was just very verbose red tape that added little value. In C no-one bothers to actually generate or read the generated Doxygen HTML output. It's just waste. Granted in Java this is not the case as javadoc is more permeated into the culture. Anywho, personally I'm glad the Go designers went with something more lightweight that focuses on the essentials. All just personal preferences...

WRT logging, can it be done right? I think in most circumstances the right answer is to not log anything at all. Logging poisons the code you are writing, forcing the user of your code to relate to the same logging APIs as you choose. Maybe they will have 10s, 100s of different logging APIs to relate to in the final program. If you are writing reusable code for others I think the answer is to avoid logging to the largest extent possible. Otherwise do something really simple that the user of your code can control if they want or not.

I've written a lot of C code and to me Go is like a high level C with some sharp corners removed and a GC. Maybe I don't see the limitations in Go as a problem because of this. Have done quite a bit of C++ as well. I prefer simpler languages that I can keep in my head and like C and Go for that reason.

Do I prefer it to rust? I've not bothered to learn rust yet. I think I would like it better than C++ but it's a bit large for my taste. I like to see the language level as an abstraction level that I want to be able to keep entirely in my head. I fear that rust (just as C++) may have too many features for that.

What are the issues with TLV? I guess one could be that it's difficult to modify messages. On the other hand skipping parts of a message is efficient.

There's also the type parameters proposal document which covers a lot of ground.

https://go.googlesource.com/proposal/+/refs/heads/master/des...

Ahh the Falcon, it was cool. It may be able to run quake2 but only at very low resolution and choppy frame rate. Still a feat of engineering.

I owned the machine and the following cheap design decisions bothered me a lot.

The memory bus was 16 bits although the Atari TT had a 32 bit memory bus. The machine was severely limited by the low memory bandwidth to main memory. It was only possible to clear about 6 MB/s to main memory, not copy. As a reference 320*240, 8 bpp, 60 Hz is 4.6 MB/s.

The main CPU should have been clocked at 32 MHz and not 16 MHz, The TT used a 32 MHz CPU released years earlier.

There should have been a chunky 8 bpp graphics mode. It would have been real useful to do things like quake. Only the 16 bpp mode is chunky and very bandwidth intensive because of the above mentioned points.

The DSP was really cool though, and useful. The link between memory (or host CPU) and the DSP was pretty slow though. I don't remember if you could DMA directly from the DSP to main memory or you had to go via the CPU.

I think both Atari and Commodore killed their businesses by not going any decent HW development between 85 and 89. Then it was too late.

I wrote my own a while back.

https://github.com/johan-bolmsjo/blog_of_markdown

It's built using make, small bash scripts and two Go support programs. I think there are tons of similar generators out there as writing one is pretty easy. Probably more sensible to look into using something like Hugo. For me it was easier to write the minimal generator than figuring out how to configure Hugo as I like it.

I think Jonathan may have a bit of OCD himself and don't want to release something imperfect. This is meant as a tongue in cheek comment. Don't get offended anyone!

My experience with laser printer paper is that it does not work well with most fountain pen inks. Although I acknowledge that there may be some that do, there are lots of paper manufacturers after all.. I've found plenty of cheap spiral bound notepad paper that does work well though. You just have to try it out and see what works. Paper can't be to absorbent or the ink will spread out.

Add blockers would not make the result better though. For me google is useless nowadays. If a search engine surfice that truly find what I'm looking for I'll pay $10/month for it but I think the price may be too much for those that don't care as much about the search result quality.

If it really starts to take off I think you should consider lowering the price. Initially I understand a higher price is required to be able to cover expenses. A price that is low enough to not matter would lure more customers into the fold (if the products deliver on its promise).

I've just finished porting my gods module (Go Data Structures) to make use of generics.

https://github.com/johan-bolmsjo/gods/tree/v2

It's not much, only a simple list and an AVL tree that I've carried with me for many years. Binary search trees are useful to solve some problems because they are ordered.

I was impressed with how polished the tools where. The go-lsp plugin just worked with the new generic types. I solved all compiler errors in the editor without actually compiling anything. Did not expect that level of polish. The modules introduction broke the editor integration for many release cycles. This seems much smoother.

I married a foreigner and for a few years when she was learning my native tongue, my own vocabulary and ease of expressing my self deteriorated noticeably. Even when speaking to others. This was quite a few years ago. I'm back on track but it was a frustrating experience.

Similarly I find myself speaking better English when "guided" by an American or English person. It's weird... If someone else speaks broken English, I will too.

Maybe Andrew is referring to this? I'm just guessing but that is the only thing I can think of which could be considered broken. Go mostly just treat strings as bag of bytes and you have to use one of the unicode packages to actually do any significant work with them.

https://play.golang.com/p/Dla3sXciYXC

I also think string handling in Go is pretty sane. But range vs indexing on strings is something you need to be aware of.

They are called type assertions, I believe they are type safe, albeit at runtime. It will panic if the assertion is incorrect.

I agree with your list but really need 4 myself to be a happy camper. Often it's neglected once 2 is in place as most don't seem to find any value by it, or don't care to maintain it. I find that having the possibility to run the real thing (in some capacity) in a cozy development environment with debugger is very useful to quickly learn how parts in the system interact with each other. I have a hard time doing that with unit tests, perhaps because they are so boring.

OSS or Free software is not broken. To claim that it's broken, there must be some outspoken intent that has been violated. For example that said software should be used by big mega corps for free and that there should never be any bugs in it. That is not the case, thus it's not broken. Most free software is made to scratch an itch. Some projects grow big and serious. Some is abandoned when the original author grows tired of it. A responsible organization would be expected to take the support responsibility for any free software that it uses as none is included in the price ($0). Or pay another company to offer that support if the task is too big. If you don't agree to these terms, refrain from using such software in your product.

I recently had an interesting experience with bad non-ECC RAM. The only effect I saw for many months was a frequently crashing web browser. I was very annoyed and downgraded to the firefox LTS release to try to solve the issue. The problem went away for a while, then came back. Seemingly erratic the problem could resurface only to disappear a while later.

Eventually I got a corruption in a large Git repository with photos. First I suspected a disk error but reruns of "git fsck" reported different bad objects, run to run. How odd, so I ran memtest86 and it reported a bad 32 MB memory region at offset 4 GB. Never saw any kernel issues or other instability. Booting up the computer does not use up 4 GB of memory (Linux) but starting a bloated web browser does.

The computer is stable after mapping away the bad memory region by using GRUB_BADRAM. That was an new takeaway for me, a machine with ECC memory can do this bad blocks mapping automatically. It's not just beneficial in correcting single bit errors.

I would love to have ECC memory in my machine. I used it for my previous build in 2012 but I think the situation has gotten worse since then. Bigger price difference and ECC memory is not even available at the same clocks as non-ECC memory.

Interestingly the MIPS CPU traps on overflow for the add and sub instructions. You have to use the addu or subu instructions to get the usual behavior of overflow.

MIPS is kind of the spiritual ancestor to RISC-V

As a self identifying Unix user, what angers me about file locking on windows is that I can't delete a file that another process has opened. This often leads to the situation that I can't delete a large directory structure because some unknown program has a file open in said directory. I don't care, just let me delete the directory please! Maybe it's not a "Unix" design, but something done by Linux. The concept that a program can continue using an already opened file while to others it's deleted is quite elegant.

To be fair, early Java definitely had lots of issues with GC and "hanging" programs due to GC activity. It's a failure of the article to bring it up if modern Java implementation are better on that point. As an example of bad reputation, I think the latest Eclipse IDE on the latest Java SDK is still sucky and because of my ignorance I blame it on Java.

I was disappointed with the first Go gRPC implementation, it allocated like crazy and was really slow because of it. It's been rewritten since then but I don't know how much better it is now. To get good performance out of Go it is important to think about memory allocations (unfortunately), just as it is in C and C++. Although allocating like crazy in C/C++ will probably mostly result in a general loss of performance, not affect tail latencies in network protocols much.

Ditto, I have a Realforce R2 PFU Limited Edition and it's the best keyboard I've ever used. I don't think it's that loud and I could see myself using it in an office setting.

Before getting the Realforce I got two Filco Majestouch with brown switches. I used one of them in the office for quite some time and in retro respect I feel a bit sorry for my colleagues at the time. I still have and use those keyboards and the Realforce is much quieter.

Thinking about getting another Realforce and retire my Filcos. It's the "end game" keyboard for me.

Sum types would be nice to describe protocols such a grpc as well (given suitable syntactic sugar to switch on them).

I think sum types, possibly in combination with tuples would have been nicer than multiple return values. But I guess everyone has their particular wish list of what a programming language should be :-)

I agree that in theory the same is possible in languages that use exceptions but in my experience laziness often wins out. The exception is caught on the level where it's suitable to terminate the stack unwinding and deal with the error from the applications point of view. At that point it's too late to add user recognizable context to the error that what Go advocates by its design.

My opinion is that a syntax shortcut such as "?" to just bubble up errors without adding context would still be useful. I would welcome it. There are cases where I find that no additional context is needed. I think the Go designers are afraid what it would lead to though (the laziness wins out hypothesis)

It's not the same thing. In Java and Python programs, especially Java programs, developers seems to think it's perfectly reasonable to present the end user with a 100 entries stack trace. This may be of use to the developer to debug issues but it's not a substitute for good error messages that are to be presented to the end user.

I don't think Go errors are perfect either as you just tend to concatenate strings together but the information they include are more user friendly if done right, i.e. not just bubble up the error, but adding context that the user is aware of.

Same experience, I thought I had things figured out but after a few weeks struggling with OCaml I felt like a complete retard :-) But it was an eye opener in some way on how to write programs in a different way. I think OCaml also suffers a bit the same problem as C++ does. You need to learn quite a lot to be able to read others code. There are many advanced concepts with cryptic syntax that is hard to search for on the net.

I don't think the advice applies for C++ either. The last time I worked with a C++ code base I tried to understand some std:: API semantics by reading the code but I failed every single time. I'm not an expert C++ programmer by any means but I think I've passed the novice stage where you try to learn the language. Maybe for C++ constant learning of the base language is needed :-)

For Go and C on the other hand I think it works very well since the core languages are so simple it's viable to read others code successfully without being a language expert. I read the Go stdlib code all the time if something is unclear in the documentation (the docs are good but sometimes there are edge cases that are not clearly documented).

Cool, didn't know about that. To boost Magit a bit, you can stage parts of patch hunks, I use that quite a bit.

Just select any parts of the diff using regular edit text select commands and press "s" for stage.

I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor.

Significant white space is a mistake IMHO :-)

I did find it to be extremely poor but once I started liking individual songs, not whole albums it does better. Still, I'm not sure it uses other listening habits to feed the engine such as:

- Early skipping a song from a generated play list (-1). - Repeat playing the same song from a generated play list (+1)

Reporting from Sweden, almost all our stand alone houses (small houses) are built the same except with better insulation in walls, roof and windows (because of the climate).

I've never considered our houses rickety, although I do think wood now days is worse than 50 years ago, less growth rings in construction lumber.