Zangoose

joined 1 year ago
[โ€“] [email protected] 8 points 7 months ago

For anyone else confused: in this case NLP stands for "Network location provider," not "natural language processing"

[โ€“] [email protected] 6 points 7 months ago

I love not having downvotes federated ๐Ÿ˜Ž

[โ€“] [email protected] 2 points 7 months ago

Thanks for the explanation! I didn't realize it was mostly a maintenance limitation, I thought maybe 32-bit instructions could be an extra attack vector on a physical CPU instruction level or something like that.

[โ€“] [email protected] 1 points 7 months ago (3 children)

Isn't supporting 32-bit apps on a 64-bit OS a security concern though? I thought that's why some linux distros were disabling 32-bit repositories by default on their 64-bit versions

[โ€“] [email protected] 0 points 7 months ago (1 children)

Sorry for being unclear, I wasn't trying to say language doesn't make a difference (e.g. static vs. dynamic typing would make a big difference). I also personally like the error handling of rust a lot more, even if it does take a bit getting used to when my education has mostly been in languages with Java-style exception handling.

I mostly meant that the language-level performance and features aren't necessarily holding the codebase back in a debate between Java and Rust for a lemmy-like REST API. As long as the developers are aware of the pitfalls of Java (null, mutation, error-handling, etc.), it's possible to have good code.

I just think that from a maintainability standpoint, a Java-style codebase is much easier for most people to read, understand, and maintain because that's what most people are familiar with. Especially when many of the developers are volunteer contributors, that type of thing could make a big difference.

The main problem with Rust is that it's only starting to get adoption now, it isn't taught in most education curriculums, and it's industry use is pretty small at the moment. It's kind of a catch-22, because rust adoption won't increase unless large projects like lemmy exist. But that's also why I think having more options is also fine. Sublinks might get more developers short term because of its language, but that also doesn't mean it'll completely replace Lemmy. Both projects can exist at the same time, and hopefully benefit from each other's development.

[โ€“] [email protected] 0 points 7 months ago (3 children)

A lot of people here seem to think that Java code is awful and disgusting and no projects should ever use it. The thing about popular languages is that more code existing in a language inevitably means a lot of it ends up being bad. The same thing will likely happen to rust as it gets popular, but that isn't exactly a problem. It's possible to have a well-maintained Java codebase.

Debate between functionality of the actual programming languages at this point is pretty meaningless, if they have good development standards then a Java program could end up just as well maintained as rust. Any time saved by compiler enforcement of specific standards (like no using null) would be lost by the fact that the devs don't know rust tooling. You could just have a requirement in PRs that null isn't used. Both Java and Rust have usable frameworks for REST API development, so using one or the other comes down to familiarity.

The idea that programming languages make code suddenly good or bad is pretty silly. Different languages have different language-level guarantees which can help produce good or working code. That being said, it's not like it's impossible to write good Java code, just like it's not impossible to write bad rust code. Most people seem to be conflating guaranteed functionality and safety with maintainability, stability, and readability. Rust is still a new language, so although it's great, Java will probably be the better choice for the latter 3 qualities.

That being said, something like Kotlin would probably have been a better starting point since it can interact with Java (and works like Java in most cases) but also has some nice improvements like stricter null checking (Kotlin nulls are treated similarly to rust's Option<T>, it's just described as T? instead and the syntax is generally a lot more concise). There's also the benefit of being able to write some code in Kotlin and some in Java since they are mostly cross-compatible.

[โ€“] [email protected] 0 points 7 months ago* (last edited 7 months ago) (5 children)

I think they mentioned in another comment, but sublinks is developed in Java, so the .world team would be able to contribute more to the actual development/testing process (edit: since they aren't familiar with rust).

[โ€“] [email protected] 2 points 7 months ago (1 children)

I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically

[โ€“] [email protected] 1 points 7 months ago* (last edited 7 months ago)

yes, I haven't tried AptX low latency headphones (tbf those are incredibly uncommon) but every pair of Bluetooth earbuds/iems/headphones I've tried had a noticeable delay. If you want good latency you need to get 2.4ghz or ideally just a wire.

[โ€“] [email protected] 12 points 8 months ago* (last edited 8 months ago) (1 children)

Java is reasonably fast though, as the JRE is pretty well optimized at this point. Languages closer to being fully interpreted like JS and Python (technically both python and JS still get compiled to a lower target and then interpreted) are still noticeably slower.

Edit: there's also the fact that JS/TS runs on a single thread, so it's inherently limited for applications intended to be scaled up.

[โ€“] [email protected] 3 points 8 months ago (1 children)

If you're actually being serious, this is Gabe Newell, the CEO of Valve. If you're joking, internet sarcasm is hard :(

[โ€“] [email protected] 2 points 8 months ago

I think Boston got less snow than that image this entire winter season :(

Global warming go brrrr

view more: โ€น prev next โ€บ