ByteCode.News
Submit RSS Atom Sign in

Back to the channels

#java

  1. dreamreal I personally don't think it's an issue if it has a dependency on KOTLIN
  2. dreamreal if it has a lot of kotlin dependencies it kinda depends
  3. dreamreal but the stdlib is pretty small, I'd be more worried about the entire ecosystem than kotlin itself
  4. dreamreal if it's multiplatform dependencies I'd be, uh, more concerned
  5. NeXeN it also increases the dependency tree and adds overhead to method resolution, albeit maybe small
  6. dreamreal by adding to the classpath?
  7. dreamreal I mean... have you been able to *measure* the overhead change?
  8. dreamreal or are you talking about something else?
  9. NeXeN no, but also java can't use kotlin inline so what may perform well purely kotlin won't perform as well in java
  10. dreamreal wait, what?
  11. dreamreal Can't... use kotlin... inline?
  12. dreamreal That's ... not how bytecode works
  13. NeXeN yeah kotlin can inline it at compile time, but a java call to kotlin dep won't benefit from it
  14. dreamreal but... but... that's ... such a LOCALIZED problem that shows up at specifically early phases of JIT runtime that it's kinda not worth counting
  15. dreamreal JIT *can* inline it, it just would do it later than the kotlin compiler MIGHT
  16. NeXeN also there's the consideration that the build process will be a little slower having to call k2 and javac
  17. dreamreal That assumes you're compiling the kotlin as part of this build, though
  18. NeXeN so in other words, if you already use it you're already paying any tax (startup time too), then it can't hurt
  19. dreamreal if a java project imports "kthing" as a dependency and kthing has kotlin stdlib as a dependency, compile time is not affected
  20. NeXeN yeah using jars won't cause any build time increase
  21. dreamreal and kthing is bytecode, so bytecode is going to act like bytecode
  22. dreamreal not to push back on your nonsense, but this is like sayig "that project's no good because the coder used vim"
  23. NeXeN and if you are using lambdas in kotlin, inline as much as possible ...i read an article a while back on kotlin lambdas and the JIT having problems with inlining them
  24. dreamreal I haven't seen a problem with kotlin lambdas in practice
  25. dreamreal and I think it's fair to say I use a crapton of 'em, to use the technical terms
  26. NeXeN its kind of unfair of you to say that since it scales down my argument
  27. dreamreal You haven't paid me to be fair, only experienced
  28. NeXeN but beyond that i got nothing.....i don't think it will matter much besides bloating a jar by 5 megs or more (plus whatever else it pulls in besides stdlib)
  29. dreamreal That's really it, in the end, which is why I say I'd have no real problem with it
  30. jreicher cheeser: what's the difference in consideration of a transitive when updating and a transitive the very first time you start using the library?
  31. cheeser once you've been using a library, it's already been vetted, you know what you're getting, etc. when taking up a new one, there are no expectations. people feel weird about things like a new language library showing up.
  32. jreicher I can understand that if the original vetting was so thorough that you would be reluctant to do it again, but was it?
  33. cheeser ¯\_(ツ)_/¯
  34. jreicher Exctly
  35. cheeser the general consensus on bluesky and mastodon was that only a barbarian would do such a thing
  36. jreicher IMO it's perfectly consistent to worry about an upgrade when the introduction was done very carefully, but sometimes it's not consistent. Sometimes people fuss about upgrades not realising that the horses have already bolted because they weren't careful at the start.
  37. jreicher That doesn't make sense to me.
  38. cheeser yeah. it's not an entirely consistent stance but it costs me little to rework this code back in to java and simplifies my build quite a bit.
  39. whaley cheeser: just replied on mastodon about that. my hot take was major version upgrades wouldn't bother me so much, minor versin pugrades was "you are a barbarian" inducing
  40. whaley *version upgrades
  41. dreamreal as in, introducing kotlin as a new transitive in a minor upgrade?
  42. whaley aye
  43. dreamreal that... doesn't sound like a minor upgrade, although it might fit semver rules (public API unchanging, no major breaking features)
  44. dreamreal but it's amusing that you're using mastodon :D
  45. Para From security point of view it's also kind of a scary thing, but that goes with all large dependency changes in general vOv
  46. whaley dreamreal: way better signal:noise ratio there for nerd stuff
  47. dreamreal I found the fediverse WAY too noisy a protocol. I considered it for nevet, to hook it in, but wasn't willing to pay for the network traffic.
  48. whaley but I digress... I largely consider the inclusion of any transitive dep that may already be widely distributed elsewhere in a minor version update to be a bad, irrespective of whether said transitive dep was actually the stdlib of another language
  49. Para Even EU did run ActivityPub for a while for official communicae, and then let it go because it was apparently too nerdy and bureaucratic even for them.
  50. dreamreal Para: I ran mastodon locally on a VPS, it was incredible
  51. dreamreal It was like using SBT again
  52. Para dreamreal: Wow, tell me more.
  53. whaley did bluesky ever get federation, btw?
  54. Para It's kinda there but not really.
  55. dreamreal ew, bluesky's initials are absolutely valid
  56. dreamreal I also considered bluesky for nevet and decided HARD NO
  57. dreamreal Para: my VPS was absolutely hammered by it
  58. Para Like in principle I guess one could have it federate stuff but as someone who even wrote their custom schema to Java generator last year...the promise basically dies at repository.
  59. dreamreal Like, doing version upgrades was a massive relief on the system load
  60. Para As in data stores.
  61. dreamreal bluesky is a toxic security channel
  62. dreamreal never say anything on there you don't want forcibly exposed to the world
  63. Para Yeah it's a public append only log.
  64. dreamreal I think $work would censure me for even having an account there
  65. Para Plus they've kinda frozen on adding new API libraries even. Like...this was why they decided to create their own schema language yet can't even produce more than two SDKs, wtf.
  66. Para I'd be open to opening my atproto library stub for wider world if it wasn't so frozen and answers to technical questions nonexistent.
  67. Para In its current state it would just add to the noise so who cares.
  68. dreamreal for bluesky?
  69. Para yeah
  70. dreamreal I definitely wouldn't bother
  71. dreamreal ActivityPub at least has a valid motivation: it's gross and incredibly heavy, but still. Understandable. Bluesky is a horror.
  72. Para It was kind of fun as a coding exercise but beyond that...meh.
  73. Para And as said, they've convenienty left out the actual persistence part or describing how those APIs are supposed to work in a generic way to enable federation. I suppose microdosing adderall fueled Silicon Valley dreamer could spend 16 hours a day to figure it out by hammering the official website and reversing everything, but...there's no point.
  74. Para I do count it as a win though that Bluesky basically exists because Elon Musk made a huge and expensive miscalculation.
  75. dreamreal yeah, twitter's been out of business for a while now
  76. whaley bsky was going to exist regardless... it was being incubated as part of Twitter before the end times. Or rather, dorsey brought on Graber et. al. and salaried them under Twitter to work on it there
  77. Para Or maybe not; migration path probably would've been too hard/expensive and outright replacing a running system is way too dangerous for any business.