austin

joined 2 years ago
MODERATOR OF
 

If you've played around with version catalogs enough, you will inevitably come to a point when you when you want to also use a BOM in your version catalog. Doing that just feels so...clunky? You need to declare the BOM in the libraries section, and then you have to declare each individual dependency from the BOM as a library (without a version). Alternatively, you can just skip using the BOM entirely and declare each dependency without the BOM. In either case it's not a great experience and definitely could use some improvement.

I wrote a Gradle plugin (in Kotlin) to automatically generate a version catalog from a BOM so you only have to specify it once, let me know what you guys think!

35
Go: What We Got Right, What We Got Wrong (commandcenter.blogspot.com)
submitted 11 months ago by austin to c/golang
[–] austin 1 points 1 year ago (1 children)

If you already know Java, Kotlin for Java Developers is free and created by the Kotlin team.

[–] austin 3 points 1 year ago

I do think there’s a gap between hibernate and jooq that needs filling. I love the ease of querying for relational data with hibernate, along with support for validation annotations. On the flip side I love the jooq dsl, code gen, typed queries, and the flexibility you get from it, but there’s really no easy way to plug in validation annotations and querying for nested relational data requires a lot of effort. Based on a brief look of the docs, it seems like this library intends to fill that exact niche. Interested in checking it out when I get some time

[–] austin 4 points 1 year ago

Much needed change, I wish they made it apply for all go versions though

[–] austin 1 points 1 year ago

Not letting me change it either

[–] austin 2 points 1 year ago

The backwards compatibility promises of Go definitely makes upgrading a breeze. Java is pretty much in the same boat (except it maintains bytecode compatibility instead of source). When working with languages that don’t offer these promises it’s always a nightmare to upgrade to newer versions.

20
submitted 1 year ago by austin to c/golang
[–] austin 1 points 1 year ago* (last edited 1 year ago)

Optional has more syntactic sugar for more complex scenarios / functional call chaining that prevents repetitive if checks

Optional.ofNullable(myObj)
  .map(MyClass::getProperty)
  .map(MyOtherClass::getAnotherProperty)
  .filter(obj -> somePredicate(obj))
  .orElse(null)

This is completely null safe, the function calls are only made if the object is not null

[–] austin 1 points 1 year ago (1 children)

I had never heard of Phaser, but it looks pretty cool. I just read Baeldung's Guide to Phaser and correct me if I'm wrong, but doesn't it kind of seem like a race condition (it could just be how they use it in the examples)?

class LongRunningAction implements Runnable {
    private String threadName;
    private Phaser ph;

    LongRunningAction(String threadName, Phaser ph) {
        this.threadName = threadName;
        this.ph = ph;
        ph.register();
    }

    @Override
    public void run() {
        ph.arriveAndAwaitAdvance();
        try {
            Thread.sleep(20);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        ph.arriveAndDeregister();
    }
}

then

executorService.submit(new LongRunningAction("thread-1", ph));
executorService.submit(new LongRunningAction("thread-2", ph));
executorService.submit(new LongRunningAction("thread-3", ph));

if ph.arriveAndAwaitAdvance(); is called before all of the LongRunningActions are initialized, won't it proceed before it is supposed to?

[–] austin 4 points 1 year ago (2 children)

assuming you propose the idea to migrate to kotlin, it would go something like this:

  • talk to your other developers and see if they feel the same way. get other developer buy-in
  • propose the idea to management with reasons why it would be beneficial
  • management now either buys in and approves kotlin usage, or says it's not worth it

if management says yes, you now have like 20 people who have vetted and agreed with the idea. once you start writing Kotlin it's not like EVERYTHING is all of the sudden Kotlin. it's an iterative process, and hopefully you have test coverage. you can even re-use your existing java tests since the languages are interoperable. Assuming you follow a normal development process, the odds of a catastrophic bug coming out of nowhere to cause millions of dollars of losses wouldn't even cross my mind.

that being said, assuming the current code works decently well, management will have no motivation or reason to approve a total rewrite in a new language. it's more likely that they will only approve starting to trickle in kotlin for new projects or features, which even further reduces the likelihood of a catastrophic bug happening.

[–] austin 2 points 1 year ago

the developers don't have to of left the team to make it legacy code

[–] austin 2 points 1 year ago

I agree it’s unique and not really talked about. It kinda reminds me of Elixir’s doctest

5
Generics in Go (bitfieldconsulting.com)
submitted 1 year ago by austin to c/golang
27
Kotlin 1.9.0 Released! (blog.jetbrains.com)
submitted 1 year ago by austin to c/kotlin
[–] austin 5 points 2 years ago* (last edited 2 years ago)

Not quite what you’re looking for, but Google does have an official style guide which may be slightly helpful

20
submitted 2 years ago by austin to c/golang
view more: next ›