Yes
philm
It could definitely use integration with a linter so it doesn’t generate subtle bugs around generative naming mismatching actual methods/variables, but it’s become remarkably good, particularly in the past few weeks.
Maybe I should try it again, I doubt thought that it really helps me, I'm a fast typer, and I don't like to be interrupted by something wrong all the time (or not really useful) when I have a creative phase (a good LSP like rust-analyzer seems to be a sweet spot I think). And something like copilot seems to just confuse me all the time, either by showing plain wrong stuff, or something like: what does it want? ahh makes sense -> why this way, that way is better (then writing instead how I would've done it), so I'll just skip that part for more complex stuff at least.
But it would be interesting how it may look like with code that's a little bit less exotic/living on the edge of the language. Like typical frontend or backend stuff.
In what context are you using it, that it provides good results?
I would actually encourage it to be extremely verbose with comments
Yeah I don't know, I'm not writing the code to feed it to an LLM, I like to write it for humans, with good function doc (for humans), I hope that an LLM is smart enough at some day to get the context. And that may be soon enough, but til then, I don't see a real benefit of LLMs for code (other than (imprecise) boilerplate generators).
Yeah my thinking as well.
Addtionally, why I think other system language competitors like Zig or Nim aren't succeeding long-term, is because of fast growth and already big ecosystem of Rust. Zig may be better though for some use-cases (when you want to avoid all the mental overhead, and the application stays simple).
On another look, though, we have to keep in mind, though that this is code-golf, so in no way representative for actual code-bases.
Hmm interesting, I would've thought that Haskell would rank much higher
Has it though?
AFAIK it has like 4k tokens which roughly translate to 3k words or something like that.
The API has 8k or even 32k (this model should be interesting for something like that, unfortunately still don't have access to it...)
So the docs have to be rather short, that it gets all the relevant stuff, or am I missing something?
I'm mostly using ChatGPT4, because I don't use vscode (helix), and as far as I could see it from colleagues, the current Copilot(X) is not helpful at all...
I'm describing the problem (context etc.), maybe paste some code there, and hope that it gets what I mean, when it doesn't (which seems to be rather often), I'll try to help it with the context it hasn't gotten, but it very often fails, unless the code stuff is rather simple (i.e. boilerplaty).
But even if I want the GPT4 to generate a bunch of boilerplate, it introduces something like // repeat this 20 times
in between the code that it should actually generate, and even if I tell it multiple times that it should generate the exact code, it fails pretty much all the time, also with increased context size via the API, so that it should actually be able to do it in one go, the gpt4-0314
model (via the API) seems to be a bit better here.
I'm absolutely interested where this leads, and I'm the first that monitors all the changes, but right now it slows me down, rather than really helping me. Copilot may be interesting in the future, but right now it's dumb as fu... I'm not writing boilerplaty code, it's rather complex stuff, and it fails catastrophically there, I don't see that this will change in the near future. GPT4 got dumber over the course of the last half year, it was certainly better at the beginning. I can remember being rather impressed by it, but now meh...
It's good for natural language stuff though, but not really for novel creative stuff in code (I'm doing most stuff in Rust btw.).
But GPT5 will be interesting. I doubt, that I'll really profit from it for code related stuff (maybe GPT6 then or so), but we'll see... All the other developments in that space are also quite interesting. So when it's actually viable to train or constrain your own LLM on your own bigger codebase, such that it really gets the details, and gives actual helpful suggestions, (e.g. something like the recent CodeLlama release) this stuff may be more interesting for actual coding.
I'm not even letting it generate comments (e.g. above functions) because it's kinda like this currently (figurative, more fancy but wordy, and not really helpful)
// this variable is of type int
let a = 8;
Just learn whatever you currently need. If you know a few paradigms, learning a new language of the same paradigm is easy-peasy and can be done rather quickly (well at least being be productive with it, doing stuff idiomatically often takes a little bit longer).
That said, Rust IMO is a language that makes sense to learn anyway, since it also teaches you to program in a nicer way (not just true for Rust, there are other languages that have this effect as well, such as Haskell etc. generally languages that introduce something really new (i.e. a new paradigm)). Generally it makes sense to learn multiple languages, as each brings you new ideas. But on the other hand it makes sense to learn one language really well (I'd recommend that being Rust, as it can cover so many use-cases and is generally designed nicely (it fills a sweet spot between mutability and functional programming IMHO).
Swift is a nice language though.
But I'm obviously on team Rust^^ for various reasons (one being that you can do the whole stack in Rust (not that it's necessarily the best choice for each level, but it really composes well and with a little bit of trait-magic abstraction in the higher levels it works quite well IME)
For ML, python yes, certainly for high-level stuff at least currently. I wouldn't be so sure in the future about the lower stack though, Rust seems to gain momentum there as well (potentially replacing use-cases where currently python is dominant too).
Well just program a little bit more Rust, at some point you don't want to look back haha. It's almost like a curse for me, I can't really enjoy programming in another language anymore (ok not completely true, but at least the major languages I had to use before like C# or Typescript etc. feel dirty and limiting now ^^). I would enjoy something like Haskell with better tooling anonymous sets, less laziness and a slightly more opinionated syntax though (having all kinds of weird operators sometimes looks a little bit brainfuck). Sometimes Rust is a little bit boiler-platy and gets complex when you're overusing fancy trait-based generic code (but it's kinda fun, you can do a lot of fancy stuff with traits), and often the type system is limited compared to Haskells, if you're approaching higher-kinded types territory...
I’d be hesitant to suggest it for most backend application just due to the ramp up time for new developers.
I would probably suggest Rust for that exact reason, you'll have to fight the language a little bit at the beginning (at least if you'll have a very "interior mutable" experience instead of a functional background), but it teaches you how to write your code in a nicely relatively uniform compositional safe style, that IMHO can be read quite well between different people (team) and I think is easier to review (as long as it's not some super magic trait-heavy/proc-macro code of course, but I think for actual applications (vs libraries) that part will be rather low)
Also I think nowadays the barrier into the language is much lower than it was a few years ago. The tooling, specifically rust-analyzer (and probably Intellij Rust too, never tried it though) and the compiler itself got really good in the meantime (I actually think Rust-analyzer is by now the best LSP for any language I know of), so that getting into Rust is likely not that hard anymore (you'll have to learn/understand a few concepts though, like heap/stack and the lifetime system, but I think that it's not that hard to learn).
Go just often feels very hacky to write with a lot of quirky things like handling errors, and a lot of missing features like pattern matching or a relatively good type system, I don't think it really promotes that nice architectures (or limits the programmer kinda).
Yeah it's more of a disaster of choosing Unity for new stuff.
While it was "almost" a no-brainer to use Unity in the past for student projects, this change among other negative stuff/press that happened with Unity etc. in the younger past slowly presses you towards e.g. Godot, since it can do as much as Unity can (at least in the beginning, as you're not hitting the limits of it) and is more in line with the academic way of thinking (not pressing charges for pretty much everything that is possible to press charges for...)
As I have used Unity extensively in the past, the amount of progress is dwarved by e.g. Unreal. It has not really made significant progress over the last (lets say) ~5 years, compared to Godot and Unreal (and soon Bevy when they have an editor/UI for better workflow for artists etc.).
So I don't see a long-term future for Unity, most of the "progress" of Unity was buying in technology that doesn't really feel organic in the Unity ecosystem (not just buying in, e.g. the ECS of Unity doesn't feel close as ergonomic compared to Bevys).
I think this slow and scattered progress will be the slow death sentence for Unity as other engines with less enshitification over the past will catch up, and don't have such a greedy dumbfu** of a CEO...