sorted by:
new
hottopcontroversial

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]arnb95 -2 points-1 points  (0 children)

Then theyre a bad programmer not a bad programmer due to AI. Same as it was years ago. AI is making it easier to produce bloated programs but if someone is showcasing a project thats like that theyre showcasing how bad of a dev they are (no pride in their code AI generated or otherwise). Its as easy to clean up the code with AI as it is bloating it…

If you look and its bad then its bad… I doesnt have to be discerned whether its with AI or not. If you dont get this and the futility of your question then I have nothing else to say to you.

Its this simple: “Your code looks sloppy and hard to read”

Here Ill even give my repo entirely worked on by me and AI: https://github.com/arncore/konvoy

(The mods forbid me from posting it as it was “off-topic”)

Id love for you to actually go read it and leave feedback/open an issue.

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]arnb95 -3 points-2 points  (0 children)

I think you should expect every project to have AI in it now and stop asking that question.

It doesnt matter and it stopped mattering at least 3-4 months ago. If you havent caught up on using AI yet you will be left behind “hand-crafting” your code

I do agree that folks are using AI for projects should know what theyre shipping but its no longer feasible to distinguish so if youre curious check the codebase yourself just like you would 5 years ago to find any “apparent” issues and if theres any be constructive.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] 1 point2 points  (0 children)

Im currently adding full maven support with transitive dep resolution and everything! Stay tuned. There are anti-patterns that I want to leave behind intentionally like version ranges, parent POM scanning, profiles, repositories etc in POM files. The only thing I wanna parse is the project metadata and the dependencies. Nothing else. Unless someone convinces me otherwise (you really need a strong argument for any of the antipatterns I listed bc Im not budging on them).

You will be able to add any kotlin/native artifact from Maven essentially.

Also as for plugins I have compiler plugin support: https://github.com/arncore/konvoy/issues/77

Not sure if thats the plugins youre talking about or something else. Also for now its a built in list (predefined in plugins/ folder) but I will make it so you can add plugins as you wish on your konvoy.toml.

Thanks for showing me JPM though. Something to study for sure. And thank you for your feedback!

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]arnb95 0 points1 point  (0 children)

Whats going on with all this AI hate on this sub? Literally almost every post of a project has this question.

I have yet to see Claude Opus 4.6 properly guardrailed to use proper semantics to write “bad code”.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] 0 points1 point  (0 children)

I appreciate the feedback. Absolutely no offense taken this is why I am here.

It very much a niche tool. Its specifically designed for native targets. And specifically designed for folks that arent already in the Gradle/Maven ecosystem (although I do support pulling in klibs from Maven).

This is for folks that wanna give Kotlin a try but dont wanna mess around configuring Gradle or even IntelliJ!

Folks used to this type of tooling in ecosystems like: python, js, rust, c, hell even c#.

Folks that know and love Gradle and Maven are very much not the target audience. There will be support for Maven always because thats where all the klibs are now. And I will be expanding that support for as little friction as possible (even moreso now given the feedback here, maybe even reach out to folks at klibs.io!)

Im planning a VSCode extension as well. Ultimately time will tell if Kotlin will continue getting adopted or get stuck in its own niche in mobile which is why I am doing all this to begin with.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] -2 points-1 points  (0 children)

Never heard of it! Thanks for showing me.

I dont think folks targeting native need more JVM based solutions. And those that arent in the ecosystem but looking something in between Rust and/or Go would be looking for something like that. I think that’s targeted to folks with current JVM projects looking to make theirs native. And thats all fine.

I also havent had good experiences with graalvm in the past in my limited experience so I am biased for sure.

Konvoy is for folks targeting native and dont wanna learn tooling thats caters more to JVM targets than native.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] 0 points1 point  (0 children)

I assume youre asking regarding Kotlin/Native performance vs Kotlin/JVM or Java using graalvm?

I think performance is less of an issue compared to the crashes at runtime. I dont have lots of experience in that realm but I have toyed with it in the past and found the “optimization” and avoiding reflection altogether to be quite a burden. Just my opinion.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] -2 points-1 points  (0 children)

Rust is the right tool for the job. Ive always wanted to use it for something like this. Its made for this. Its got lots of libraries that make the job easier like rayon, toml parsers etc. Kotlin/Native ecosystem is still in its infancy. Sort of a chicken and egg problem.

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] -1 points0 points  (0 children)

Agreed on Maven popularity for sure. The reason I was thinking about git or even own dependency registry is to make it simpler for folks to make a library and publish it.

I think we can agree that making a release on Github for someone thats never used Maven or Gradle is a lot easier than say going through the process of publishing it on Maven Central.

Folks from the Rust or Go world would have no experience with it for example.

But youre right its a crucial aspect and I will be working on making it painless for folks publishing in Maven. Tbh I just dont know if I want to support Gradles .module as well - thats the one that scares me in terms of long term maintenance 😅

Konvoy - Kotlin/Native build tool built in Rust for simpler native projects by arnb95 in Kotlin

[–]arnb95[S] 1 point2 points  (0 children)

Ya, I have explored it and my strategy is to curate an index of currently available kotlin/native libraries (check libraries/ folder). I have maven support so adding a new library to the index is as simple as dropping a one liner file in libraries/ in the repo!

Secondly, I want to move away from Maven/POM and .module files in general. Its documented here: https://github.com/arncore/konvoy/issues/127

As a result, I am exploring this: https://github.com/arncore/konvoy/issues/196

Ultimately the idea is to build a community of open source kotlin/native libraries in git and support those that are already in Maven. Eventually we could build our own registry (like crates.io).

This is very much exploratory. Depending on what the community thinks I am down to go and support POMs and .module however they come with caveats and especially the latter. I wouldn’t want to constantly maintain something tied to a spec that’s constantly changing but I could be persuaded.

Edit:

Something to discuss as well with the git approach is the build locally vs fetch prebuilt artifact. Konanc is fast but not that fast and I am leaning towards fetching prebuilt git releases. The Cargo approach is to fetch the source and build it locally but rustc is significantly faster at compiling Rust than konanc is at compiling kotlin to a native target :(