philm @ philm @programming.dev

Posts

1

Comments

131

Joined

2 yr. ago

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

I actually think java is more cumbersome to write, Rust is definitely higher cognitive load though (get the typing right, fight the borrow-checker etc.).

With cumbersome I mean, that the language limits yourself with a relatively bad type system (compared to Rusts) and often results in a lot of boilerplate and IMHO generally promotes the wrong patterns (I think https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition brings this on point in a comical way). But I'm biased, I much prefer functional programming vs object oriented programming...

I mean yeah, dynamic libraries are great if used correctly (via something like Nix), but the unfortunate truth is, that they are not used correctly most of the time (the majority of the Unix and Windows landscape is just a mess with dynamic libraries).

With modern systems programming (Rust) the disadvantages of static compilation slowly fade away though via e.g. incremental compilation.

That said dynamic libraries are still a lot faster to link and can e.g. be hot-swapped.

Language agnostic development may be quite viable within a year or so.

I doubt that very much, GPT4 (to my knowledge still the best LLM) is far from being there. As (my) initial hype is overcome, I have basically stopped using it because I have to "help" it too much (and it got really worse over time...) so that I spent more time to get any usable results from it, instead of just writing the goddamn code myself. There has to be a very large step in progress, that this is anywhere feasible (maybe that's true for some "boilerplate" react UI code though). You have to have in mind, that you should still review all the code which takes a good chunk of the time (especially if it's full with issues as it is with LLMs). Often I go over it and think yes, this is ok, and then I check it out in more detail and find a lot of issues that cost me more time compared to writing the code myself in the first place.

I have actually fed GPT4 a lot of natural language instructions to write code, and it was kind of a disaster, I have to try that again with more code instructions, as I think it's better to just provide an LLM the code directly, if it will really get smart enough it will understand the intentions of the code without comments (as it has seen a lot of code).

Context size is also a bigger issue, the LLM just doesn't have as much overview over the code and the relevant details (I need to try out the 32k GPT4 model though and feed it more code of the architecture, this may help, but is obviously a lot of work...)

Same for humans, if your code is really too complex, you can likely simplify it, such that humans can read it without comments. If not, it falls for me in the first category I've listed (complex math or similar). And then of course comments make sense for a complex piece of code that may need more context. I would only add comments otherwise for edgecases and ideas (e.g. TODO).

For the rest a good API doc (javadoc, rustdoc etc.) is more than enough (if it's clear what a function should do and the function is written in a modular way, it should be easy to read the code IMHO.

Really if you need comments, think about the code first, is it the simplest approach? Can I make it more readable? I feel like I have written a lot of "unreadable" (or too complex) code in my junior years...

What otherwise makes sense for me is a high level description of the architecture.

I think even the second comment is not that helpful.

Just use (boolean) variables that phrase what your comment would explain, often more concise and better to read IMO. Also if the logic is more complex compose multiple named (boolean) variables. I think comments seldom make any sense at all (function doc is a one of the rare cases, mostly for the user of the library in the IDE).

Just write your code, so that you (almost) don't need comments (i.e. simple to read). The problems with (most) comments won't be solved by AI.

(in-code) comments only make sense for me in roughly these scenarios:

• complex piece of math possibly from a paper (e.g. a ref to the paper where it is explained)
• function doc, here AI may really help at some time (right now, I'll rather write it myself, AI represents this post very well in an even more verbose and literate way than the typical junior dev...)

The problems with comments are explained well IMHO here: https://www.youtube.com/watch?v=Bf7vDBBOBUA

It really depends. Maybe developing something like a game will require (almost) no CLI.

But do a little bit more server stuff, dev-ops, and you can literally not even do the job without cli.

Though in general, CLI is often better for the task, it often can easily be automated (via scripts etc.), which seems to be relevant for a lot of tasks programmers do...

All good, well maybe not exactly the issue: https://github.com/LemmyNet/lemmy/issues/3580 (maybe you find something else there, otherwise, just open an issue there)

Also just discovered via this, that there's already a "Show Read Posts" setting in the settings

Pretty sure, that there's already a github issue on lemmy itself (too lazy currently to search it though)

I don't think this will be a very big issue for the majority of the cases though. As long as it's configurable and not a (very) controversial change. Especially, since I don't think that feature requests on a programming focused community will be that much controversial...

What I have observed so far: I think the maintainers are relatively open to changes (compared to a few other open source repos).

Is this a hard error? Like it doesn't compile at all?

Isn't there something like #[allow(unused)] in Rust you can put over the declaration?

Is it good technically though? Or is it just really popular because it's so well maintained and extensible?

I think the main reason vscode is so popular is, because there aren't really good native alternatives (e.g. I wouldn't compare e.g. vim because it's kind of a different target audience).

So maybe something like zed or so will take the reign of this class of editors, but we'll see, I just hope it's not yet another electron or DOM based editor, DOM is bad enough in the web already...

So cancer + a different form of cancer = ...?

I really don't get why you want an editor to be based on DOM, it feels just like sluggish ... cancer...

Hmm pretty sure, it's not vim, as that would be u and C-r

(Nor anything else...)

I probably wouldn't see it that negative TBH. I'm often finding interesting content for whatever problem or interest I'm currently having via google (SO and yes reddit has also quite a lot to offer from the community). I rarely click anything that looks too profit-oriented and fortunately those pages although are on the first page, often aren't the first search result.

SEO got a little bit smarter nowadays, sure it's still a game with the search, but modern SEO is more focused on information and site design (e.g. does it display on mobile correctly?) etc. AFAIK.

Good that the Fediverse is just on the rise while these platforms are self-destructing (hopefully).

But how do you find a website and the relevant content then?

I agree, that you should have a good search on a platform, specifically optimized on the scope of that platform, but it's just an unfortunate truth, that google is often better than these individual searches.

SEO could also just mean that all the stuff is actually server side rendered, so that google is able to find the content (which is not the case yet for lemmy-ui, but there is lemmy-ui-leptos in development, which should support that at someday)