I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?
TypeScript is in a unique position. It's basically a set of extensions to JavaScript, and with a very short list of exceptions, those extensions only affect the type system. You can mostly just convert TypeScript to JavaScript by going through your source files, selecting various ranges of text, and pressing "delete" on your keyboard. This is more or less how the TypeScript compiler compiles your code anyway.
The exception I can think of is enum types. These always result in some amount of generated code.
TypeScript can also apply some other transformations to your code during compilation, but as far as I know that's just so you can use newer JavaScript language features and target older JavaScript runtimes.
I don't want to stretch metaphors too far here but there's some truth in what you're saying. TypeScript usage is a tiny minority of JavaScript usage but it's climbing and I'm sure it's much higher than CoffeeScript ever was.
But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.
> TypeScript usage is a tiny minority of JavaScript usage
shudders at the thought
After using TypeScript for almost 5 years now, I can not imagine a scenario where I would write JavaScript without type safety - other than a 5 minute POC to test something out.
I look forward to the day when TypeScript can be compiled to wasm binaries and it can be a language all on it's own rather than a superset/wrapper of JavaScript.
I like TypeScript but I think there's a complexity threshold — if you have a massive collection of other people's code, types are essential. If you're building a basic web app which is using the built-in behaviour and have a reasonably modern editor + linter + test setup, type safety is still good but it buys you less than it does when your baseline complexity level is higher.
Since modern browsers and JavaScript give you a lot of functionality out of the box which people used to use libraries for, there are quite a few projects which are under that threshold.
For smaller projects, I find that the value is less the type safety (still valuable) and more the much stronger control of intellisense. Yeah, if you have a language server that's able to deal with typings your JS code will still be a lot better than without it, but starting with TypeScript just makes that way more fluid. I find that I write TypeScript much more quickly, and more correctly, than I do JavaScript, both for small and large projects.
I agree that TS is a good pragmatic choice for any non trivial amount of code but I am still surprised how bad it is.
Error messages in TypeScript are quite cryptic for a modern language. Compiling it is super slow. Type safety, well they are doing their best considering the very dynamic nature of JavaScript but now if we compare it to other languages that compile to JS like Elm, it is just not that huge of a step.
With Elm you get a guarantee of no runtime exceptions at all in productions plus the most helpful compiler ever written. Even compilation time feels much faster. Similiar for competitors like ReScript, Purescript and the like.
Of course TypeScript is the easiest to learn for established JS Developers. And I am quite grateful that the option exists but I just wish it would be better considering how much money is put into it.
That's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.
> If anything it slows development down, not makes it faster
It doesn't really "slow development down", it just forces you to explicitly specify the data structures that exist whether you decide to acknowledge them or not. Eschewing types is just a form of technical debt that every developer has to repay as they deduce the application data structures through trial and error, often times in production.
That strong following might not last. My company made the decision to have PySpark be the default for training and future greenfield Spark projects, and they're only really making official what's been the reality for the past few years. A shame, as Scala seems like a nice language but I've never really gotten into it as Python is always the preferred option.
It's true that PySpark probably is overtaking (or already has overtaken) Spark with Scala. I still personally like Scala over Java in general for non-Spark projects as it's much less verbose which is my main problem with Java. However, I also haven't used all the new Java features to see how that would adjust the comparison for me.
As soon as I opened the page, I searched for "null" and saw it didn't show up in the original post. Leaving that out is almost a bad faith argument, because it is the number 1 Kotlin feature I doubt Java will ever get.
Now, I will say that build times are way better on Java. A large part of this is the ability to generate ABI jars with Gradle, which you can't do with Kotlin. If anyone from Gradle or Jetbrains are reading this, please please please try and make this work, I know there's ongoing tickets but in larger projects Kotlin and Java are not even close, for this specific reason.
It's funny actually: my java code had mostly made peace with null. A combination of tireless performance of that if-dance where necessary, generous use of static methods for certain routine tasks on nullables and most importantly, @NonNull and null object singletons creeping into more and more code.
Now in kotlin it feels like it's just "drown it in question marks". I certainly end up with lots of nonnull signatures and far more reliable null handling than in java, but the ease almost feels wrong.
I am using more and more kotlin these days as an Android app dev
it starts that way, but over time you don't need the question marks as much because you're dealing with more and more code where the variables are guaranteed to not be null.
Where my code is mostly interacting with itself I see question marks almost as rarely as I saw Optional during my scala adventures (still can't believe a decade went by!), but the android API provokes it's share of nullability and the kotlin approach to deal with it is just so "why didn't we have that back in the MIDlet days!"
Some coworkers seem to type questionmarks faster than that IntelliJ "convert to kotlin" button and I hate it, but much less than I'd expect.
I really think Goetz/the Java language people are waiting to see if nullable types actually pay off in C#/Kotlin first, like with every feature, before considering it.
Java went the route of Optional<?> instead of nullable types. You still end up with some nullability issues working with old libraries (and even the std lib, like Map.get()) but by and large you can force a "never use null" policy on Java codebases and NPEs become very rare.
I fairly strongly prefer Optional over nullable types. Especially how it works seamlessly with streams.
It's actually kind of instructive to consider how Scala mostly solved the NPE issue by simply having Option available and discouraging use of null.
There are still issues at the API boundaries with Java or JS code, but that's about it. Outside of that, NPEs are usually in more niche places to do with initialization order and that sort of stuff.
Of course if you're inventing a totally new language you probably want to just avoid the possibility of null outright.
I think the author is more saying that a "with" operator would fit into Java record semantics but might not be compatible with Lombok @Data classes or Kotlin data classes (though it looks from your link that Kotlin actually does have something very similar in the "copy" method).
Not sure why this is getting downvoted; if you look at the hypothetical “with” syntax in the original blog post, it is clearly borrowed from the C# implementation.
The annoying thing about Java here is that it doesn't have default argument values, and doesn't allow you to name your arguments in function calls.
In Scala (I don't know Kotlin, but I assume it's similar) you could easily implement a copy() method yourself (and many people do if they need a case-class-like thing but can't use a case class) that behaves identically to the copy() method provided by a case class.
But the semantics of that copy() method require default argument values, and the ability to call functions using named arguments. Java doesn't have either of those, so instead of adding those features (I can understand the former being controversial), I guess the plan is to add entirely new syntax just for records, which IMO is a huge shame.
But it appears the "with" syntax is far from finalized, so it's possible they'll do something better.
It was included because changing data using records (copying it except changing the fields you need to change) is a shitty experience, so rather than showing the code you have to write, they showed you code you may or may not in the future be able to write.
Seems like an odd thing to mention. They are arguing that records are better than data classes, but part of their argument is "maybe, in the future, at some point, I don't know, it will be as easy to do this thing with records as it already is with data classes, we'll only need to add new syntax and a new keyword to the language".
You mean the article author? Yes, it was odd that he mentioned that, but besides that not a bad feature to have (but a bit wordy for my taste, I hope they'll change that).
> I'm not sure what it's taking about for the "with" feature: ...
The author is referencing possible future work that can build on the current records implementation, and the work Brian Goetz is doing with pattern matching and record deconstruction. Goetz has put together a draft that shows how these could be combined.
I used Kotlin in a large codebase, and one of my only complaints is the compile times. We use Gradle for our build system, and relative to Java it is slooowwww. But we like the other benefits of Kotlin, so it's worth it in the end. But if they could get compile times down, it'd be the perfect language imo.
Are there other companies where a CX Specialist makes the same as an engineer? Usually I see Engineering offset from CX, so an entry level CX employee might come in at Level 1, while an engineer might come in at Level 3. I don't think I've ever seen an Engineer and CX Specialist have the same corporate level, but perhaps that's just the companies I've worked at?
It's surprisingly easy, depending on your scale/scope of course. But in general, I've managed to build CI/CD pipelines that are tolerant of GitHub (or any service) failures by following these steps:
1. Use as little of the configuration language provided by the CI as possible (prefer shellscripts that you call in CI instead of having each step in a YAML config for example)
2. Make sure static content is in a Git repository (same or different) that is also available on multiple SCM systems (I usually use GitHub + GitLab mirroring + a private VPS that also mirrors GitHub)
3. Have a bastion host for doing updates, make CI push changes via bastion host and have at least four devs (if you're at that scale, otherwise you just) with access to it, requiring multisig of 2 of them to access
Now when the service goes down, you just need 2 developers to sign the login for the bastion host, then manually run the shellscript locally to push your update. You'll always be able to update now :)
> our CI can't clone the PR to run tests. What do other folks use to avoid this situation?
Multiple remotes can help and is certainly something you should have as a backup. However I don't think it solves the root cause which is how the CI is configured.
I'm a firm proponent of keeping your CI as dumb as possible. That's not to say unsophisticated, I mean it should be decoupled as much as possible from the the how of the actions it's taking.
If you have a CI pipeline that consists of Clone, Build, Test, and Deploy stages, then I think your actual CI configuration should look as close as possible to the following pseudocode:
stages:
- clone: git clone $REPO_URL
- build: sh ./scripts/build.sh
- test: sh ./scripts/test.sh
- deploy: sh ./scripts/deploy.sh
Each of these scripts should be something you can run on anything from your local machine to a hardened bastion, at least given the right credentials/access for the deploy step. They don't have to be shell scripts, they could be npm scripts or makefiles or whatever, as long as all the CI is doing is calling one with very simple or no arguments.
This doesn't rule out using CI specific features, such as an approval stage. Just don't mix CI level operations with project level operations.
As a side benefit this helps avoid a bunch of commits that look like "Actually really for real this time fix deployment for srs" by letting you run these stages manually during development instead of pushing something you think works.
More importantly though, it makes it substantially easier to migrate between CI providers, recover from a CI/VCS crash, or onboard someone who's responsible for CI but maybe hasn't used your specific tool.
You really just need a TCP pathway between your CI and some machine with the git repo on it.
Or take your local copy and use git-fu commands to create a bare repo of it that you can compress and put somewhere like S3. Then download it in CI and checkout from that.
Or just tarball your app source, who cares about git, and do the same (s3, give it a direct path to the asset)
All of this is potentialy useless info though. Hard to say without understanding how your CI works. If all you need is the source code, there are a half dozen ways to get that source into CI without git.
Presumably, manually running builds locally is an automatic failsafe option if you have the same people around who originally set the build pipeline up in the first place.
In 2021, basic business continuity plans for software companies should incorporate these sorts of concerns. You should have a published procedure somewhere that a person could follow for producing the final build artifacts of your software on any machine once backups are made available. Situations like these are why I check in 100% of my dependencies to source control as well.
Ideally your CI/CD is just calling Make/Python/Whatever scripts that are one shot actions. You should be able to run the same action locally from a clean git repo (assuming you have the right permissions).
The anti-pattern to watch out for is long, complex scripts that live in your CI system’s config file. These are hard to test and replicate when you need to.
Well unfortunately it seems everything I said 11 days ago has become a reality I'm afraid and I was still downvoted for pointing this truth out. [0]
Too many times I suggested everyone to begin self-hosting or have that as a backup but once again some think 'going all in on GitHub' is worth it. (It really is not the case)
Something I've learned on HN is that upvotes/downvotes means nothing but how popular an opinion is. You can be 100% right, honest, straightforward and kind, but if the hive-mind does not agree, it does not agree and will downvote your well-written opinion.
Don't read too much into it and comment freely as normal. In the end, it's just internet points.
Doesn't help that this occurred in the same week as a patent pending MS Patch Tuesday that borked a lot of corporate machines. I'm still cleaning up messes from the changes they pushed out that break Kyocera drivers.
When I built CI stuff at my previous job there were two remote repos that could be cloned from; Github and a repo on a system on the LAN that the CI's user has ssh access. Which one was used was controlled by a toggle-able environment variable in the CI system.
If I understand correctly, the .so TLD is effectively a national resource of Somalia, and as such they have total control over it and could in fact shut it down if they wanted.
> It is an uncommon status that is usually enacted during legal disputes, non-payment, or when your domain is subject to deletion.
Serious question, if this is an extended legal dispute or the domain is actually subject to deletion, that would be hugely damaging to the Notion brand right?
I ask because I can't think of another company that's had a similar issue lately, so I find the domain dispute an interesting issue that we rarely see get to this stage.
I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?