#dev-general

1 messages · Page 336 of 1

onyx loom
#

ur gross

jovial warren
#

property-based injection > constructor-based injection

#

anyway, enough of that

#

what should I do?

prisma wave
surreal quarry
#

constructor injection is so easy

#

especially in kotlin

prisma wave
jovial warren
jovial warren
#

singletons are just

#

unless those singletons are Kotlin's object, in which those are amazing

surreal quarry
#

why is instantiating the class your self bad exactly?

jovial warren
surreal quarry
#

why not?

jovial warren
#

why would I be able to?

ocean quartz
#

Why don't you require plugins that to have a server as property of the constructor of the main class?

surreal quarry
#

you have an instance of the server, just pass it when you instantiate the class

ocean quartz
#

class Plugin(private val server: Server) : JavaPlugin()

prisma wave
jovial warren
#

oh right, you're saying I should instantiate it myself James, I thought you were saying it was a bad idea for me as a developer to instantiate it myself

jovial warren
#

I might just instantiate it myself tbh

surreal quarry
#

no im saying what matt is saying

jovial warren
#

might be easier

prisma wave
jovial warren
#

right, so then an initialize method or something I guess for loading plugin shit?

#

(a bit like Bukkit's onEnable)

prisma wave
#

If multithreading is a focus (which it seems to be) you should probably be strongly discouraging state and mutability

surreal quarry
#

not really, they could use the init block or constructor

prisma wave
#

^

jovial warren
#

I'm thinking that an initialize function might make more sense though

#

and then shutdown for disabling

surreal quarry
#

could you do what JDA does and have a shutdown event that they listen to

prisma wave
#

Yes

#

Reactive model much better

surreal quarry
#

why not?

prisma wave
#

You have a choice here, go with the traditional bukkit API design and accept that thread safety will be hard, or use an actual concurrency model

#

Event driven works very well

#

Reactive works well

jovial warren
#

I don't like Velocity's method of listening for events for initialisation

prisma wave
#

state machines not so much

jovial warren
#

that's not what's async

prisma wave
#

doesn't matter

jovial warren
#

it's the actual playing of the game that's all async

surreal quarry
#

still seems nicer to use events

jovial warren
#

eh, I don't like that idea tbh

surreal quarry
#

my vote is init/constructor/startup event & shutdown event, but its your project so its up to you lol

jovial warren
#

I could provide events and the method I guess

#

best of both worlds

surreal quarry
#

if you do that make it an open not abstract method por favor

jovial warren
#

one thing I definitely will provide though is heavy encapsulation and strong limits on what plugins can actually do

jovial warren
surreal quarry
#

yea that works

#

why limit what plugins can do?

prisma wave
jovial warren
#

like none of the plugin management or loading should be visible in the API

surreal quarry
#

oh yea

jovial warren
#

e.g. in Bukkit, you can call Bukkit.getPluginManager().disablePlugin(anyPluginInstance)

surreal quarry
#

i guess i will just need to use reflection in order to take over servers

jovial warren
#

lol

#

the way I want this to work though, your plugin won't have any idea if any other plugins actually exist on the server

#

actually that might be a bad idea for dependencies

hot hull
#

would fuck dependencies yea

jovial warren
#

but maybe I can do that another way

surreal quarry
#

you can expose parts of the process so things like dependencies can work and then just make other parts like disabling plugins internal

jovial warren
#

or just make an interface that contains things like the list of plugins that exist maybe, but then do enabling and disabling on the backend

#

so plugins can't do any whacky reflection to access those methods at all

#

and if they want to access them, they've gotta depend on the backend

surreal quarry
#

reflection would still give you access to the backend tho?

jovial warren
#

eh, true I guess

#

if you did some whack

prisma wave
#

Trying to stop reflection is dumb

surreal quarry
#

^^

jovial warren
#

yeah I shouldn't try to stop reflection

prisma wave
#

I've seen a few people building their programs around that philosophy

#

It's stupid

#

Reflection literally exists to bypass restrictions when necessary

jovial warren
#

I just want to make it clear that enabling and disabling plugins should be avoided, and I can put across that message by putting it on the backend

surreal quarry
#

i just expose the stuff i thing they need, but if they want to use reflection and potentially fuck something up thats up to them

prisma wave
#

Exactly

surreal quarry
#

just don't expose the enable/disable stuff

jovial warren
#

yeah that'll be on the backend

surreal quarry
#

if someone chooses to use reflection to do it and they fuck something up thats on them

jovial warren
#

also, @JvmName is gonna be my best friend and my worst enemy

surreal quarry
#

i feel like kotlin does a good job of that in most cases already

prisma wave
#

if you're using coroutines anywhere in the API you can already forget about interop

jovial warren
#

yeah I'm not

#

just on the backend I think

ocean quartz
#

Does coroutines not work well with Java?

prisma wave
#

Not at all

jovial warren
#

coroutines don't work at all with Java

prisma wave
#

Not in the slightest

jovial warren
#

especially because of suspend

prisma wave
#

Seems an odd decision

jovial warren
#

¯_(ツ)_/¯

surreal quarry
#

honestly if i were you I would say fuck interop and just make it a great kotlin api that suspends and does whatever it needs to do for performance

prisma wave
#

Mhm

jovial warren
#

as long as I call them from a coroutine context then all is well

prisma wave
#

bruh

jovial warren
#

actually maybe just saying "fuck you Java" is a good idea

prisma wave
#

why would you not make them suspending is the question

jovial warren
#

literally the only possible reason would be Java interop

#

but fuck that

surreal quarry
#

if they want to make plugins they can learn a superior language

prisma wave
#

Plugins in clojure yeah

surreal quarry
#

it deadass takes like 2 days if you know java

prisma wave
#

That would be great

ocean quartz
#

From the java POV such a library would just look like normal bytecode with callbacks and some method calls to kotlinx.coroutines library classes. So no different than any other asynchronous technique –
Wouldn't this be the same for plugins?

jovial warren
#

I mean, I don't think lucko will mind lol

prisma wave
#

Which makes them pretty much impossible to call from java

#

Unless you somehow generate your own Continuation

unkempt tangle
#

Senpai

jovial warren
#

also, what would I even make suspending?

surreal quarry
#

something that suspends

#

usually

jovial warren
ocean quartz
#

Yeah but what I mean is that a coroutine based server would call java code, that could would be run async in theory
The issue is when Java itself tries to use it, but since the server would be the one calling the plugin i don't think there'd be an issue

jovial warren
#

maybe commands should be fully async

#

that sounds like a good idea

surreal quarry
#

from my experience if you make one thing suspending, you make everything suspending

jovial warren
#

commands can be async if there is nothing we need to call sync, which in how I want to design Krypton, there shouldn't be

surreal quarry
#

suspend class Server

#

ez

#

whole server suspending

jovial warren
#

if only

ocean quartz
#

If you suspend the whole server then nothing would be async thonking

prisma wave
#

suspending does not mean async

jovial warren
#

^

#

in fact, suspending means the complete opposite

#

the way you write coroutines is in a blocking way

#

you write code as if it's going to block (suspending functions) and then execute it in a place where it doesn't block (coroutine scope)

#

but coroutines are weird

prisma wave
#

Which is also untrue

jovial warren
#

true

lunar cypress
#

this is a bit misleading

#

because the idea of coroutines is precisely to not have blocking code that just runs in a different thread

jovial warren
#

your turn it is then I guess

lunar cypress
#

In essence, coroutines are callback-hell generated for you

jovial warren
#

lol

prisma wave
#

Mhm

jovial warren
#

also, instead of the method names addPermission and removePermission, I was thinking of using the names grant and revoke

#

e.g. sender.grant("some.permission")

#

or sender.revoke("some.other.permission")

#

oh also, I'm debating whether to use an Array<out String> or a List<String> for command arguments

prisma wave
#

It makes 0 difference

#

out on a final class 🤨

jovial warren
#

is Array final?

#

didn't know that

prisma wave
#

String is

#

And yes

#

Array is too

jovial warren
#

alright, anyway, list it is then

#

means I don't have to use any iterator bull shit

prisma wave
#

?

jovial warren
#

with arrays in Kotlin, they don't have all the same functions that Iterables do

#

so you have to use an Iterator and Sequences if you want to not have arrow code and access those methods

prisma wave
#

What

jovial warren
#

I mean, maybe that's just me, but ya know

#

¯_(ツ)_/¯

#

anyway, we using a list

ocean quartz
#

That's horrible

jovial warren
prisma wave
#

that's for "traditional" CLI

#

rather than something like kick [Player] [reason]

#

it could probably work

#

but isnt great

jovial warren
#

that's not what I was on about

#

read what I said again

prisma wave
#

Then yes it's fine

jovial warren
#

oh also, should CommandSender have access to the Server like Bukkit's does?

#

that sounds unnecessary tbh

prisma wave
#

?

jovial warren
#

what

prisma wave
#

"have access"

#

like access control?

jovial warren
#

I mean should it have a value in it that allows you to retrieve the server

#

which is why I said it was useless

obtuse gale
#

what are you talking about

astral quiver
#

Lost the talk about Koin :c

#

Koin is just great, works pretty well

#

In fact, I need to add some extensions in KotlinBukkitAPI to better support Koin

prisma wave
#

koin is despicable

#

in fact

astral quiver
#

😠

prisma wave
#

most libraries in the kotlin ecosystem are

#

don't @ me

astral quiver
#

What is your recommendation instead of Koin for DI?

#

Dagger2 is bullshit, Google DI also, Spring also

prisma wave
#

Personally I'd much rather use guice

astral quiver
#

Google DI = Guice

prisma wave
#

ik

astral quiver
#

same shit

prisma wave
#

Nothing wrong with Guice

jovial warren
#

Koin superior

astral quiver
#

Yes, Koin is superior

#

even Kodein is superior

prisma wave
#

people in the kotlin ecosystem have an obsession with reinventing the wheel to be more "idiomatic", even though it usually ends up worse

#

koin is utter trash

jovial warren
#

you're utter trash

astral quiver
#

well, I don't see where Koin is worse

jovial warren
prisma wave
#

no it's not

astral quiver
#

Here on my job, we use Dagger2, Koin and Kodein

jovial warren
#

make something that's easier and nicer to use than Java is

#

and has some cool features on the side (coroutines, time, etc.)

astral quiver
prisma wave
#

there is a difference between making an alternative to something to fix flaws, and "fixing" something that isn't broken

jovial warren
#

okay, I cannot stand "if it's not broken, don't fix it"

astral quiver
#

Okay, Gson vs Kotlinx.serialization

#

I say that Kotlin libraries are trash

prisma wave
#

both are fine

astral quiver
#

what you thnking about ktxserialization

prisma wave
#

the only thing ktx does better is multiple languages

jovial warren
#

kotlinx.serialization superior though because it's more idiomatic

prisma wave
#

buzzword

#

meaningless

jovial warren
#

stfu

prisma wave
#

how exactly is it more idiomatic

#

aside from having a dsl in some parts of the API

jovial warren
#

actually, maybe idiomatic isn't the word

#

just being able to have serialisers be auto-generated for objects instead of having to write them yourself is amazing

prisma wave
#

?

astral quiver
#

ktx serialization just work with Kotlin, Gson, doesnot

jovial warren
#

and taking out reflection

astral quiver
#

samething about Guice

prisma wave
jovial warren
#

actually yeah Gson does a similar thing

astral quiver
#

you can use in Kotlin? chore, but I will lost a bunch of features

prisma wave
astral quiver
#

Generic type for example

#

Kotlin just works

jovial warren
#

also, working with Kotlin libraries in Kotlin is generally better than working with Java libraries in Kotlin, as Kotlin libraries are (surprise surprise) made for Kotlin, and Java libraries are (again, surprise surprise) made for Java

astral quiver
#

you can have like a DI of Something<String> and Something<Int> and they are different

jovial warren
#

I find anyway

astral quiver
#

try to do that with Java

prisma wave
astral quiver
#

You can do this by passing DI Tags all over the place

#

but, does easy, no

#

There is alot of features that Java libraries simple can't support

jovial warren
#

and a lot of them aren't designed in a way that really works well for Kotlin either

#

or at least, not as well as a Kotlin library generally is

astral quiver
#

There is alot of libraries build in kotlin that have a big advance in beeing kotlin

#

not just for idiomatic

#

performance reason

jovial warren
#

e.g. OkHttp 4 is so much better to use than OkHttp 3

astral quiver
#

like Jetpack Compose or any library that use lambdas functions in inline modifier in kotlin

#

Jetpack Compose use ALOT inline classes to avoid memory allocation

jovial warren
#

e.g. MediaType.get("application/json") vs "application/json".toMediaType()

#

I hate having to call utility methods in Kotlin

#

it's just not the way it's meant to be

prisma wave
jovial warren
#

yeah but one is more idiomatic

#

and looks nicer imo

astral quiver
#

You can forget all the kotlin only features, is not fair with any Java library, you can put just the features that the usage in code is exacly the same, but the performance is better

#

also, Java libraries are massive and confusing

jovial warren
#

because Java is massive and confusing

astral quiver
#

try for example Maven Aether

#

No good documentation, you will only learn from github projects that uses this shit

#

and Maven Aether is the most "Java" library that I can think (because I don't use java for long time and do not suffer anymore ❤️ )

prisma wave
#

god the circlejerk

#

i thought i was bad lmao

jovial warren
#

lol

#

Kotlin good Java bad

#

that's just a fact around here

#

it's not even a matter of opinion in this channel lol

astral quiver
#

Is not just a fact, Java is still in Java 8

#

There is alot of people still using Java 8

jovial warren
#

I mean, can't really say the language is bad because idiots decide that using legacy versions is a good idea

#

it's like saying Minecraft is bad because most people still use 1.8

prisma wave
astral quiver
#

Kotlin is developed by a company that knows all languages mainstream in the world

#

they do the best tooling for a bunch of languages

#

they know what they are doing

#

this is the fact about kotlin

jovial warren
#

Kotlin is only good because it had dozens of examples of what not to do lol

prisma wave
#

jesus

#

i know what kotlin is

astral quiver
prisma wave
#

i am not talking about the language

#

i am talking about a few prevalent libraries in the ecosystem

jovial warren
#

yeah BM thinks Kotlin superior to Java at least I think

prisma wave
#

namely Koin and Ktor

jovial warren
#

Ktor's DSL-based system is beautiful

astral quiver
#

But you say that "Kotlin libraries are despicable"

prisma wave
jovial warren
#

it's so idiomatic

#

maybe about level by 16?

prisma wave
#

with a bit of hyperbole

jovial warren
#

Kotlin is superior to Java 11 too

astral quiver
#

Java 14 too

jovial warren
#

maybe level with 16, but that's about all I'll give you BM

astral quiver
#

where is the Extension function, a really good Functional type system

#

to finish it

jovial warren
#

maybe that will be added to 17 lol

astral quiver
#

Where is Jetpack Compose?

jovial warren
#

then Java will start to look more like C#

astral quiver
#

Where is Fiber?

prisma wave
#

Java doesn't want extension functions

jovial warren
#

true

astral quiver
#

Why they don't?

#

All currently languages are adding it

jovial warren
#

probably "not the Java way"

astral quiver
#

Dart, Swift

prisma wave
#

they've already addressed this

prisma wave
jovial warren
#

I mean, I don't think extension functions really fit into Java tbh either

prisma wave
#

exactly

astral quiver
#

with the Kotlin design, no

#

but the concept, fits

prisma wave
#

and again, im not really talking about the language here

#

i have no problem with either language

#

i have a problem with the kotlin ecosystem's obsession with reinventing the wheel in a shitty way, adding a few 💫 idiomatic 💫 DSLs for configuration, and calling it a better library

astral quiver
#

also, about the reinventing the wheel, you are right if the Kotlin and Java was not complete different

prisma wave
#

huh?

jovial warren
#

okay, maybe not better

#

but Guice vs Koin is like comparing apples to oranges

#

it's personal preference imo

hot hull
#

So you don't like mangoes is what you're saying

prisma wave
#

Field injection sucks

jovial warren
#

it's two completely different ways of doing dependency injection

jovial warren
prisma wave
#

constructor injection is literally the only way you should be doing it

#

no

jovial warren
#

I personally don't mind it

#

it just feels like "the Kotlin way" to me

astral quiver
#

I only do constructor injection with Koin

prisma wave
#

field injection is pretty much an anti-pattern by now

jovial warren
prisma wave
#

for the same reason static getters are bad

astral quiver
#

also, Dagger does the same

#

and it a Java library

prisma wave
#

guice supports it too

#

but afaik dagger and Guice both heavily encourage constructor injection instead

astral quiver
jovial warren
#

ah yeah, that'll work

#

I mean, one thing I do like about Koin is just how stupidly lightweight it is

astral quiver
#

About Ktor

#

there is a reason why kotlin does this

#

reinventing the wheel

#

Kotlin is multiplatform

jovial warren
#

Koin: 143 KB
Guice: 755 KB

prisma wave
astral quiver
#

Kotlin should give you the ability to use anything from any platform, but it also should give you a way to do this for all platforms

jovial warren
#

yeah there's no whacky reflection or classpath scanning afaik

prisma wave
#

guice doesn't do classpath scanning

jovial warren
#

just reflection then

prisma wave
#

it doesn't even do reflection afaik

#

It uses ASM to make a factory class

jovial warren
#

also, don't you have to configure Guice?

prisma wave
#

Uh

#

How so

jovial warren
#

I remember Piggy saying something about you having to make some configuration classes or something

prisma wave
#

Modules?

jovial warren
#

that'll be the one

#

I mean, I haven't a clue how Guice works since I've literally never used it ever, so I'm just curious

#

also, someone please tell me the difference between plus and unaryPlus

prisma wave
prisma wave
astral quiver
#

maybe your problem is with libraries with much Kotlin features?

jovial warren
astral quiver
#

maybe is because you still are using alot of java

jovial warren
#

and F#

astral quiver
#

ohgod 👀

jovial warren
#

I mean, Haskell is actually really nice

#

not sure about Clojure, it doesn't look pretty but it's a decent language I think

#

and F#, can't comment at all on that

astral quiver
#

lisp MinusOne

jovial warren
#

Haskell's pattern matching makes a when expression look like something out of the 80's

astral quiver
#

Do you folks want ternary operator in Kotlin?

jovial warren
#

eh, I do fine without it

#

single line if/else statements mostly do the job

astral quiver
#

same thing I think about Haskell or any language pattern matching comparing with Kotlin

lunar cypress
#

Kotlin has baby level pattern matching

jovial warren
#

as I said, Haskell's pattern matching makes a when expression look like something out of the 80's lol

lunar cypress
#

Which is funny, considering, Haskell

astral quiver
#

when have alot of feathres that I never use

#

for example, range matching

lunar cypress
#

It has a specific range pattern? Isn't that just the normal in?

oblique heath
#

hello humans

astral quiver
#

for numbers, I mean

#

when(x) {
1..10 -> ......
}

lunar cypress
#

is that a thing?

#

no, you do mean the regular in pattern I believe

#

It would be indistinguishable from value patterns otherwise

jovial warren
#

also, should I make getPlayer the method to retrieve players by name and UUID?

#

but, ya know, putting get in a function name in Kotlin just feels a bit... out of place

astral quiver
#

about pattern matching, for a scientist studding languages, sure, is "useful" but seeing the cases where pattern matching in Scala is use the most, is where kotlin already supports with when, my point is that is clear that the Kotlin team is not building a language with alot of feature, they are build a language with useful features, that you will use all the time

#

I kinda miss some features in kotlin, but I don't have any feature that I don't use

#

and comparing with like Java, Kotlin has alot more features

#

you I just use it all

#

This is why Haskell is cool but is not usage in the industry

lunar cypress
#

haskell sure isn't a language rooted in pragmatism like kotlin

astral quiver
#

kotlin is not just pragmatic, it is also concise, in this is important

#

bit operators show what concise to Kotlin means

jovial warren
#

bitwise operations in Kotlin are horrible compared with other languages in terms of being concise

#

there's no assignment that can be done with them either, so you have to do something like variable = variable or 1 for example, like you're in some GCSE computer science class learning Python for the first time

astral quiver
#

what was the last time that you use bitwise operations that was not for minecraft or any type of protocol handling?

lunar cypress
jovial warren
#

I mean, I can definitely say that it's more readable, but more concise? better?

astral quiver
#

in the world real, how much you will use bitwise?

jovial warren
#

actually quite a lot

lunar cypress
#

also, even though I wasn't talking about concision, most functional languages are very much concise

astral quiver
jovial warren
#

bitwise operations are what make maths algorithms fast

#

and other things

lunar cypress
astral quiver
#

if you are a CS, that will try to optimize a algorithm that also created in 90s, sure

#

in the world software world you will not use it alot

lunar cypress
#

...except when you do

astral quiver
prisma wave
#

I use them for educational purposes only, I regularly use Kotlin and Java

lunar cypress
#

that is very subjective

forest pecan
#

bitwise really is useful

#

its often overlooked

#

many algorithms actually use bitwise and are severely reliant on them

astral quiver
#

Yes, they use, but how many times you will try this algorithms ?

forest pecan
#

If you are an algorithmic student like me

#

you would understand

#

🙂

#

they are the savior from getting a 60% to a 100%

astral quiver
#

The point is, should jetbrains add this because 1% of developers uses day by day, increasing language operators, increasing compilation time?

jovial warren
#

a.k.a circlejerking

prisma wave
#

As far as I know

jovial warren
#

as I said, circlejerking lol

prisma wave
oblique heath
#

clash of clans!???!?!?!!111one!

prisma wave
#

saying FP isn't used in industry is such an outdated comment

forest pecan
#

do ppl even know what circlejerking means lmao

prisma wave
#

It hasn't been true for many years

prisma wave
forest pecan
#

ikr

#

its dirty minded

#

xD

prisma wave
#

well it doesn't really mean that anymore

forest pecan
#

yea ig

prisma wave
#

But yes

astral quiver
#

Elixir is new and shine and it is growing ALOT in the industry

prisma wave
#

As I said, Haskell is also used in industry

lunar cypress
prisma wave
#

yeah kotlin is a very syntax-y language

astral quiver
#

yes, but I use it all every day

lunar cypress
#

doubt.

obtuse gale
#

all the kotlin

prisma wave
#

i could count the times ive used crossinline on one hand

jovial warren
#

same lol

#

in fact, I wouldn't even need any hands to do it

astral quiver
#

When do you have a bunch of Java apis that you need to make it better with Kotlin Inline Function

#

you will use all the time

forest pecan
astral quiver
#

specially in android

astral quiver
#

for a Hello World project? sure

jovial warren
#

I swear Kotlin's compiler already has to do quite a lot anyway

#

since Kotlin has so many features

astral quiver
#

Kotlin's compiler is slow comparing with Java

prisma wave
#

not really

#

sometimes it can be faster than java

#

normally it's pretty close

jovial warren
#

depends on what you're compiling

#

the Kotlin compiler does have more to do though

astral quiver
#

you meant the new compiler?

#

because here with Android, is pretty close, but is not so much

#

compilation time of 30m here is normal with big apps

jovial warren
#

also, I swear you just contradicted yourself

astral quiver
#

you don't have microservice to salve you :c

forest pecan
jovial warren
#

complaining about bitwise operators increasing compile time and then saying Kotlin's compiler is slow anyway

astral quiver
#

I also not joking

jovial warren
#

even though Kotlin's bitwise functions are more readable, that does not by any means make them "better"

prisma wave
#

more readable
doubt

obtuse gale
#

More relaxed area to discuss development topics

prisma wave
#

don't

#

even

#

TRY

#

and get

#

configuration

#

help

obtuse gale
#

Not configuration help

forest pecan
#

so u are saying to take out bitwise??

astral quiver
#

language operators, YES!

obtuse gale
#

yes

lunar cypress
prisma wave
#

i cba to scroll up but im about 95% sure dedicated bitwise operators would make a negligible difference in compile times

obtuse gale
#

all of the bitwise

#

remove

#

obliterate

jovial warren
#

I think shl is more readable than <<, since I just find it easier to read shl as "shift left" rather than having to think about which direction << is shifting

prisma wave
#

yes

forest pecan
#

thats stupid?

#

lol

prisma wave
jovial warren
#

because < seems to sometimes be difficult for my eyes to read properly lol

lunar cypress
#

<< is an established operator in pretty much every other C family language

jovial warren
#

yeah ik, I'm not saying it's bad, I'm just saying that I sometimes find it difficult to remember what it means

lunar cypress
#

I've yet to see a language that uses shl as an abbreviation

obtuse gale
#

bUt MuH cOmPiLaTiOn TiMeS

#

mUh 5 nAnOsEcOnDs

astral quiver
#

also ternary operator?

lunar cypress
#

no, but because of that, there is no reason to come up with your own cluttered language for it

jovial warren
#

I think bitwise operators are vastly superior, don't get me wrong, but I'm just saying that personally, for me, shl is easier to read than <<

lunar cypress
#

you could make the same argument for && and ||

prisma wave
jovial warren
astral quiver
#

bitwise operators is superior, of course, but the point is not what is the best and "bitwise operator is a edge case operator?"

jovial warren
#

infix precedence

#

no assignment

lunar cypress
#

what benefit is there to not using the known operators

prisma wave
#

yeah that was definitely a mistake on kotlin's part i think

jovial warren
#

also, bitwise operators aren't "edge case" operators

#

they are very common and very useful operators

#

if they were in fact "edge case" operators, then C and C like languages wouldn't have dedicated symbols for them

#

especially at the lower level, bitwise operators are very common and very useful operators

astral quiver
#

if you will do low level stuff with Kotlin

#

you already doing the wrong thing

prisma wave
#

why?

#

kotlin can be low level

static zealot
#

my head hurts

forest pecan
#

Java has native methods that call native code like C and C++. You should have bitwise operators in Java. Kotlin follows Java but it is less verbose. It has this same idea of native code as well. (cause C and C++ use a lot of bitwise)

lunar cypress
#

yeah, sure, let's just write all of our network protocols in C and the JNI

forest pecan
#

Removing bitwise operating has no sense at all

lunar cypress
#

when we use kotlin

astral quiver
#

Can do low level operations in Kotlin Native, but it was never build to do that

forest pecan
#

i dont get your point

lunar cypress
#

we just pretend we'll never have to work with raw bytes

astral quiver
#

The point is that, there is language for performance

#

and Kotlin does interop with

prisma wave
#

?

forest pecan
#

uhh wot

lunar cypress
#

uh oh

half harness
#

lol

prisma wave
astral quiver
#

Kotlin is not the language that you will do low level algorithm in it

lunar cypress
#

let's just write all of our network protocols in C and the JNI
for the record: this is a joke

astral quiver
#

You will do this in Rust, C, C++

static zealot
#

does anyone have a tutorial step by step on how to upload a jar to a vps from my pc and then run it? My head hurts to much to give docker another try

forest pecan
#

algorithms can be implemented in any language?

#

you crazy?

#

my algorithms are literally in Java

#

it doesnt matter what language I use

forest pecan
#

holy shit

#

you can code the same algorithm in any language

forest pecan
#

thats the definition

#

of what an algorithm

#

literally is

#

otherwise it would be stupid

static zealot
#

so now I need to set up sftp? great 😦

astral quiver
#

so, tell me why something: Why projects like bungeecord uses JNI for compression stuff?

prisma wave
#

sftp is ssh

forest pecan
#

Because why not?

surreal quarry
#

sftp is there by default

static zealot
#

oh

surreal quarry
#

on most things

astral quiver
#

why not just write in java (and they write)

#

Why there is so many big projects in java using ALOTTTTT of binding libraries

#

for performance reasons

jovial warren
#

rsync superior

astral quiver
#

why just not write in Java?

jovial warren
#

rsync only sends differences, and supports built-in compression and other tools

forest pecan
#

You realize that an algorithm thats much better can perform 10x faster in java than compared to brute force in C

#

i dont think you understand at all

lunar cypress
#

ok, and whenever we need this sort of stuff in kotlin as a base for higher level code, we are seriously supposed to resort to the JNI every time?

forest pecan
#

^^

#

The translation also takes huge

#

of a time to ranslate

lunar cypress
#

have you ever written to the JNI? it's horrible

forest pecan
lunar cypress
#

they know it themselves

astral quiver
#

java does not have any magic

forest pecan
#

have you even done algorithms before?

#

jesus

prisma wave
heady birch
#

java has no magic.
the compiler is pretty clever though

prisma wave
#

bitwise operators: too obscure, not appropriate to the language, not used
unaryPlus: PogChamp2 🤤 🐪

heady birch
#

Not compiler, runtime, hotspot I think?

astral quiver
#

The JVM Compiler is pretty clever, but, if you say to me that Java will be 10x faster then a well writing C

forest pecan
#

I said the algorithm

#

dumbass

#

if the algorithm is smarter

#

of course it will run 10x faster

#

or even more

astral quiver
#

I'm talking about the same one

obtuse gale
#

that tells me you didn't read the message lol

prisma wave
#

blockchain can make bubble sort the fastest sorting algorithm on the planet

astral quiver
#

pick like quicksort

lunar cypress
#

the reason people turn to JNI/JNA for very specific and critical parts is that usually there are established standardised native libraries for those parts that no one can be bothered to port to the JVM

#

But, I mean, there is stuff beyond this extreme

#

It's not always so incredibly critical and highly optimised

prisma wave
#

if java is so good why isnt there the RUSt native interface

astral quiver
#

Java vs C, java will never be 10x faster with a well developed C

#

Maybe if I write in C it will

forest pecan
#

not always true

surreal quarry
#

elara will always be at least 100x faster. that is the only certainty in the world

lunar cypress
#

it is true, can't deny that

astral quiver
#

if java is so good why RUST exists?

lunar cypress
#

but it's not a reason to dismiss basic operators

prisma wave
#

we have reached peak irony

lunar cypress
#

because having to turn to the JNI every time you want to write something involving raw bytes... I think I'd shoot myself in the head

spring canyon
#

lmao

prisma wave
#

haskell native interface

astral quiver
#

JVM with Hotspot is just awesome, with a big project it will be faster the C, of course, the both developers in C and Java will make mistakes that well, Hotspot sometimes can fix it

#

but the C developer doing a stupid thing? no

prisma wave
#

public native static IO<Object> HS_putStrLn(String s) {

lunar cypress
#

I just vomited

jovial warren
prisma wave
#

haskell native inteface

astral quiver
prisma wave
#

for interacting with haskell when you want speed 🙂

lunar cypress
prisma wave
#

no way

lunar cypress
#

well, haskell has an FFI so...

#

I assume it will get very messy very quickly though

prisma wave
#

amazing

heady birch
#

((b as u32) << (c as u32)) as i32

prisma wave
#
public interface Monad<T> {
    <A, B> Monad<B> bind(Monad<A> m, Function<A, Monad<B>> function);
    <A> Monad<A> return(A a);
}
#

pragmatic

astral quiver
#

this is Arrow?

lunar cypress
#

If I had less will to live I would try JNI + haskell now

#

But I'll leave that to you

old wyvern
heady birch
old wyvern
#

Adding on from impure languages 😫

jovial warren
#
interface Monad<T> {

    fun <A, B> Monad<B> bind(m: Monad<A>, function: (A) -> Monad<B>)

    fun <A> Monad<A> return(a: A)
}
astral quiver
#

Arrow Meta is more interesting

jovial warren
#

😎

prisma wave
#

sadly

#

will not work

#

afaik

astral quiver
#

I need to go deep in FP

prisma wave
astral quiver
#

because I don't miss any thing from it

astral quiver
#

you folks saw the value class proposal?

#

immutability at the type level, finally

prisma wave
#

java had it first

astral quiver
#

with mutating

old wyvern
#

C + Haskell + Rust = Casket
Seems like a subliminal message. Dont mix the pure with the impure

#

!!!

astral quiver
#

actually, not, is not the samething

#

and Java still does not release with

#

so.... Java simple does not have

prisma wave
#

kotlin devs see a java achievenment and try to STEAL it!!

astral quiver
#

Value Classes in Java will be immutable too?

prisma wave
#

every dev sees a haskell achievement and gazes in AWE

prisma wave
#

when will we be getting type class HUH andrey??

astral quiver
#

thank god

old wyvern
astral quiver
#

I don't know C++, I don't like C++

old wyvern
#

I remember their fields being assignable in C++

#

so maybe

#

Because Java already got records

#

for immutable data

astral quiver
lunar cypress
#

In java's case, value types are more than just language level constructs

astral quiver
astral quiver
#

when is not targeting JVM of course

prisma wave
#

every body gangster until interface Functor<T> gets added

lunar cypress
heady birch
#

modifier pubfin extends final, public {
}

class MyClassWithFinalProperties {
//implicitly final!
pubfin String myPublicFinalString;
}

forest pecan
#

discord has brainfuck for code formatting

lunar cypress
old wyvern
#

They just exist on the stack, that doesnt mean they have to be immutable I think

astral quiver
old wyvern
astral quiver
#

Value Classes at JVM Level will be just fucking great

lunar cypress
#

does this arrow stuff have proper documentation?

#

not just overview articles and talks

surreal quarry
#

i would hope so lmao

lunar cypress
#

I'm having trouble finding it

astral quiver
prisma wave
#

WHIPPIng the dead horse

lunar cypress
astral quiver
#

Just choose what you want to learn

lunar cypress
#

for example, it doesn't let me select the meta module and a tutorial type at the same time

astral quiver
#

core, fx, optics, meta

lunar cypress
#

just 4Head

#

the website literally doesn't work properly for me

astral quiver
#

oh

lunar cypress
#

thanks

lunar cypress
#

so you're telling me haskell is academic shit but when kotlin does it it's cool?

prisma wave
#

kotlin users alergic to parentheses... find a cure for cancer "DOES IT HAVE A DSL????"... no

prisma wave
#

havent you heard the news? kotlin good, every other language bad

onyx loom
#

breaking news

lunar cypress
#
fun nextTalkCity(speaker: Speaker): Task<City> {
    return
        speaker
        .nextTalk()         .execute().then { x -> x
        .getConference()   }.execute().then { x -> x
        .getCity()         }
}
```ok call me biased but I've never seen this
prisma wave
#

what the

astral quiver
prisma wave
#

wait...

#

is that supposed to be a

#

=?

lunar cypress
#

yep

prisma wave
#

dear god

lunar cypress
#
interface Monad<F>: Applicative<F>, Functor<F>, Selective<F> {
    fun <A> just (instance: A): Kind<F, A> // this comes from [Applicative] interface

    fun <A, B> Kind<F, A>.flatMap(f: (A) ->  Kind<F, B>) : Kind<F, B>
}```
prisma wave
#

oh my god

#

why do people do this to themselves

astral quiver
#

This is why I don't like Arrow

lunar cypress
#

well why not

astral quiver
#

just add boilerplate to code

prisma wave
#

huh?

#

that's despicable, sure, but i wouldnt call it boilerplate

lunar cypress
#

Don’t be afraid of the “M-word” just because you are a Kotlin programmer.

#

I find this interesting, honestly

ocean quartz
#

What is the m-word? xD

lunar cypress
#

building an ml-like type system in kotlin must be very hard

#

m*nad

ocean quartz
#

Oh!

static zealot
#

monad ?

old wyvern
#

shhh

prisma wave
#

😱

old wyvern
#

Also, there was an article about function composition in kotlin

prisma wave
#

hmmm

old wyvern
#

but there was pretty much a compose function for every arity tho xD

prisma wave
#

😬

#

And they say kotlin is multi-paradigm

jovial warren
#

not really sure if functional programming fits in Kotlin tbh

lunar cypress
#

half of kotlin is inspired by functional programming

jovial warren
#

or at least, Arrow's functional programming

half harness
#

is companion object the same thing as static?

#

(in kotlin)

jovial warren
#

not really

#

it is and it isn't

half harness
#

what is the difference?

jovial warren
#

an object is basically a singleton

lunar cypress
#

It becomes a class the enclosing class keeps a singleton reference of

jovial warren
#

^

#

the best way to understand how Kotlin actually works is to click on tools -> Kotlin -> show Kotlin bytecode and decompile

half harness
#

oh

jovial warren
#

that will decompile bytecode generated by Kotlin to Java code

#

also, someone help with plugins pls

half harness
#

also

#

quick question

#

is server -> client = clientbound or serverbound? 😂

jovial warren
#

we've been over this

forest pecan
#

clientbound -> client

half harness
#

ik

jovial warren
#

which direction does the arrow point to

half harness
#

but i forgot

forest pecan
#

serverbound -> server

jovial warren
#

what does the arrow point to

half harness
jovial warren
#

does it point to the client or the server?

half harness
#

client

jovial warren
#

well then it's clientbound

#

because it's bound to the client

half harness
#

alr

#

thx

jovial warren
#

also, someone help with plugins pls

half harness
#

?

jovial warren
#

I wanna have a Plugin class, but no idea how to DI the server, folder and logger without loading the plugin within the API

#

and anyone who thinks I should use annotations, here's the door: 🚪

half harness
#

static 🙂

ocean quartz
#

Use the door

half harness
#

🚪

jovial warren
#

dkim leave

half harness
#

👋

jovial warren
#

thank fuck for that

#

about time

#

xD

#

I'm messing ofc lol

ocean quartz
#

You don't like the idea of requiring the plugin to have the server in the constructor?

jovial warren
#

but that looks a bit ugly and increases boilerplate, especially if you have to DI the server, folder and logger every. god. damn. time you make a plugin

prisma wave
#

plugin doesnt need a logger

#

leave that up to the caller

jovial warren
#

I want plugins to be able to log things

half harness
#

why not like Bukkit.getLogger()

jovial warren
#

just like in Bukkit, Bungee, Sponge, Velocity, just about any Minecraft API

#

but this logger will use SLF4J instead of Java's built-in logger, because SLF4J superior

prisma wave
jovial warren
#

wdym the caller?

prisma wave
#

each plugin

jovial warren
#

I think I misinterpreted you

#

ah right

prisma wave
#

to decide what logger they use and how they obtain it

lunar cypress
jovial warren
#

so they can choose whether to DI that or not?

#

ah right

#

so by using LoggerFactory.getLogger themselves or what?

lunar cypress
#

you should definitely include some predefined way to get a logger

prisma wave
#

you probably dont need to inject it at all

jovial warren
prisma wave
#

yeah just make a property with a default value

jovial warren
#

also is it just me or can md_5 not code

prisma wave
#

md_5 is dumb

#

uses lombok

jovial warren
#

allman, if ( statement ), Lombok

#

wtf

#

thinks Gradle is bad because it's imperative (which is kinda BS)

prisma wave
#

allman good

jovial warren
#

wait what

jovial warren
#

he said this once:

Imperative vs Declarative
A build system should be the latter, therefore Maven wins

Also Maven is almost always faster at actually building than Gradle

lunar cypress
#

A build system should be the latter, therefore Maven wins
I mean gradle is declarative

#

Also Maven is almost always faster at actually building than Gradle
this is just plain wrong lol

jovial warren
#

md_5 has about 3 brain cells on a good day

#

(Also Gradle is almost invariably slower at actually building).

This was his actual quote

lunar cypress
#

Source(s): Dude trust me

jovial warren
#

gotta love the wise potato lol

#

"It came from @md_5 ... that's enough of a benchmark. "

lunar cypress
#

I'm still pondering at "Gradle is imperative"

jovial warren
#

val logger = LoggerFactory.getLogger(SomeClass::class.java)?

ocean quartz
prisma wave
#

Probably there is that you can't override it with a different logger type if you want

#

But I guess with slf4j that's not an issue

prisma wave
#

override val logger = java.logging.Logger.blah

#

doesnt work

jovial warren
#

that won't work anyway

#

since this is an abstract class and this property isn't open

prisma wave
#

then make it open

jovial warren
#

why?

#

also, you can't override SLF4J loggers with java.util.logging loggers can you?

prisma wave
#

no exactly

#

But you could override it with a different slf4j logger perhaps

jovial warren
#

also, I'm still trying to think of what I should supply to this getLogger call

#

maybe the name of the plugin rather than the class?

#

though it would really make people who name their main class Main look like a mug if I used the class lol

surreal quarry
#

are you gonna require a plugin.yml

jovial warren
#

I want to use something like that yeah

#

the only other option really is annotations

surreal quarry
#

reflection

#

maybe

jovial warren
#

and I like having a plugin.toml file anyway

surreal quarry
#

yea true

jovial warren
#

or should I use YAML

stuck harbor
#

mmmmmmm toml

#

I wanna use toml more

surreal quarry
#

toml is fine probably

stuck harbor
#

but server owners dont like things that aren't yaml

jovial warren
#

TOML is really really bad for nested structures though

stuck harbor
#

sadge

#

well yeah

#

it has no treees

jovial warren
#

yeah

surreal quarry
#

true true

stuck harbor
#

that's kinda the point

surreal quarry
#

i mean yaml is used by basically everyone in mc stuff

#

might want to keep it consistent

stuck harbor
#

meh

prisma wave
#

plugin.elon

#

plugin.edn

stuck harbor
#

just use clojure and toml ;)

jovial warren
#

could call it plugin.yml, or krypton.yml lol

prisma wave
#

lein new plugin

stuck harbor
#

mmmhm

#

good

#

I still haven't got clojure <-> java interop down

jovial warren
#

gonna loosely base this off of Bukkit's plugin.yml, with commands and permissions being optional though

surreal quarry
#

its not krypton

#

its a plugin

jovial warren
#

true

surreal quarry
#

if you want kyrpton in there do krypton-plugin.extension

jovial warren
#

nah I'm just gonna stick with plugin.yml

prisma wave
#

plugin.korm

jovial warren
#

I've just thought about the fact that I haven't even implemented the reflective loading logic yet lol

#

🥲

surreal quarry
#

shouldn't be too hard

jovial warren
surreal quarry
#

lol

#

org.reflections:reflections:0.9.12 might make it easier

#

i used that earlier today to register commands for a plugin lmao

jovial warren
#

you know, contrary to its name, reflections isn't a reflection library

#

it's a classpath scanner

prisma wave
#

we know

surreal quarry
#

yea yea yea

#

it works for what you need to do though

jovial warren
#

also, how should I register plugin perms?

#

I could just steal the perms stuff from Bukkit I guess

#

although, do permissions really need to be registered as such?

#

I mean, Bukkit's purpose of registering perms is just for retrieval by other plugins

#

and descriptions/default values

#

and heirachies

surreal quarry
#

you could make permissions plugins implement an interface/class like vault does
you could use bukkits thing
you could say fuck everyone and require luckperms as a dependency, then expose its API through krypton's api

jovial warren
#

lol

#

I think I'd rather option 2 tbh, would probably be easiest

surreal quarry
#

yea probably

jovial warren
#

or just say fuck permission registering entirely, which is option 4

#

I think option 2 is the best though, so option 2 it is

#

I mean, I can always use Bukkit's loader as a reference lol

#

a.k.a steal it

surreal quarry
#

if you do option 4, you make all plugins have to depend on every major permissions plugin and implement each one

lunar cypress
jovial warren
#

yeah that's not what I mean by not registering permissions lol

surreal quarry
#

oh

jovial warren
#

as I said before, Bukkit's entire use for registering permissions is just for retrieval by other plugins

#

and /help

#

that's it

#

also, @prisma wave, here's one for ya

surreal quarry
#

are you talking about registering them as in like plugin.yml permissions

jovial warren
#

how should I handle the plugin.yml descriptor?

prisma wave
#

what

jovial warren
#

I want to have the logger's name be the name of the plugin btw, rather than the class name

#

but anyway, I want to expose the descriptor to plugins

#

like Bukkit does

prisma wave
#

the what

jovial warren
#

basically the object that represents the plugin's plugin.yml file

prisma wave
#

oh like plugindescriptionfile

prisma wave
#

right

#

ez

jovial warren
#

go for it reflection master

prisma wave
#

dont need reflection for this

#

mostly

jovial warren
#

he says

#

xD

prisma wave
#

plugin interface defines an abstract val, "JavaPlugin" equivalent overrides it with the actual value

#

you could just pass it through the constructor

jovial warren
#

and which one exactly is inherited from?

prisma wave
#

?

jovial warren
#

which one do you inherit from to make a plugin?

prisma wave
#

oh

jovial warren
#

as your main class

prisma wave
#

the javaplugin equivalent

jovial warren
#

so basically just Bukkit

prisma wave
#

this is actually one of the few bits of bukkit that i think is quite nicely designed

jovial warren
#

then we run into the same issue

prisma wave
#

which is?

prisma wave
#

just use a constructor

jovial warren
jovial warren
prisma wave
#

Which is?

jovial warren
#

because plugins inherit from this, they have to call the constructor

prisma wave
#

and?

jovial warren
#

how can I have them not have to provide all the shit I do?

surreal quarry
#

can they add the same things to their constructor

#
class MyPlugin(private val server: Server) : JavaPlugin(server)```
#

idk if that works

#

i feel like it might

jovial warren
#

that was what Matt suggested, but that gets messy when you have to DI the data folder, server and plugin description file

#

for every plugin

#

also, you suggesting I use a secondary constructor with lateinit properties BM?

prisma wave
#

absolutely not

jovial warren
#

e.g. ```kotlin
abstract class JavaPlugin() {

lateinit var server: Server
    private set

lateinit var folder: File
    private set

lateinit var description: PluginDescription
    private set

constructor(server: Server, folder: File, description: PluginDescription) : this() {
    this.server = server
    this.folder = folder
    this.description = description
}

}

prisma wave
#

Horrendous

jovial warren
#

that is disgusting

#

what be yer idea matey?

old wyvern
#

Why is it a open class?

#

Make it an abstract class

jovial warren
#

alrighty

#

anyway, better idea = ?

old wyvern
#

You're looking for a replacement for something like JavaPlugin right?

jovial warren
#

I was just deciding if init is a good idea or not

old wyvern
#

for what exactly?

jovial warren
#

initialising the plugin

#

injecting the server, data folder and plugin description file

old wyvern
#

Id suggest having delegates that provide them

jovial warren
#

example?

jovial warren
#

Plugin might as well just be a single abstract class

prisma wave
#

other implementations

#

might not be necessary now

#

but you can decouple the messy JP logic and the interface

jovial warren
#

true