Live data from Hacker News

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

avraam.dev

71–80 of 132 posts

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

#71

I'm surprised the author of this article thinks Go is a "system language". Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it. C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in…

The Go creators declared it a systems language and it's stuck around for some reason.

Their definition was not the one most people would have used (leading to C, C++, Rust, Ada, etc. as you listed) but systems as in server systems, distributed services, etc. That is, it's a networked systems language not a low-level systems language.

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

#73

The author makes the argument that in the age of LLMs more type safe languages will be more successful than less type safe ones. But how does that support the claim that Go is more suitable than JavaScript? TypeScript is more type safe than Go: Go doesn’t validate nil pointers, it doesn’t enforce fields to be set when initializing structs, it has no support for union types. All those things can cause runtime errors t…

Not sure, but I gave it a shot weeks ago and finally started building something using Rust for a project I've wanted to build for years now, in maybe 12 hours worth of effort total I've probably done several months worth of engineering effort (when you consider I only touch this project in my spare time). Every time I pick up Rust I fight it for hours because I don't do any Rust in my dayjob, but the LLM helps me pick up that Rust nuance slack wherever I fall short and I can focus on key architectural details as I have been obsessing over years now.

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

#74
I mean the simple answer here is to just develop proper frameworks for Futamura projections. There's an exact one to one algorithmic correspondence between an interpreted program and the compiled version of that. GraalVM and PyPy are good options here.

Using an LLM is overkill especially when correctness can never be guaranteed by systems who must sample from a probability distribution.

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

#75

Earlier quoted context omitted.

Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.

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.

There are programs that "work" but the reason they "work" is complicated enough that the BC is unable to understand it. But such programs tend to be difficult for human readers to understand too, and usually unnecessarily so.

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

#76

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

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 help but wonder if I’m actually stunting my learning curve and might end up slower in the long term.

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

#77

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!)

What does the struggle with an LLMs help look like?

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

#78

The author makes the argument that in the age of LLMs more type safe languages will be more successful than less type safe ones. But how does that support the claim that Go is more suitable than JavaScript? TypeScript is more type safe than Go: Go doesn’t validate nil pointers, it doesn’t enforce fields to be set when initializing structs, it has no support for union types. All those things can cause runtime errors t…

A gross mischaracterization of the author's point (the word "type" doesn't even appear in the article). The author focuses on the cost of interpreted languages, which he describes as "memory hungry" and computationally expensive.

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

#79

I'm surprised the author of this article thinks Go is a "system language". Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it. C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in…

I think the broad consensus (and I agree with it) is that a systems language cannot have a mandatory GC. The issue with GCs isn’t just latency-optimized applications like hard real-time. GCs also reduce performance in throughput-optimized applications that are latency insensitive, albeit for different reasons.

Anything that calls itself a “systems language” should support performance engineering to the limits of the compiler and hardware. The issue with a GC is that it renders entire classes of optimization impossible even in theory.

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

#80
post #72

If LLMs live up to their potential, then they should be able to rewrite language runtimes to eventually be as fast or faster than systems languages. "Sufficiently intelligent compiler" and whatnot

No, because some language features like monkey patching have inherent runtime cost that cannot be eliminated. And if we reach superintelligence you can just let the AI invent its own language.
Post reply on HN