Well, there you go. Typescript can only get you so far. Unless you want to be a low-paid code monkey, time to learn natural languages.
ps. I have many Spanish colleagues, and I have a hard time understanding them in general (when they speak English). Only one other nation is worse, the French...
It may not help that there are more of them, and of course, among themselves they speak Spanish. One of them then turns to me and asks something switching to English, he keeps his speech mostly unchanged (speed, enunciation, pronounciation), except he is putting supposedly English words one after the other...
The Spanish accent in English is --simply put-- atrocious. I've met many Spaniards, and only a few had a clear, understandable accent. Even academics with British or US post-docs may not speak clearly. Nor flight-attendants, for that matter (juecom odi flai tu ásterda).
I only know a few French, but I had a colleague who (although not of the French nationality) was born and raised there, and apparently was taught English literature through reading Les Hauts de Hurlevent. Yes, Wuthering Heights, in French.
> ...why the candidate wants to work at our place.
Sorry to be blunt, but - to earn some money to feed their family? Just like applicants are not unicorns, neither are companies - unless you are FAANG nobody really cares about your shitty company really. (Maybe not even if you are FAANG.) If the CV matches the JD, why do you have doubts if they have an idea about the work? They obviously haven't the faintest idea, but how could they (unless your code is open source).
From the applicant's perspective, they are applying to multiple places at once. Investing emotionally at step 0 (when they don't know if their CV will even be considered) is taxing, and unfair. Once there is a connection, you can expect them to invest more, but not until then. Because they will apply to 10 places, get ghosted by 5, get an automated NO response from 4 (usually a month later), and maybe, MAYBE they get an invite to the last one. Get a conversation started first and THEN expect investment.
It's totally fine if somebody just wants the money. We are all in it for the money to some degree or another. No need to fake enthusiasm. Actually, many applicants I see want to work part time (e.g. 2/3) and just want something to pay the bills and be able to pursue their hobbies.
But I'd like to know, why did you send your application to our company and not one in another industry?
I work for a university data center. Many of my colleagues have a scientific background. If not in academia, they could do coding, R&D, devops, science communication, product management, finance or many other things. They are 'lateral entrants' in any profession.
If people can't answer "why did you apply here specifically", it means one of two things: They don't have a clue what their job would be, and they and we are likely to be dissappointed when they show up. Or: they sent their application to everybody indiscriminately. That signals that they likely aren't a good match for the skills needed, and also that they have a high rejection rate.
> * data class Foo(val theImplementationAndStyleOfDataClasses: String)
For the purists there are records now in Java (which can be combined with destructuring / pattern matching - there were significant improvements in this area in the last few JDK releases, and more are coming!). In this regard Java had surpassed Kotlin by some margin.
For the enterprise coders, there is the Immutables project (https://immutables.org) which you can say is Lombok on steroids (but implemented correctly, that is, by generating classes which you can inspect as regular source code, instead of relying on hacking the compiler...).
> * elvis?.operator?.chaining
This will hopefully be finally resolved by one of the subprojects of project Valhalla, as a prerequisite for value class support (which cannot be null, so...).
The others on your list are small and subjective stylistic differences, of course your preference may vary, but should not weigh heavily in any Java vs Kotlin discussion.
Java records do not have a copy method (or with clause or whatever equivalent), and there are no keyword arguments.
This makes Java records extremely painful to use for any data has more than 3 fields or so. You could use them together with an annotation processor like RecordBuilder (or Immutables or Lombok, but I don't think they support records?), but that's just not pure Java. Annotation processors that generate byte code always come with their own complexity.
Kotlin data classes have their own warts (order-based destructuring can be dangerous and the copy() method is a bit hacky) but the overall ergonomics for large value objects are better than Java records at this point.
Lombok supports `@With` on records, which adds wither methods. And there are ongoing JEP discussions on how to support this natively in Java.
Lombok is so ubiquitous today that I effectively consider it part of the language. And even with Lombok, the Java toolchain is so much faster, easier to use, and more stable than Kotlin.
Kotlin is a great language, marginally better than Java, but I'm not sure it's worth enduring the toolchain. And Java keeps improving.
If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design.
Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start.
On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first.
In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.
Nah: If you think Kotlin is vastly better than Java, then you have a poor grasp of Java. I offer the same evidence you did.
Having worked professionally in both, I find that good programmers can write excellent code in both languages; bad programmers can write terrible code in both languages. The average cultural practice of the Kotlin community is perhaps better than the average cultural practices of the Java community (which huge and defies averaging anyway). But Java code which emphasizes immutability, uses Optional instead of nulls, uses streams, etc is pretty indistinguishable from Kotlin.
I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022:
Here are some of my favorite Kotlin improvements over Java that I leverage all the time:
* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)
* Local variables are final by default ("val")
* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)
* Much improved collection API
* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)
* Extension functions (incredibly useful in practice)
* Much better DSL capabilities (great for UIs, generating HTML, etc.)
* Yes, the Kotlin type system is better, no question. And yet it doesn't really matter for 90% of code, Java's type system is "good enough". And in the places where it tends to suffer, IntelliJ ends up covering the ground anyway (validating various annotation values, spring properties, sql, etc).
* The difference between nullable types and Optional<?> types is not material. TBH I quite like Optional<?> and how it meshes with streams.
* "final by default" is indeed nice. But putting `final` everywhere (which we do) is at most a tiny annoyance. This is not material.
* Clear type distinctions between mutable and readonly collections is better, but not material, because we treat all collections as immutable.
* Java streams hit 90% good enough, and StreamEx tends to fill in another 9%.
* We don't have pain points with mutating variables in closures because we don't use mutable variables.
* We don't have problems with checked exceptions because we don't use checked exceptions (and when interfacing with foreign code that throws checked exceptions, we use @SneakyThrows or wrap).
* Coroutines are a major net negative for Kotlin, and Loom is already here. After many years of async programming in JS/TS, Ruby, and (going back far enough) C++, I've concluded that async programming (and function coloring) is absolutely toxic and should be avoided unless it's absolutely required for performance (or the platform, ie GUIs).
* Multiplatform support has great future potential, but it doesn't seem to be ready yet. I just started a greenfield project and _really_ wanted to use KMP. Decided against it in favor of a React frontend. I don't want to live on the bleeding edge, I have work to do. And I've been bitten by deadended technologies enough times in my life to know the risk isn't worth it.
I could go on but I think you get the point - my Java looks like Kotlin, and the parts of Kotlin that would really diverge from my code aren't things I want. You could tell me that I should use coroutines everywhere and I just simply disagree.
> This will hopefully be finally resolved by one of the subprojects of project Valhalla
I think we'll see them come in through https://openjdk.org/jeps/8303099 although I'm not a huge fan of the approach chosen (tri state nullability: explicitly nullable, explicitly non-nullable, legacy code that should just be treated as nullable).
Except for native support for reification, almost all of Kotlin can be reimplemented by Java if you wait long enough and stack enough class annotations. It's all stylistic up to a certain point, but the classic Java style combined with the glacial improvement process is one reason why some people want to use a different language.
I think I'll have an easier time convincing someone to consider Kotlin than I'll have convincing someone to add Immutables+Manifold to the dependency chain. You end up writing Java that's not really Java like, but also not something that there's a good standard style for, and that usually ends up in a mess.
I'm glad with pattern matching, Java is now pushing Kotlin to improve rather than the other way around. I'll hope to use those features one day, when companies finally upgrade from Java 11 to Java 17 in five or ten years.
> pattern matching ... In this regard Java had surpassed Kotlin by some margin.
I did just glance at Java's pattern matching; and yeah, it does look like it is a bit more powerful than Kotlin's pattern matching in that it can, at the same time, look for both type and a conditional. That's relatively neat - not something I've personally needed / wanted; but neat just the same :)
The JVM is a really nice virtual machine in how it lets us use both of these languages fully interchangeably to pick the one we like more.
I'm glad Java has been investing in some of these areas, too. Everyone improves when paradigms and new learnings are distilled.
10+ years in the making, at this year's Devoxx Brian Goetz said that they are almost ready with the design of Project Valhalla and can start JEP-ing it in future JDK releases. No timeline yet, so we probably will not see it until the next-after-next LTS release (29?)... But Java, like Cobol, is not going anywhere, so the wait will be worth it.
Great, though is that perhaps orthogonal to my complaints? My vague understanding is that Valhalla is about transparently allocating local objects on the stack instead of the heap when possible (i.e., when escape analysis confirms that they can't "get out" of the method that declared them), the way primitives are now.
But these are the same problems! I'm not intimately familiar with the current state and internals of project Valhalla, but they were proposing `primitive classes` backed by primitive types, allowing said class to be used as a type in generic code. Moreover, primitives would become ValueObjects, so you would have your int[] which would also be an Object[]. In other words, the difference between primitives and objects would be much smaller in terms of the language.
Bottom line is, you could have your cake and eat it too - have an int[] that looks like a List<Int>, and vice versa, while retaining the performance characteristics of an array.
Thanks, I'd thought that the goal was to reimplement aspects of the compiler+JVM to preserve existing language semantics but be more performant, but from what you've written I take it that the goal is actually to expand the language semantics themselves, in a way that would bring primitive types and objects (and thus generics) closer together.
It took me some time to get why this is faster than simply poking in a for-next loop - nice hack (for those who don't know I can recommend one of Ben Eater's latest BASIC hacking videos)!
But why add only 1 character each time, why not add the string to itself? That would grow it exponentially and would require much fewer steps. Or is string concatenation much slower than character concatenation?
Which would limit the loop to 1 + 2 + 4 ... 128 = 255. You could start off with this, but making it work and filling exactly 8000 might be too complicated.
The 1..125 loop stores 8000 bytes of string and they need to clear 8000 bytes.
There may be a fast path for adding one character, but in any case bytes of program are a valuable resource with only 64k ram so having a second loop from nearest power of two to 8000 would be a waste of bytes.
It may not be precise in its details but it's a very accessible explanation that's certainly "good enough." Maybe you could swap it in for "non-whole numbers" and still be reasonably accessible, but that's also not perfectly accurate since integers are stored just fine inside a float.
I'm certainly not going to fault them for using layman terms when addressing laymen.
Ideally for this work you want somebody who is capable of communicating in a way that doesn't feel dumbed down and yet also isn't actively wrong. This explanation of the floating point types does not hit that mark. I'm not in the market for an Odin book, so in some sense it doesn't matter what I think, but across fields it's better if what you're saying is able to both serve its immediate purpose and actually true.
People are going to remember (some of) what you taught them and even if it felt peripheral at the time they may have centred it. When they return to this teaching again, it's not surprising that they assume you meant what you said, even if in your mind it was figurative or targeted at a superficial understanding of the subject.
Decimal representations do exist in machines. Representations that can manage 1.2 exactly but can't handle a third, or pi, or the square root of 2 for example. But the floating point numbers aren't that, they're a weird (but useful) binary fraction and if we're going to mention them at all we need to make it clear what's going on here.
For example the "float" (32-bit IEEE floating point type) called 1.2 is actually 5033165 divided by 4194304 which isn't actually six over five (1.2) but it's pretty close.
Hi, author here! I will update the book with a few clarifications surrounding my sloppy use of the word "decimal". As some have pointed out it is a bit of a "layman way" to view things, but nevertheless the reader should be made aware of whenever I use sloppy / simplified language.
I agree with OP that it's unnecessarily confusing. A "method" is a procedure. The floating point number is the result of that procedure, not the procedure itself.
"Decimal" implies a ten based system, even though it's perfectly fine to say "binary decimal".
Using your own replacement words, it would be clearer to write "A floating point number is a representation of a number with a fractional part".
Maybe it should've said "is a method of storing" instead of "for". It would make it clear it's not talking about a procedure, but a way or manner of doing something.
Maybe OP reacted because a float only looks like it is a way to store decimal numbers, when it's only an approximation of decimal numbers. If you really need decimal numbers you need something like mpmath¹.
As a shorthand to explain what a float is to someone, "a decimal number" is an OK start though.
But sometimes that approximation breaks down even for simple examples, i.e. 0.1 cannot be represented as a float. This can be quite unexpected if your mental model is that "floats are decimal numbers with a certain precision".
Very few numbers have decimals. They're not just numbers with whole and fractional parts, decimals are base 10 as well. .NET has them for monetary uses but I'm unaware of any other language(family) that has them built in.
Blinking / flashing bike lights were kind of OK when they were in the 10-20 lumen range. But nowadays even the cheap ones are on the order of several hundred lumens, which is a completely different game. It is possible to buy a 1000 lumen light for around 50 EUR (Magicshine), now consider that a single car headlight is around 1500 lumens... These lights have no cutoff beam.
The problem is not even cars though, but other cyclists. Even with a cutoff beam it is easy to blind oncoming traffic if the light is not setup correctly. Flashing, it should be illegal.
At least car headlights are aimed down, below the eye-level of other drivers, and this is actually checked and enforced in the UK. But many cyclists install high-powered LED beams and aim them upwards, at the eye level of other cyclists. It's even worse when they're flashing/strobing lights!
I understand all those against HS2 due to various reasons (costs, environment etc), but what is the alternative? If the current tracks are at capacity there is no easy solution. If they stop the project now, surely, that's all the money spent so far down the drain?
I heard someone say that they wished it had been called High Capacity 2, rather than High Speed 2.
What we need is more rail capacity, while people opposed to this project latched onto the idea that no one really wanted to get from London to Birmingham (a somewhat unlovely city that is the first major stop on the line) faster.
It's a surprising black hole on the map, seen from London. In 20 years in the country, it has never come into any conversation I've had except for "have you ever been to Birmingham? No, me neither." For a major city so accessible from London, it's very odd.
Leisure is already more than half of the trips on UK rail. It’s mostly people living their lives. Reducing demand seems mostly a dead end to me except perhaps along very busy commuting corridors, of which there aren’t that many and of which demand is still high at weekends because work hubs also tend to be leisure hubs.
by far the most common method of public transport for commuting is by bus, which is why the Gov spent all that money subsidising bus fares in the last couple of years.
You’re making a somewhat classic correlation = causation mistake here. I.e. because most people use cars, they must prefer cars over alternatives.
In reality a big part of why people use cars is because there isn't a practical alternative, because we either haven’t built it, or we tore it down in the 70s/80s. There was a period where the UK government honestly thought that public transport was going to cease existing, and be replaced by private cars. The decades since have clearly demonstrated why that isn’t true, as usage of public transport has grown year-on-year despite chronic underfunding, and the slow dismantling of services.
Simply typing `ls -la` + Enter in the terminal window was a significant challenge, even if I typed slowly. And then I had to press Enter about 5 times until it registered it.
Well, there you go. Typescript can only get you so far. Unless you want to be a low-paid code monkey, time to learn natural languages.
ps. I have many Spanish colleagues, and I have a hard time understanding them in general (when they speak English). Only one other nation is worse, the French...