Live data from Hacker News

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

avraam.dev

121–130 of 132 posts

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

#121

Earlier quoted context omitted.

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…

Leptos? Dioxus?

Meant to say "react equivalent". And no, I don't use either. IMO they're not quite mature enough for me to match my productivity in javascript with them. They're getting there though. I just use rust for the actually difficult logic and have javascript as a thin layer for the UI.

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

#122

Earlier quoted context omitted.

Sadly, I'm seeing a LOT of this kinda of usage. So much so, I know a couple people that brag about how many they have running at time same time, pretty much all the time.

Including Steve Yegge, is Gas Town orchestrator of LLMs is... wild. And complicated. https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...

I think he smokes more weed than I ever did.

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

#123

Earlier quoted context omitted.

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 vari…

Yes OK, but that was not the point that I was trying to make. You are developing in a language + framework that you are not familiar with, without having any human feedback in the process at all - see where I am going with this? Even with a quarter of a decade of experience you are still in what can basically be reffered to as uncharted territory.

Define what you mean by uncharted territory?

- I've never used a new language or framework before? Nope

- I've never used both a new language and a new framework at the same time? Nope

- I've never tried to do real work in a new language and new framework that I'm not particularly familiar with? Nope

- I've never shipped work I've done in a new langauge and new framework that I'm not particularly familiar with? Nope

What specifically do you think is so magic about Ruby and/or Rails that you think I won't have encountered something similar in some other form - in some other language or framework - before?

And do you not think that the reviewing and changes that I am making to the code, the prompting I'm doing, the decisions I'm making about which changes to integrate and which to ignore, etc., as a human being, count as feedback?

At the end of the day I'm building a web app, and soon enough an API, and the concerns in building this web app and API are exactly the same as the concerns I've had in building other web apps and APIs.

The only difference is the language and the framework, and I've learned new languages and frameworks before. And, although I'm using an LLM to help, I've been doing that for the past 3 years using different stacks and the only notable difference is that LLMs are quite a lot better at helping to develop software than they were 3 years ago.

So how is this uncharted territory?

---

And, as an aside, not an issue you've raised but one I commonly see on HN: people moaning about job ads demanding X years of experience in this or that framework or language (with the parody being that the desired framework or language has only existed for X years, or maybe not even that long), and how this isn't really relevant to whether an experienced software engineer can do the advertised job or not. I happen to agree with that perspective but here's the thing: you can't have it both ways. Either that's true or it's not true, and I'm operating (as I have done before and as you can probably tell) on the basis that it is true.

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

#124

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

Lisp? I'm always surprised when agents aren't working directly with the AST.

btw. Clojure (modern Lisp dialect) been said to be very token efficient.

https://martinalderson.com/posts/which-programming-languages...

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

#125
post #9

Earlier quoted context omitted.

I'm not sure that's true. Bombarding code with huge numbers of randomly generated tests can be highly effective, especially if the tests are curated by examining coverage (and perhaps mutation kills) in the original code.

Right, that method is pretty good at finding unintentional behavior changes in a refactor. It is not very well suited for showing that the program is correct which is probably what your parent meant.

That doesn't seem like the same problem at all. The problem here was reimplementing the program in another language, not doing that while at the same time identifying bugs in it.

Conversion of one program to another while preserving behavior is a problem much dumber programs (like compilers) solve all the time.

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

#126
post #115
post #22

Earlier quoted context omitted.

The thing is LLM-assisted C is still memory unsafe and almost certainly has undefined behaviour; the LLM might catch some low hanging fruit memory problems but you can never be confident that it's caught them all. So it doesn't really leave you any better off in the ways that matter.

Almost as well as a human doing it!

Better than a human maybe. But still not good enough to rely on.

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

#127
post #7
post #3

This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner. In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borr…

n_u's point about LLMs as mentors for Rust's borrow checker matches my experience. The error messages are famously helpful, but sometimes you need someone to explain the why. I've noticed the same pattern learning other things. Having an on-demand tutor that can see your exact code changes the learning curve. You still have to do the work, but you get unstuck faster.

Storngly agreed. Or ask it to explain the implications of using different ownership models. I love to ask it for options, to what if scenarios out. It's been incredibly helpful for learning rust.

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

#128
post #3

This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner. In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borr…

>In particular, an error on one line may force you to change a large part of your code.

There's a simple trick to avoid that, use `.clone()` more and use fewer references.

In C++ you would be probably copying around even more data unnecessarily before optimization. In Rust everything is move by default. A few clones here and there can obviate the need to think about lifetimes everywhere and put you roughly on par with normal C++.

You can still optimize later when you solved the problem.

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

#129
post #128
post #3

This is my second attempt learning Rust and I have found that LLMs are a game-changer. They are really good at proposing ways to deal with borrow-checker problems that are very difficult to diagnose as a Rust beginner. In particular, an error on one line may force you to change a large part of your code. As a beginner this can be intimidating ("do I really need to change everything that uses this struct to use a borr…

>In particular, an error on one line may force you to change a large part of your code. There's a simple trick to avoid that, use `.clone()` more and use fewer references. In C++ you would be probably copying around even more data unnecessarily before optimization. In Rust everything is move by default. A few clones here and there can obviate the need to think about lifetimes everywhere and put you roughly on par wit…

Clone doesn't work when you need to propagate data mutations, which is what you need most of the time.

Another option is to just use cells and treat the execution model similarly to JavaScript where mutation is limited specific scopes.

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

#130

Earlier quoted context omitted.

Including Steve Yegge, is Gas Town orchestrator of LLMs is... wild. And complicated. https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...

I think he smokes more weed than I ever did.

Now that I've read that link (well... a bit, I just couldn't at a certain point) I totally understand this comment.
Post reply on HN