Look at you, complaining about your famously on schedule Japanese trains! ;)
Over here in France a train is considered on time if it has up to a 15mn delay. We can ask for a very partial refund only if it has at least 30mn of delay, and we get a voucher to book another train that will also be late.
Thanks for sharing, it's indeed a great way to quickly see what a language has to offer.
From what I understand, the main innovation of Lobster here is that `class Foo` is a boxed type, while `struct Bar` will be inlined. I'm not sure I see how that's an improvement over using either `Foo` or `Box<Foo>` on instantiation. It also does reference counting by default, and tries to optimise it out at compile time by assigning a single owner and borrow.
We often see complains that Rust's ownership puts a lot of burden on the programmer, but there is really a point at which it clicks and we stop having to fight the borrow checker almost entirely.
Lobster is meant to be a more high level language than Rust, so encoding what you want 99% of the time in the type made sense. It also makes it easier for people to read, knowing that common types like int2 are always by value.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
I agree with all of this, but that's assuming we've reached a plateau. Maybe Claude 6.3 will be able to churn through 10M lines of Java and Cobol, tidy it and convert it to Rust. Or maybe not, but so far the scaling laws are holding.
Oh I am sure with the right prompts and the right chunking and subagents this is already possible today. But converting the old cobol mess to java code that is "most likely doing the same things" is just a fraction of the work.
You need to run those systems in parallel, integrate them in each other or have an abstraction/two-rails layer in front of them, test, test, test and test again, all of which takes months, while new features now need to be added to both systems, whether by AI or some average developer schmuck!
Do you have any idea how much any of this costs? Mind boggling amounts of money. Infrastructure costs will at least DOUBLE for several MONTHS. Meanwhile you will need extra manpower and AI credits for MONTHS on top of your increased existing costs for maintenance and new features.
You don't need to convince me that this is hell, in particular with all the managers who have never written a single line of code being now convinced that programming is completely solved.
Well they will train on my Claude Code sessions for a start. I spend a lot of time asking it to remove unnecessary code that was produced, I'm not the only one.
I've been using fluffychat for over a year. It's a nice interface and the client I used to convince less technical friends and family to give Matrix a try. Unfortunately major functionality like being able to send images becomes broken for long periods of time https://github.com/krille-chan/fluffychat/issues/2497
Matrix has gotten to a complexity threshold that makes it near-impossible to have independent client/server implementations. Element is terrible, and many contenders are better in a way or another, but all lack some essential feature to turn them into practical alternatives.
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore.
I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent.
The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program.
I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.
I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
Is it still true with llms being so good at interpreting it? I just tried all the examples on the home page, it works perfectly. In the past couple months I've moved almost entirely back to the terminal because I can just ask my coding agent to "have a look at this tmux session".
As a technical person, how does one find a non-technical business partner? ;)
I know about Entrepreneur First, but that's not for bootstrapping and has a too much of the unicorn vibe for me. The obvious is of course luck through one's social network.
>> The obvious is of course luck through one's social network.
I'd really counsel you to pursue this but not focus on the luck piece of it (which really is a big part). Just like hiring works best when it's a recommendation of a known good hire, look to your 2nd (and possibly 3rd) degree network. Force yourself to attend events, programs and communities (irl & virtual) outside of your direct sphere of expertise. Economic development orgs in your city/region might work too. Maybe you can do it with some help/practice and don't need a partner? You could be looking for a support network more than business expertise; the good news is IME that's easier to find than a partner.
reply