Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Any application that can be written in a system language, eventually will be

avraam.dev

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Any application that can be written in a system language, eventually will be

#101

Post by ChadNauseam »

ycombinatrix wrote: post #99
forrestthewoods wrote: post #33

Earlier quoted context omitted.

This is a n objectively false statement. Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them. I’m a big fan of Rust and the BC. But let’s not twist reality here.

>There are many correct programs that the BC is unable to prove to be correct and therefore rejects them. No. The borrow checker rejects programs that are definitely incorrect. It does not require that the program is correct. That's a big difference.

there’s a miscommunication. programs that pass the borrow checker all are memory safe (assuming code marked unsafe is sound). This means that all memory unsafe programs are excluded. but some memory-safe programs are excluded too.

Re: Any application that can be written in a system language, eventually will be

#102

Post by ChadNauseam »

jimbob45 wrote: post #84
yert3 wrote: post #82

Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.

Rust isn’t versatile enough to be used in high-level contexts. You simply have to jump through too many hoops. It’s great for low-level apps but if I just want a simple UI and CRUD functionality, I’m reaching for C#/Kotlin. That’s not a bad thing though. It’s okay to aim for your thing and be good at just that. No need to try to please everyone.

That’s not my experience. I use rust in my web application. It’s compiled to WASM and runs in the browser. About as high level as it gets. And I almost never feel I have to jump through hoops. The only time I do is when I’m implementing something that’s plain impossible in javascript, like zero-copy deserialization.

On the other hand, I constantly have to jump through hoops in javascript. You literally cannot compare two objects for structural equality in JS without jumping through hoops. It’s unbelievable. Yet no one says javascript is not versatile enough to be used in high level contexts.

It is fair to say that the way Rust deals with closures requires too much hoop-jumping to make a truly ergonomic reach equivalent

Re: Any application that can be written in a system language, eventually will be

#103

Post by ChadNauseam »

gritspants wrote: post #87
yert3 wrote: post #82

Why not assembly? Not enough compile time checks, only runtime errors. Why not go? Slower than rust. Type system is lacking. Why not c? Not memory safe. Why not c++? Also not memory safe. Why not zig? Not memory safe. Why rust? Fast, memory safe, type safe. Compiler pushes back on LLM hallucinations and errors. Over time, security-critical and performance-critical projects will autonomously be rewritten in rust.

So, I am then interested in non trivial software written with LLM assistance and in Rust. Off the top of my head I'm aware of Turso (supposed sqlite successor), marketing approach aise, I find it interesting to see how that works out. Any others?

I’ve been working on this since approximately when claude code was first released: https://github.com/yaptown/yap

As hobby projects go it’s “in production” with maybe 50 active users, so nothing crazy. Definitely less ambitious than a sqlite successor. But it’s not trivial. (The repo history is truncated to save money on github LFS storage.)

Re: Any application that can be written in a system language, eventually will be

#104

Post by tasuki »

fwip wrote: post #62
jact wrote: post #50

Earlier quoted context omitted.

Are Python apps really so easy to understand? I seriously disagree with this idea given how much magic goes behind nearly every line of Python. Especially if you veer off the happy path. I certainly am no fan of C but from a certain point of view it’s much easier to understand what’s going on in C.

Well-written Python apps are very easy to understand, especially if they use well-designed libraries. The 'magic' in Python means that skilled developers can write libraries that work at the appropriate level of abstraction, so they are a joy to use. Conversely, it also means that a junior dev, or an LLM pretending to be a junior dev, can write insane things that are nearly impossible to use correctly.

> Well-written Python apps are very easy to understand, especially if they use well-designed libraries.

Oh. Why haven't I seen those?

Re: Any application that can be written in a system language, eventually will be

#105

Post by fc417fc802 »

ajkjk wrote: post #42

I kinda like viewing this as similar to coordinate-invariance in physics / geometry. A programming language is effectively a function from textual programs to behaviors; this serves the same role as a coordinate system on a space, which is a function from coordinates to points. Naturally many different programs and programming languages can describe the same behavior, especially if you forget about implementation-spe…

I've also found myself thinking a lot about isomorphic languages, particularly the edge cases I run into when I start attempting to run through potential mappings for various aspects of syntax or language features in my mind.

> with all of the language-specific concepts stripped away

I've arrived at a somewhat different conclusion. I think we'll arrive at a maximally cumbersome, maximally verbose interchange format that isn't intended to be parsed by a human. One capable of expressing literally every feature of every language that it officially supports. Otherwise translation will necessarily be lossy and round trips with perfect fidelity impossible.

Even then certain paradigms that are common today simply don't seem possible to translate between arbitrary language pairs. I think the client language would also need to be tailored to support the paradigm. Consider how you would go about abstracting (for example) longjump in C and how fundamentally incompatible that is with (for example) Java in its present form. Or how you would deal with differences in ordering requirements as well as any implicit synchronization points between languages.

I figure that C++ will be a viable candidate for the interchange format if we wait another 10 years or so. Just need to add a borrow checker, first class continuations, full blown AST macros, and a runtime "eval" facility. It's slightly tongue in cheek but it's wild to think that actually it could almost work (including the bit about not being intended to be parsed by a human).

Re: Any application that can be written in a system language, eventually will be

#106

Post by forrestthewoods »

ycombinatrix wrote: post #99
forrestthewoods wrote: post #33

Earlier quoted context omitted.

This is a n objectively false statement. Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them. I’m a big fan of Rust and the BC. But let’s not twist reality here.

>There are many correct programs that the BC is unable to prove to be correct and therefore rejects them. No. The borrow checker rejects programs that are definitely incorrect. It does not require that the program is correct. That's a big difference.

No.

The BC will not incorrectly approve an incorrect program.

But the BC does not approve all correct programs. Because some patterns which are indeed perfectly correct and will never explode the BC is not able to prove that and therefore the BC rejects the program.

The BC is effectively incompatible with typical video game patterns. The whole level/frame life cycle is effectively unsupported by the Rust BC. As just one example.

Re: Any application that can be written in a system language, eventually will be

#107

Post by a96 »

nemo1618 wrote: post #20
spicyusername wrote: post #10

I wonder when we'll start to see languages designed exclusively to be easy to write by agent programming.

Here's one attempt: https://x.com/sigilante/status/2013743578950873105 My take: Any gains from an "LLM-oriented language" will be swamped by the massive training set advantage held by existing mainstream languages. In order to compete, you would need to very rapidly build up a massive corpus of code examples in your new language, and the only way to do that is with... LLMs. Maybe it's feasible, but I suspect that it…

If only we had some programs that were good at generating vast amounts of code examples.

Re: Any application that can be written in a system language, eventually will be

#108

Post by bartread »

captain_coffee wrote: post #63
bartread wrote: post #36

Earlier quoted context omitted.

Yeah, I would say it's pretty variable, and it depends on what you mean by the word write. I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture…

So let me get this straight - you vibe code, make what you consider as necessary changes to the LLM-generated code, create PRs that get to be reviewed by another AI tool (Copilot), potentially make changes based on Copilot's suggestions and at the end, when you are satisfied with that particular PR you merge it yourself without having any other human reviewing it and then continue to the next PR. Did I get that right…

Not quite: remember I said I fettled the code myself? This might involve rewriting, refactoring, reorganising, and I'll make changes to Copilot's PRs as well, but still the percentage of code written by LLM remains what I'd consider to be very high.

I've been an engineer for more than 25 years so I know how to architect an application from the highest level down to the fine details, and I can obviously code in a variety of languages. Even with Ruby and Rails I know it well enough to read and understand the code already. Plus I obviously know HTML and JavaScript, and have used various CSS frameworks and overlays. (Though the truth is I basically hate fussing with CSS [and its various proxies], and I'm very far indeed from the king of UX or design anyway, so having an LLM to assist with that is a godsend.)

The strict definition of vibe coding, as far as I've understood it, is that you don't touch or even really look at the code at all, and make all modifications, do debugging, etc., via prompting the LLM or using an agent. Vibe coding tends to break down in critical areas like security, or when the contours and wrinkles of the domain become too complex, so I'd never trust that approach for anything substantial or where security is a critical concern. For most organisations the data that I'm working with in our app is going to be second only to financial information in terms of sensitivity, and it's a complex domain, so the problems we're solving are simply not amenable to a pure vibe-coding approach.

Going back to the original point on how much code LLMs are writing: with other languages that I'm more familiar with, where it might be quicker for me to write the code to do what I need myself rather than write a spec for the LLM, and modify afterwards, you would probably see quite a different picture.

Re: Any application that can be written in a system language, eventually will be

#109

Post by bartread »

WD-42 wrote: post #76
bartread wrote: post #36

Earlier quoted context omitted.

Yeah, I would say it's pretty variable, and it depends on what you mean by the word write. I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture…

This is exactly how I use AI as well in codebases and languages I’m not familiar with. I’m a bit concerned we might be losing something without the google and stack overflow rabbit holes, and that’s the context surrounding the answer. Without digging through docs you don’t see what else is there. Without the comments on the SO answer you might miss some caveats. So while I’m faster than I would have been, I can’t hel…

Yeah, I had that concern as well, but I tend to find that both ChatGPT and Claude do a pretty good job of explaining the issues around the solutions I'm using them for, so I think - maybe not all - but a good portion of that learning is still happening. No doubt this is a result of the way I prompt them, because it does involve a lot of discussion, iteration, and back and forth.

Of course, you do have to know what you're doing well enough to spot a hallucination, and those do occur but, I mean, how often do you go down a blind alley or rethink your approach with coding, particularly with a new platform or framework, anyway? It doesn't feel like I'm wasting a huge amount of time here.

Re: Any application that can be written in a system language, eventually will be

#110

Post by bartread »

AstroBen wrote: post #44
bartread wrote: post #36

Earlier quoted context omitted.

Yeah, I would say it's pretty variable, and it depends on what you mean by the word write. I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture…

This seems like a really short-sighted view. 6 months from now you'll be much more inexperienced than if you just went through the initial struggle (with an LLM's help!)

I'm not sure what you mean by this. As I mentioned in another comment, both ChatGPT and Claude to a pretty good job of explaining around the solution we're working on - because of the way I'm prompting them, no doubt - and it's not as if I haven't also worked through both Ruby and Rails tutorials.

What I'd observe is that it's simply a different way of learning, but to me it seems like it's working at least decently well, and it means that I'm able to devote more time to thinking about and working on our roadmap and higher level issues without completely screwing my work/life balance - and, critically, time with family because the kids are growing up fast.

Post reply on HN