Lighterra

It's been said many times that Go feels like a language written by people who stopped paying attention to programming language research after the 1990s, as well as that it was written by people who look at C and think the only things that are less than perfect about it in the modern world are memory-safety and lack of a first-class concurrency story.

Some examples (not an exhaustive list):

1. Fibers/stackful coroutines (See "Fibers under the magnifying glass" by Gor Nishanov for why they were hugely popular in the 90s and then got abandoned by all the major OSes and programming languages → http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf)

2. Garbage collection (The 90s were the height of GC hype, to the point that the JVM still struggles with "Don't worry. GC research will make it fast." design decisions.)

3. Error handling that feels like "Well, we know that exceptions were a mistake, so the only other option is C-style return values... but, hey, we can at least follow 90s Python's lead in supporting returning tuples." (Granted, exceptions DO bake in a fundamental assumption that all the world can be treated as single-threaded execution amenable to transactional rollback. → https://www.lighterra.com/papers/exceptionsharmful/)

4. No generics until they were pushed into it by things like people writing preprocessors that use the Canadian Aboriginal Syllabics characters that look like angle brackets.…

Previous discussions:

2018, 87 comments: https://news.ycombinator.com/item?id=18230383

2016, 12 comments: https://news.ycombinator.com/item?id=11116211

2014, 37 comments: https://news.ycombinator.com/item?id=7174513

2011, 30 comments: https://news.ycombinator.com/item?id=2428403

This link has also appeared in 9 comments on HN, featuring threads on "Computer Architecture for Network Engineers", "X86 versus other architectures" by Linus Torvalds, and "I don't know how CPUs work so I simulated one in code", also recommending a udacity course on how modern processors work (https://www.udacity.com/course/high-performance-computer-architecture--ud007): https://ampie.app/url-context?url=lighterra.com/papers/modernmicroprocessors

Jason also has a couple of other interesting articles on his website, like intro to instruction scheduling and software pipelining (http://www.lighterra.com/papers/basicinstructionscheduling/) and the one I liked a lot and agree with called "exception handling considered harmful" (http://www.lighterra.com/papers/exceptionsharmful/).

> maybe that's just how fonts are supposed to look and Mac OS has warped my perception

Well, Mac OS users lived with this serious rendering bug for more than a decade: https://www.lighterra.com/articles/macosxtextaabug/

I remember that look well, and even thought that was how text was supposed to look. I stopped using Mac OS before that bug was fixed, so I don't know what else may be going on over there. However, there was a period where a lot of websites looked terrible on non-Macs because Mac-using designers would set really light font weights, which apparently looked fine with Apple's font rendering. Were they right, while everyone else was wrong? I don't know.

Nowadays I run pretty-much-default Ubuntu linux with a 4k display, and I think fonts throughout my system and the web look great, both compared to my iPhone (which also looks great) and compared to my standard definition Windows setup at work (which looks anywhere from 'bad' to 'fine', depending on the program, font, scaling, etc).

So, if I understand it correctly, the text argues in favor of the GPU approach of pipelining independant vector operations instead of the current SIMD approach.

I see how this could be beneficial, specially when writing codes, as it's way closer to just a normal loop.

Then again, why not combine both ideas and pipeline chunks of SIMD type? Say we have 4 execution stages and 32bit SIMD types (unrealistic, I know) and want to process 8-bit numbers. Wouldn't we be able to process 16 of them at the same time? Actually, isn't that kind of what GPUs already do?

I'm sure smarter people than I have reasoned about this, maybe someone can link a good article. I only know of this one [1] and one about GPGPU that I just can't find any more (but which was also very interesting)

[1] http://www.lighterra.com/papers/modernmicroprocessors/

Please. This is not relevant almost 12 years later!

Moore's law is saturating. Benchmarks numbers are more and more a function of core-count not GHz-count. It's time to embrace the RISC-y tiny speed-demon cores (so you can have them by the dozens) over complex brainiac ones (too much space). It's been almost 9 years Intel introduced dual cores and the mainstream is still quad-core (with 6 and 8 on the fringes) while GHz is less that what P4 had more than 10 years ago! What is going on? If Moore's law still holds, in 9 years since 2005 Intel should be at 24/32/48 core ballpark, something that is clearly not the case.

In that vein I would also state that linux needs a major overhaul, i.e., to shift itself from a single core kernel to one that leverages n-cores.

good read: http://www.lighterra.com/papers/modernmicroprocessors/

> That's why exceptions work so well in most languages

But there are many people including some well-known and highly-respect people who believe that exception handling in fact does not actually work well:

- https://www.joelonsoftware.com/2003/10/13/13/
- https://blogs.msdn.microsoft.com/larryosterman/2004/09/10/structured-exception-handling-considered-harmful/
- https://www.atlassian.com/blog/archives/exceptions_are_bad
- https://stackoverflow.com/a/1736320/102699
- http://xahlee.info/comp/why_i_hate_exceptions.html
- http://www.lighterra.com/papers/exceptionsharmful/

#justsaying