Hacker Newsnew | past | comments | ask | show | jobs | submit | leoc's commentslogin

The Apache Foundation used to step in in this kind of situation, didn't it? Thugh maybe pgbackrest isn't quite big and official enough to be the kind of software which Apache takes on, and one certainly hears (increasing?) grumbles about Apache's stewardship.

The Apache Foundation used to help with this sort of governance problem didn't it? Thugh maybe pgbackrest isn't quite big and official enough to be the kind of software which Apache takes on, and one certainly hears (increasing?) grumbles about Apache's stewardship.

What should people read to learn about structured concurrency?

I think the clearest sales pitch comes from this post from the author of Trio, which is an implementation of structured concurrency for Python: https://vorpus.org/blog/notes-on-structured-concurrency-or-g... .

Perhaps java's related JEPs could be a good starting point?

https://openjdk.org/jeps/505

There are also related discussions on other platforms that are worthy to read.


(‘Minimum’ is the singular of ‘minima’.)

Mind you, that suggests that the sentence is at least half-true even if "much more complex" is a big overstatement, since Rust, "modern" C++ and the later evolutions of C# are all relatively recent. (What would have compared to Ada in complexity back in the day? Common Lisp, Algol 68?)

As a matter of general interest, what features or elements of Ada make it particularly hard to compile, or compile well? (And are there parts which look like they might be difficult to manage but aren't?)


You're right in your first part. Ada 83 is less complex than modern C++ or Rust. However Ada kept evolving, and a lot of complexity was added in later revisions, such as Ada 95, which added a kind of bastardized and very complex Java style object model layer.

Ada features that are hard to compile are very common in the language. It is generally a language that is hard to compile to efficient code, because rules were conceived in an abstract notion of what safety is. But in general Ada is an extremely over specified language, which leaves very little space to interpretation. You can check the Ada reference manual if you want, which is a use 1000 pages book (http://www.ada-auth.org/arm.html)

* Array types are very powerful and very complicated * Tasking & threading are specified in the language, which seems good on paper, but the abstractions are not very efficient and of tremendous complexity to implement. * Ada's generic model is very hard to compile efficiently. It was designed in a way that tried to make it possible to compile down both to a "shared implementation" approach, as well as down to a monomorphized approach. Mistakes were done down the line wrt the specification of generics which made compiling them to shared generics almost impossible, which is why some compiler vendors didn't support some features of the language at all. * Ada scoping & module system is of immense complexity * The type system is very vast. Ada's name & type resolution algorithm is extremely complex to implement. functions can be overloaded on both parameters & return types, and there is a enclosing context that determines which overloads will be used in the end. On top of that you have preferences rules for some functions & types, subtyping, derived types, etc ...

This is just what comes to mind on a late Friday evening :) I would say that the language is so complex that writing a new compiler is one of those herculean efforts that reach similar heights as writing a new C++ compiler. That's just a fe


And despite all that complexity, you make it work very well (I've used GNAT since about 2002).

> First, what he calls "the desktop era" wasn't so much a desktop era as a Windows era - Windows ran the vast majority of desktops (and furthermore, there were plenty of inconsistencies between Windows and Mac).

That's overemphasising the differences considerably: on the whole Windows really did copy the Macintosh UI with great attention to detail and considerable faithfulness, the fact that MS had its own PARC people notwithstanding. MS was among other things an early, successful and enthusiastic Macintosh ISV, and it was led by people who were appropriately impressed by the Mac:

> This Mac influence would show up even when Gates expressed dissatisfaction at Windows’ early development. The Microsoft CEO would complain: “That’s not what a Mac does. I want Mac on the PC, I want a Mac on the PC”.

https://books.openbookpublishers.com/10.11647/obp.0184/ch6.x... It probably wouldn't be exaggerating all that wildly to say that '80s-'90s Microsoft was at the core of its mentality a Mac ISV, a good and quite orthodox Mac ISV, with a DOS cash-cow and big ambitions. (It's probably also not a coincidence that pre-8 Windows diverges more freely from the Mac model on the desktop and filesystem UI side than in regards to the application user interface.) And where Windows did diverge from the Mac those differences often ended up being integrated into the Macintosh side of the "desktop era": viz. the right-click context menu and (to a lesser extent) the old, 1990s Office toolbar. And MS wasn't the only important application-software house which came to Windows development with a Mac sensibility (or a Mac OS codebase).


Tired: particle accelerator which crosses the border between France and Switzerland.

Wired: particle accelerator which crosses the border between Quebec and Ontario.


Wireless: Quartks crossing between France and Ontario


https://www.euronews.com/2026/03/30/what-are-ukraines-new-gu...

> Zelenskyy also said that Ukraine is willing to share its expertise in unblocking maritime trade routes with the naval drones.

> “We shared our experience with the Black Sea corridor and how it operates. They understand that our Armed Forces have been highly effective in unblocking the Black Sea corridor. We are sharing these details.”


To be fair, it was bright Chinese minds at ByteDance which worked on getting US teenagers addicted to TikTok videos.


Meta, Google did their parts too


A recent blog post from Christoper Drum on running Lotus 1-2-3 on MS-DOS in a 286 emulator https://stonetools.ghost.io/lotus123-dos/ .


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: