philm @ philm @programming.dev

Posts

1

Comments

131

Joined

2 yr. ago

Yeah best is probably not the "best" wording and a little bit provocative, but it's the "best" ecosystem I have found so far (and I squabbled around with like ~10+ programming languages, often at a deeper level). I'm mostly talking out of a development-experience + quality of software standpoint.

I'm very happy to be proven wrong, or be given a different direction (but C# or JS/TS are definitely not the languages/ecosystem I want to be confronted with, or even maintain systems in it...)

Sure you can doubt me as much as you want (and this is probably a healthy attitude). I tend to educate myself, and learn from experience (and that I dare to say, I do have...). As you may have guessed, I really recommend looking into it, there's so many good design decisions with Rust (and the ecosystem). As a starting point/library: axum would be the web-framework I'd recommend to use (as it uses Rust quite idiomatically). And for e.g. service communication via grpc, tonic is quite nice. As database abstraction layer the last time I have used sqlx which was quite convenient to use. (So far with a "classic" web-stack). And rust-analyzer is probably the best language server I have used (and felt the fast development over the time (with "successful" switch of the maintainer), which speaks for itself as well...).

Btw. it also really depends on what you actually mean with "web backend development". I.e. "just" writing a web-server that takes connections via HTTP or something deeper the stack...

Sure I'm totally in for something new, maybe even more in a wiki based style (i.e. collecting knowledge) or a mix of all kinds of things (like StackExchange etc.). But I don't think that the concerns you have, have much to do with the platform and more with the users using the platform. The communities I'm mostly on, are civil and objective/less emotionally driven. This topic is (as the title already implies) a little bit the exception...

Mastodon - not a link aggregator, tree-threaded, kbin hmm PHP (yuk) and mostly one contributor and by far not as feature rich as lemmy. The rest similarly as Mastodon is not close to reddit as lemmy is.

And yes ActivityPub grows with multiple projects, but I mean specifically something like lemmy or kbin and something that can be a reddit replacement of sorts. There's a little bit more happening than just ActivityPub behind the scenes btw. And it's still no small feat to have a platform like Mastodon or lemmy (I think those two are the mostly the forerunners by now). Sure it's not super complex, but the amount of features are often underestimated by a lot of people (as far as I can read here and often somewhere else, so why is there no real alternative to lemmy yet...?)

Really? Is it necessary to ban people about making a valid argument. I know and also don't like people asking a low effort "What's the status of this" (and would totally get why such a thing would be marked off-topic, but a ban over something like this is still to harsh IMHO, they will learn, that such questions are not well-received over just the marking it as off-topic).

But the comment discussed here has a valid concern (quickly closing issues that don't have satisfactory solution yet, without getting feedback).

A better reaction would be to just ask, whether the issue at hand is still relevant, having [these] alternatives at hand etc.

And yet, I don't know of a better project. Growing, maintained projects will usually get better over time (take major refactors, when being modular, rewritten parts of it etc.). But yeah growing needs to have a healthy and friendly Community Code of Conduct, and that I am more concerned of...

Well yeah the second comment didn't really had to be, but hey it's certainly not really reason enough to ban someone from the repo. The first comment I think is totally ok (as well as marking it off-topic, but optimally with an answer, probably marked as off-topic as well). Just keep an issue (it's not a PR) open, until the issue is resolved in one way or the other i.e. either solved reasonably via a third-party client (with links to it) or directly in the repo, asking the community (when it's not obvious that the issue is resolved), whether this is resolved, wait for reactions, and close it after some time based on that. Banning someone, or quickly closing or not reopening after a carefully written argument, that the issue is not solved etc. is just childish behaviour, especially for a community focused project (I'm watching a few lemmy issues on GH).

despite what Rust cultists will undoubtedly soon come to tell me

And here I am :)

There's a lot of reasons to go with Rust (and least of all performance), especially as web-backend. Top-notch libraries/ecosystem (I work extensively with all kinds of programming languages and most others suck in one way or the other). At this point I dare to say that it has the best ecosystem in this regards. Also a static type-system only being exceeded by Haskell (when talking about general purpose languages, that are actually in use), which makes projects maintainable by a lot of people, especially relevant for an open source project. There's a reason why a lot of high quality projects are either rewriting or starting in Rust or are thinking to switch to... Etc. don't want to throw more Rust evangalism at you, since there's a lot to just google and learn...

Anyway, there were a few changes lately that made federated lemmy better (with the last release especially), the initial bugs I accept. But I agree, they aren't veterans from the valley with multiple years of experience, just a bunch of idealists that had an idea and were persistent enough for years to implement it, I certainly have respect for that. What I don't like, is that they are moderating a little bit too much, not being mostly community focused (among others, to avoid forks). But bringing a federated link aggregator like lemmy to the place where it currently is, at least takes quite a bit of time... So a fork (if really necessary) sounds like the most likely way forward...

That only really works, if the method is self-contained, and written in a language that GPT has seen often (such as python). I stopped using it, because for 1 in 10 successful tries I waste time for the other 9 tries...

This.

If I'm writing something slightly more complex, ChatGPT(4) is mostly failing.

If I'm writing complex code, I don't even get the idea of using ChatGPT, because I'm only getting disappointed, and in the end waste more time trying to "engineer" the prompt, only to get disappointed again.

I currently cannot imagine using ChatGPT for coding, I was excited in the beginning, and it's sometimes useful, but mostly not really for coding...

$0.7k annually? Is it anyhow possible to live with that low salary in India? I can't even live a month with that here, even if I don't buy anything but the cheapest food and live in the smallest apartments here...

I think the crux of good software design, is having a good feeling/intuition when to abstract and compose, and when to "inline" code as it's used only once anyway (in which case "linear code" is IMHO often the better choice, since you're staying close to the logic all the time without having to jump between files etc.).

I agree the examples of the google blog are bad, they don't really show how to compose code nicely and in a logical way (whether that would be more data-oriented, imperative or OOP).

Yes

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)

 rust

    
// 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).