cryptos

If the included timestamp doesn't expose sensitive data, then using UUID v7 is a good default, because it has performance advantages on database operations and items might be sorted by ID in a meaningful way, what is sometimes desired (even if I never used it).

> The repositories include a large amount of intellectual property… connection strings, cloud access keys, blueprints, design documents, [single sign-on] passwords, API Keys [...]

That doesn't really sound like security best-practices would be applied. Why don't they use a credential store?

Why do people use percent for such big factors? To make the headline more impressive?

To 2) We need an app that would increase the counter for dropping iPhones automatically ;-)

A little indicator about technical failures (or groundings) per aircraft model would be nice to have :-)

Go is so minimalistic that it forces developers to reinvent the same things again and again. Just think about how common certain collection operations are and how easy they are in some languages (e.g. Java, Kotlin, C#, Rust), but in Go you'd write list and for loops like in the last century. This wastes developer time, makes the code harder to understand and adds chances for bugs.

So, this cite applies to Go: “Everything should be made as simple as possible, but no simpler.”

Do you really think that it would be a good fit? Apple is mostly a hardware company, although this hardware obviously needs some software and a part of it runs in the cloud these days. But at least my impression is that they are not really in the B2B market with professional services.

To enter the cloud market they are pretty late to the game ...

But that makes it somewhat entertaining :-) Have you ever heard of the German sports club "Bayern Munich" ("FC Bayern")? They've won all national titles since 2013! _That_ is boring.

https://en.wikipedia.org/wiki/FC_Bayern_Munich

No, they will allow to mark types as explicitly not null (the other way around). The default in Java will still be that everything can be null.

I feel no desire to use dynamic typing again, as nice as Clojure might otherwise be. While Kotlin is not strictly immutable, it is much better in this regard than Java. Collections are immutable by default in Kotlin (or more precisely you get an immutable view defined by the respective interface) and that is quite useful in practice.

Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.

> Null was always a pitfall in Java. It has slightly improved with the controversial Optional type. It’s also why I suggest that everyone use only wrapper types everywhere, instead of primitives, unless they can prove with a JMH test that a primitive provides enough of a performance benefit.

That doesn't make sense at all! Why should one do it without a need? To have NullPointerException with "primitive" types, too?

> Kotlin ecosystem is severely lacking compared to Java. FAANG has first-class support and commitments to Java, like providing JDK with multi-year support commitments.

It is not really needed to provide JDKs or something else especially for Kotlin, because Kotlin basically just uses the JVM (at least if you use the JVM as a target).

> To this day, there are significantly fewer Kotlin developers than Java developers.

Yes, that is probably true. Although almost every Android developer should know Kotlin these days and there are quite a few them. But even if a developer doesn't know Kotlin at all, it is relatively easy for a Java developer to learn it. In my experience it a takes a few days to a few weeks to be at least as productive as with Java (even not all Kotlin features are learnt in this time).

> Lack of progress: Compared to Java lately (e.g., records two years ago, pattern matching, and VT release this year), Kotlin has been stagnating in delivering the big features that would bring us (Infobip) value over alternatives.

Here, I agree. Some years ago I was super excited about Kotlin and couldn't wait for a new release. These days new releases are mostly boring. Maybe the most important stuff is simply done, but then there are enough interesting ideas to improve it (real pattern matching, meta programming, union types, ...). But JetBrains and Google decided that it is more important to improve the fundamental infrastructure first and decided to create a new, faster compiler (K2). As boring at it is feature-wise, I think it is a wise decision, because every project would benefit from it. The plan is to add new features, once the compiler is ready.

From the Guidelines:

> What to submit? [...] anything that gratifies one's intellectual curiosity.

https://news.ycombinator.com/newsguidelines.html

Maybe it's just me, but I don't feel very inspired on an intellectual level by news about a patch version ;-)

I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.

Just out of curiosity: What backup tool do you use?

Both points could be addressed by using a file system cache (or RAM disk) and a compiled language. A CGI application could, for example, be written in Go (https://pkg.go.dev/net/http/cgi).

Yeah, but CGI has fallen out of fashion and needed a re-branding!

But then again, it is Gnome's fault to pick the wrong tool for the job.

But then again the internet is everywhere now: desktop, servers, watches, washing machines, industrial systems, sensors ... So "internet language" is a somewhat pointless term.

I consider that a bad practice, because it doesn't make things obvious. I guess it works so well in Go, because the language itself is small, so that you don't have to remember much of these "syntax tricks". Making things explicit, but not too verbose, is the best way in my opinion. JetBrains has done amazing work in this area with Kotlin.

    for (item in collection) {
        ...
    }

    list.map { it + 1 }

    fun printAll(vararg strings: String)

    constructor(...)

    companion object

I like the `for..in` which reads like plain English. Or `vararg` is pretty clear - compare that to "*" and the like in other languages. Or `constructor` can not be more explicit, there is no need to teach anyone that the name must be the same as the class name (and changed accordingly). Same is true for companion object (compare with Scala).

Very true! I think a lot of the accidental complexity of early Java systems were rooted in the not so powerful language. If the language is too powerful (like Scala 2) developers do insane things with it. If the language is not powerful enough, developers create their own helpers and tricks everywhere and have to write a lot of additional code to do so.

Just compare Java streams with how collections are handled in Go and scratch your head how someone can come up with such a restricted language in this century.

I'm a JVM guy, but this is a good one :-)

I'm still with Gradle, but my feeling is the same. Gradle comes with some very good things, but the typical Gradle configuration is an insane mess!

However, not everything is magically better with Maven. It is slower (although the Maven daemon is an improvement), the XML config is a bit verbose and modules are not as straightforward as with Gradle. But the convention over configuration approach (without exceptions like in Gradle) makes maintenance way easier.

I wouldn't teach Pascal any more. While the ecosystem around it is not quite dead it is not alive either. So, everything feels a bit fallen out of time. At least to me it would be demotivating to learn the Latin of computer science.

I would rather pick Python or Kotlin.

"Advice for new software devs who've read all those other advice essays" Ha! That reads like someone is trying to lure new developers into recursive essays! Be aware! :-)

I have the vague feeling that way to many manager with poor technical skill make decisions like "We're going to the cloud. All-in!" or "Use a cloud-native™ approach!" without understanding all implications or to tackle problems (like fossilized business processes) that have nothing to do with the server infrastructure as such.

But what would be the definition of "cloud" then? I'd say it boils down to managed services, so that you don't have to care about basic system configuration, hardware or networking. The only thing 37Signals outsourced is the hardware part and basic network infrastructure. That is pretty much what was known as "colocation" in the pre-cloud era.

See also this talk: Why Static Typing Came Back, Richard Feldman, GOTO 2022

https://www.youtube.com/watch?v=Tml94je2edk&list=PLEx5khR4g7...

But would Go really reduce the "ceremony" compared to C#? I doubt it. Just look at Linq (functional programming APIs in C#) and compare this to the typical Go approach with auxiliary lists and for loops! Or what about error handling? Or null safety? Not that cool in Go, I think.

I would suggest Kotlin. It is concise and readable and the language itself is a bit leaner than C# (delegates are, in my opinion somewhat redundant, if there are first-class functions, for example).