[josephg]

I saw a talk about tigerbeetle the other day - which is a small, fast database for handling financial transactions that apparenty runs orders of magnitude faster than Postgres. The database binary has no dependencies and compiles to 500kb. Its authors were joking they could distribute it on floppy disks if they wanted.

It’s written in Zig, not C. But that style of programming is still available to us if we want it. Even in more modern languages.

Honestly I’m really tempted to try to throw together a 90s style fantasy desktop environment and widget library and make some apps for it. There’s something about that era of computing that feels great.

[laserbeam]

Keep in mind, the thing that matters most for tigerbeetle’s speed is they are domain specific. They know exactly upfront how data looks like. They don’t have to be general purpose.

The style of programming does work for general purpose computing, but their requirements enable a significant % of “orders of magnitude faster than postgress”.

[vendiddy]

While your take makes sense, I feel like even general purpose programming frameworks should be orders of magnitude faster for what they are doing.

[laserbeam]

Definitely! It's just your benefits aren't going to be "all" the orders of magnitude speedups, just some of them. And I agree, that's nothing to shy away from.

[josephg]

Yeah; and we have plenty of other general purpose databases which can run laps around postgres and sqlite.

There's plenty of optimisations postgres and friends leave on the table. Like, the postgres client driver could precompile queries and do query planning on behalf of the database. It would introduce some complexity, because the database would need to send information about the schema and layout at startup (and any time it changed). But that would remove a lot of unnecessary, repeated makework from the database process itself. Application servers are much easier to scale than database servers. And application servers could much more easily cache the query plan.

Weirdly, I think part of the problem is economic. I think there's a lot of very smart people around with the skills to dramatically improve the performance of databases like postgresql. Across the whole economy, it would be way cheaper to pay them to optimize the code than needing companies everywhere to rent and run additional database servers. But it might not be worth it for any individual company to fund the work themselves. Without coordination (ie, opensource funding), there's not enough money to hire performance engineers, and the work just doesn't happen.

[gregw2]

Would odbc/jdbc protocols have to change to support client-planned queries?

[red_admiral]

Back when Java had just introduced Swing to supplement/complement AWT, I remember you had a set of components (that you could even style in different ways with themes), a fairly object-oriented approach, and with the open-source MiG layout manager (that still exists today) a powerful way of laying out forms with constraints to adapt to changing screen/window/font sizes. I feel like UI framework progress from Windows 3.1 to Swing+MiG was much greater than anything I've seen since.

[josephg]

I feel that way about the old Interface Builder for macos, back in the Xcode 3.x days. VB6 was pretty good too.

[red_admiral]

Yeah, the interface builders back then are also unsurpassed to this day. Much as I have my issues with VB as a language, the way you could build a GUI with a GUI was amazing. Better still, it worked back on school computers that of course didn't have any "programming" tools, but did come with MS office and the full VB "experience" installed for some reason.

[Khelavaster]

Visual Studio's wpf editor and Avalonia are beyond vb6 interface builders!

[markus_zhang]

Just curious, what is preventing people from creating something similar to VB6 and Delphi in modern days? Different underlying frameworks? But I'm sure VB6 still sort of works on Windows 10 (VBA).

[josephg]

The big problem is that nobody wants yet another platform-specific UI framework. Even Microsoft is using electron (or something like it) to build Microsoft Teams.

If you build a cross-platform UI framework, it'll probably end up looking a bit ugly and custom on every platform (eg Java Swing). Making a cross-platform UI toolkit that looks native everywhere is an insane amount of work, because different platforms have very different UI toolkits, with different built-in components and different platform conventions. This problem becomes 10x harder if you want to make it work on mobile as well.

Some people try anyway - and bless their cotton socks. But electron (and arguably Qt) are the closest we've got. And even then, most electron apps seem to be full of custom components.

[markus_zhang]

Thanks, that makes sense. Where can I find a Windows specific (or Linux specific)? I actually don't care about cross-platform. Desktop is dominated by Windows anyway.

QT is not bad and I used it for a small project. But it follows native so I'm not sure how to go back to native Win2000 style.

[mike_hearn]

That's not really the cause. As you say, Electron apps don't look native either. The issues are elsewhere.

[dormento]

In theory, nothing will stop you. In practice, nothing stopped GAMBAS (https://gambas.sourceforge.net/en/main.html), which can do a lot of what VB did.

Problem is, the multitude of platforms, screen sizes, capability sets etc. that we must support in practice make a very compelling case for a unified runtime, which ended up being the current web tech turducken clusterfuck we have today.

If the CPUs were slower, hovewer... one can only wish.

[mike_hearn]

Depends what you mean by "similar to VB6/Delphi".

The VB6/Delphi era (called at the time RAD for Rapid Application Development) was oriented around proprietary UI and component frameworks. They were planned out a long way in advance and solved a lot of problems up front, but, they were tied to Windows and then you had to buy the dev tools on top.

These days people usually want to write web apps if they aren't doing mobile. The web as a UI framework is basically evolved rather than designed. The features you need to support RAD don't exist. Moreover the web UI community would view them as bad practice!

RAD tools were typified by a few things:

1. A standard way to define components that is statically reflectable (so you can populate property and event editors), and get documentation on the fly, etc.

2. MVC: a standard way to separate code from layout.

3. Layout management that's integrated with the component hierarchy.

4. A standard toolbox of high quality, high effort components.

5. A marketplace for components (which means they need to be distributable in binary form).

The web has none of this and isn't going to any time soon. For example, there's no agreement on how components work. React has one or more different solutions, Web Components is a different one, Vue yet another. MVC has been abandoned: React doesn't know anything about that. Code and layout are intermingled together. JavaScript is dynamically typed, largely reflection-free language. You can't automatically work out what the props are for a React component short of parsing the source code. You can't easily distribute proprietary components either because there's no way to enforce licensing (so a lot of users wouldn't pay, in reality).

And then there's the components. Browsers don't provide good enough components out of the box, unlike Windows-oriented RAD tools, so devs have to invent their own. Then React makes things worse by conflating theming with the component library. The result is that every web app has its own unique set of widgets with its own unique set of limitations and bugs, very few of which ever reach a high quality level. Widget development is expensive, which is why RAD tooling centralized it and supported a marketplace, so devs could amortize out the cost of writing widgets across many projects. The whole React/Jetpack Compose approach basically spurns all of that and says if you want to change the way your app looks you get to redevelop the widgets from scratch. And everyone does want that, so there are floods of duplicated work that's open sourced and then abandoned, but nothing ever gets critical mass.

[markus_zhang]

Thanks. It looks complicated. I'm learning Windows desktop development and will take a look of QT first. I used it for a small project years ago and the experience was OK.

> 1. A standard way to define components that is statically reflectable (so you can populate property and event editors), and get documentation on the fly, etc.

This was what I really loved about Visual Basic back in the day. Everything is within clicks -- even with the legacy IDE it still feels slick.

[throwaway55671]

> Honestly I’m really tempted to try to throw together a 90s style fantasy desktop environment and widget library and make some apps for it. There’s something about that era of computing that feels great.

SerenityOS might be exactly what you're looking for. Join the community and make some apps, it's great (both the community and the OS/dev experience)!

[red_admiral]

Is there any way to run something like "serenity's WM and file manager, but on my favorite linux distro?" Or is it all more tightly coupled than that?

[throwaway55671]

It's a Unix like OS with great separation of concerns. There probably is a way - their browser runs on Linux - but I don't think anyone has done it yet. Could be a fun project to look into!

[Froedlich]

In 2007 I put together a bunch of servers running openSUSE 10.2. They run some specialized application software that's version-dependent and is unlikely to ever be upgraded. The working network is not connected to the internet, so there's no reason to upgrade the OS.

They're full KDE installs, and openSUSE 10.2 wasn't a lightweight distribution in its day. But now, even running in VMs, UI and network response are noticeablly snappy, and are sparing of resources by modern standards.

[mwcampbell]

Do you think you'd write your 90s style widget set and desktop environment in Rust, or do you think Rust itself tends toward bloat (in non-embedded applications)? I know you use Rust in other projects, which is why I'm asking about that language specifically.

[markus_zhang]

Please do. I'm also wondering why no one created something similar to VB6 and Delphi.

[holsta]

  if [ "$os" = "Darwin" ]; then
    arch="universal"
    os="macos"
  elif [ "$os" = "Linux" ]; then
    os="linux"
  else
    echo "Unsupported OS."
   exit 1
  fi

This is nothing to emulate.

[josephg]

Why not? Does everything really need to be built in a cross platform way? I feel like that’s how we got into this mess.

[holsta]

Yes, bugs are often found by running the same code on similar but not identical platforms. We've had this conversation multiple times.

https://news.ycombinator.com/item?id=28978086

What mess are we in because of POSIX?

[josephg]

I’m talking about the mess of electron and friends. I’ve spoken to engineers who work on it. From their point of view, it’s the only sane way to build software that works across multiple operating systems.

The nice thing about windows and macOS back in the day was that the programs we ran were all written with the same native UI toolkit. All the controls matched between applications. Applications were small and efficient - binary sizes and memory usage were in the megabyte range. Any program written like that today starts up instantly, and is incredibly responsive.

But last I checked, Hello world in electron is ginormous. It uses about 100mb of memory. It takes time to start up. Vscode and Spotify are great but they don’t look or feel native. It is legitimately great that people now ship apps for Linux. But we’ve lost platform cohesion in the trade.

So, so what if tigerbeetle is written for Linux? I’m ok with the developers choosing not to pay the cross platform tax.

[arp242]

That's just the codepath from bootstrap.sh that downloads the binaries. I don't know if it will compile and run on, say, FreeBSD. It's quite possible no one tried.

[holsta]

I did, but there are literal compile-time checks for various platforms.

    pub fn monotonic(self: *Self) u64 {
        const m = blk: {
            if (is_windows) break :blk monotonic_windows();
            if (is_darwin) break :blk monotonic_darwin();
            if (is_linux) break :blk monotonic_linux();
            @compileError("unsupported OS");
        };

[arp242]

That genuinely seems platform-specific. Should be easy enough to write a patch to add support for $other_system.

[josephg]

According to the talk I watched, tigerbeetle makes heavy use of io_uring on linux - which isn't part of POSIX.

Adding freebsd support should be pretty easy. If it supports darwin, it'll probably already have an implementation built on top of freebsd's kqueue. Its probably just a case of wiring it up to use kqueue when built for freebsd.

[arp242]

Yes, that was my impression as well when I looked at it yesterday. The monotonic_linux() bit that's quoted is platform-specific because it uses CLOCK_BOOTTIME with clock_gettime(), but that seems supported on BSD systems as well. It's probably just that no one tried to run it, and no one spent any effort on it. I can't find a single mention of "BSD" in the issue tracker.

[logicprog]

> Honestly I’m really tempted to try to throw together a 90s style fantasy desktop environment and widget library and make some apps for it. There’s something about that era of computing that feels great.

If you're interested in that, you should definitely check out Serenity OS!