ragnese

54 ms·

481.
by ragnese 6y ago
Yeah, the poster didn't make totally clear whether all of their business records are totally gone, but it does sound like that's the case. The ERP was very likely the source of truth for everything- including employee informatio
482.
by ragnese 6y ago
If you agree that it's not idiomatic (and maybe I can get you to agree that it's more than just non-idiomatic when it comes to async operations that can fail), then are you actually refuting my original comment: "It's
483.
by ragnese 6y ago
I agree. That's not a very compelling argument at all, IMO. I've read some other stuff, too, though, such as praise for the ports system and FreeBSD's "jails" feature. But I imagine it's a little like Linux dis
484.
by ragnese 6y ago
I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or impl
485.
by ragnese 6y ago
Yeah, I know. I'm just lamenting how long it took to get to async/await. It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO.
486.
by ragnese 6y ago
> Structs/value types can be mutable, records are not. Fair point about record fields not being reassignable (not the same as immutable for others reading this). > And as far as I know, while records have a sane default equals de
487.
by ragnese 6y ago
Why can't coroutines take full advantage of Loom's green threads on JVM and do other stuff on Native/JS/whatever? I generally agree that being multiplatform is a lofty goal. And as much as I like Kotlin, it clearly inher
488.
by ragnese 6y ago
Agreed about nullability. And Java will never fix it fully or I'll eat my hat. ... but, you have to be pretty damn good to win out over the native language of a platform. And if it were just Kotlin today vs. Java 16, I think Kotlin is
489.
by ragnese 6y ago
I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that d
490.
by ragnese 6y ago
> Function builders are a really awkward unnecessary feature that was implemented so that SwiftUI could have a decent looking DSL. Ugh. I agree. I haven't actually used SwiftUI in anger yet, so I try to reserve my judgement, but t
491.
by ragnese 6y ago
Agreed. But Kotlin 1.5 will have enough interesting stuff with the new inline class and const methods that I think it'll keep its appeal for quite some time.
492.
by ragnese 6y ago
"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods. So
493.
by ragnese 6y ago
I think it's fair, though, to say that it's likely that the implementation and/or semantics may be more based on other JVM languages, who have to work on Java's terms. In particular, I'm talking about the fact tha
494.
by ragnese 6y ago
To someone who has a passing familiarity with OCaml, but none with F#, can you elaborate? Because I do hear the comparison frequently. Do people just draw the comparison because they don't actually know of any other ML languages beside
495.
by ragnese 6y ago
I think the person actually said Java/C#/F#. But in any case, I'm thinking that the real timeline is more that Java is prioritizing features that are most attractive from Kotlin, which borrowed the ideas from Scala. But Scala
496.
by ragnese 6y ago
Does anyone know of any testimonials of this from people of Mediterranean descent? My hair gets very, noticeably, oily if I don't shampoo every single day. It's kind of gross. I know many people who don't shampoo every day, b
497.
by ragnese 6y ago
> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can. Can it, though? I keep hearing/reading FUD around both unsafe and Pin making it unlikely to ever be able to ubiquitously enable the noal
498.
by ragnese 6y ago
Oracle MySQL's official one (Connector/J). Here's the code from the current version as of this message. It's in mysql-connector-java-8.0.23.jar. Class com.mysql.cj.jdbc.result.ResultSetImpl. Lines 814-818: @Overrid
499.
by ragnese 6y ago
I don't know. But the Rust team is VERY against introducing any breaking changes. So we're stuck with the semantics we have today.
500.
by ragnese 6y ago
Exactly. Which is unfortunate, because the fact that Rust has true type classes is absolutely awesome. But when dealing with traits, you have to remember the orphan rules, and the implicit object-safety rules- which sucks, because you might
501.
by ragnese 6y ago
> Not every application needs to take full advantage of the underlying DBMS. Sometimes it's just a place to put data and not lose it, e.g. a key-value store with transactions. ORMs handle that use case perfectly well. Okay, yes... B
502.
by ragnese 6y ago
For me, the issue isn't performance or even n+1 (though I do think it's easily to accidentally do stuff like that, even if you "know what you're doing"). You're probably a Hibernate expert. I'm not. I used
503.
by ragnese 6y ago
But my view at this point in my life is that SQL is SO not a simple language, that any and all ORMs are going to be way too restrictive and leaky. There's all kinds of weird crap that SQL does when it comes to nulls, empty strings, fal
504.
by ragnese 6y ago
There's a lot of air between "I need a query string sanitizer and/or a PreparedStatement construct" vs. "I need a full blown ORM."
505.
by ragnese 6y ago
Right. Agreed. I'm definitely not trying to say anything positive about SQL. ORMs are a doomed proposition. There is simply no way to write a database-agnostic ORM API while also taking full advantage of the underlying tech. Very simpl
506.
by ragnese 6y ago
> I rely a lot on SQL and in general advocate for it, but that’s too simplistic of a view IMHO. SQL makes it easy to write and read simple queries, and ridiculously complicated and arcane to write slightly more complex logic. > >
507.
by ragnese 6y ago
Which problem are we referring to? I was only making a general statement that I think Rust would have benefited from HKTs instead of doing umpteen ad-hoc implementations of specific higher-kinded types. I'm far from an expert, so pleas
508.
by ragnese 6y ago
Yep. Same. I've been doing Rust for years at this point (not full time, and with long gaps- granted), and it's exactly like you said: individually these things are simple, but then you're trying to figure out where you accide
509.
by ragnese 6y ago
I sympathize. As I said in another comment, the issue isn't really caused by async, IMO. It's caused by the complicated and leaky abstraction of traits. I'd be willing to bet that your difficulties were more around dealing
510.
by ragnese 6y ago
I agree that Rust should have embraced HKTs instead of resisting them every step of the way. It's been my observation that the Rust lang team is pretty much against HKTs as a general feature, which makes me sad. I'm also happy to

More ›