Earlier quoted context omitted.
No, because my competitors who are attempting to fill the same orders I am attempting to fill are not chasing pointers.
are your competitors using java?
Java is relatively common in HFT yes.
Java's records, Lombok's data, and Kotlin's data classes
271–280 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#272Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other. https://kotlinlang.org/docs/jvm-records.html#declare-records...
Yeah, and that is a good example of how semantics might change depending on which platform Kotlin code is targeting.
Re: Java's records, Lombok's data, and Kotlin's data classes
#273Earlier quoted context omitted.
You can use Scala without introducing implicits and even if you have to interopt with a library that does require them, it's quite easy to learn how to use them. It's also easy to abuse them but then that's not really Scala's problem. They are changing implicits in Scala 3 though with the "given" keyword which is more ergonomic.
Scala can't let go of implicits as they're a fundamental part of the language. I just don't believe this Scala 3 fudge to give the impression implicits are not alive and well beneath the surface.
Scala 3 takes the most common use cases for implicits and makes them more ergonomic. Implicits are still in the language, but not exposed as concept.
Odersky called the approach for Scala 3 "intent over mechanism."
Re: Java's records, Lombok's data, and Kotlin's data classes
#274Earlier quoted context omitted.
Scala has the full suite of Java collections without any conversion or overhead whatsoever. But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements. The Scala adapters are merely ways of convertin…
I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
It's only a problem if you can't decide which part of your project to write with which language.
If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.
Re: Java's records, Lombok's data, and Kotlin's data classes
#275Earlier quoted context omitted.
I'm not sure, but I think I would make a language based on structural typing only, including to allow a structural type to contain names. (Scala actually already has literal types that come close) Think about the following type-level (not runtime) representation for a structural type (tuple): (String -> Integer) And the following for a structural type with where each "member" has a name: (("name" -> String) -> ("age"…
I think nominal types are a must, otherwise you lose most of the benefits of static typing. Is an Email type the same as a String even though they are the same under the hood? I precisely should not accept it without explicitly casting it, otherwise I would have duck typing. But I agree that explicit structural types can be useful at places.
I think you misunderstood my idea. For example, check the User that I defined. Even if you would have another type with the same structure, the name would be different, so it would not be interchangeable without a "cast", even though both are ultimately structural types. It's
just that the name is now part of the structural definition.
Re: Java's records, Lombok's data, and Kotlin's data classes
#276Earlier quoted context omitted.
Precisely: you did not write the original solution, which is where immutability shines. It's a code comprehension tool; it gives you guarantees about code you didn't write. That's a huge boon!
There are no guarantees that it is the same object you get so it is pointless.
No one uses immutables to make sure they “get the same object”. What does that even mean?
Re: Java's records, Lombok's data, and Kotlin's data classes
#277Earlier quoted context omitted.
> so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change. I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.
Good code don't have this issue.
good code shouldn't need to be debugged either ;)
Re: Java's records, Lombok's data, and Kotlin's data classes
#278Earlier quoted context omitted.
Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.
What Kotlin features do implicits serve to replace? I'm new to Scala and am having trouble imagining when I'd want to use an implicit, so I'm genuinely curious.
Scala implicits are used in a few different places, predominantly in library code where they can for example be used to derive instances of type classes. e.g. in circe:
import io.circe.syntax._
List(1, 2, 3).asJson
For you as a normal user, the two common places where you might use implicits are (1) for implicit classes providing syntactic sugar:
// original
def doSomething(a: A): B = ???
val a: A = ???
val b = doSomething(a)
// with implicits
implicit class AImplicits(a: A) {
def doSomething: B = ???
}
val a: A = ???
val b = a.doSomething
implicit def optIntToInteger(optI: Option[Int]): java.lang.Integer = optI.map(Int.box).orNull
Re: Java's records, Lombok's data, and Kotlin's data classes
#279Earlier quoted context omitted.
I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
It's only a problem if you can't decide which part of your project to write with which language. If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.
What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. On the other hand you have Kotlin which just directly, frictionlessly deals with Kotlin/Java collections the same way (in fact, they literally are the same). We're comparing "some small-to-medium cost" against "zero-cost".
Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."
Re: Java's records, Lombok's data, and Kotlin's data classes
#280Kotlin data classes can use Java records as their implementation if running on JVM, so it’s not like you have to choose one or the other. https://kotlinlang.org/docs/jvm-records.html#declare-records...
That misses the point. The strength of records is that the language can build features that are only possible because of records' restrictions. It's not that the bytecode says "I'm a record" - which is all you get if Kotlin compiles a data class to one. @JvmRecord gives you all the limitations with none of the benefits. The annotation only exists for compatibility reasons.