Kotlin is like TypeScript(gi-no.github.io) |
Kotlin is like TypeScript(gi-no.github.io) |
Scala has it too indeed, but it's not the default mode and feels awkward, also has known limitations.
The nice thing with typescript is that structural typing makes sense for 90% of the use cases, and for the remaining 10%, you can very easily simulate nominal typing by adding a field like so:
interface Robot { __Robot: true }
I would much prefer if they just added a new keyword to the language, instead of hacks like this.
name: string;
constructor(name: string) {
this.name = name
}
constructor(public name: string) { }
And the TypeScript ones have the value `undefined` (unfortunate that strictNullChecks doesn't catch things like that https://github.com/Microsoft/TypeScript/issues/8476).
And for some nitpicking, please be consistent with your semicolons, either use them or don't use them, but don't mix it randomly like that.
This is one of the more annoying problems with our industry. People rediscover solutions from 60s and 70s and sell them as if they were new and revolutionary...
Modern? Are you serious?
"All these new languages with C-derived syntax and automatic memory management are pretty much the same -- so pick the one that is most supported on your target platform, get to work, and don't worry about it."
I'm kind of expecting someone to do a "Meta-Kotlin" next: a language that has the common intersection of features from Swift, Kotlin, C# and TypeScript, and offers tidy code generation for any of these.
Curious how they would relate all the features Go lacks.
const x = 1
val x = 1
var x = 2
It's unfortunate each language has a different keyword for constants and variables.
Kotlin is like TypeScript
that infer
TypeScript is like Swift
am I getting right? or Is there anything else?
Is go like scala?
Everything is C (or lisp).
With the popularity of things like React, you now have a powerful way to express how the UI looks in every state, not just the initial one.
Step 1: People realise that Electron apps look different and do not fit the OS.
Step 2: Big company invests and creates a library that supports Win/OSX looks.
Step 3: Same big company creates a RAD type tooling for it.
We present you a revolution - Big Corp. RAD Tooling 2020 a la Borland Delphi 2007.
This is not an issue for most people. I like to use Spotify (the desktop app) as an example - it's a pretty good looking app, works nicely, and yet it uses an HTML-based UI.
Microsoft's own UWP also looks vastly different than native Win32-based apps.
The resource usage and slowness of Electron apps is a problem, but that is caused by using the entire browser runtime. When it comes to the capabilities of a UI framework, one of the questions I ask is "Could you build something like Spotify's UI with this? How difficult would it be?".
I guess the question boils down to whether a single tab in a browser which is properly managed by OS can compete with a good old native desktop app.
So far the facebook stack and react-desktop seems to be the best candidate for that description, but I don't neceserily think people would focus on getting it to the desktop styling. Universal Material UI (or similar?) probably would overtake that approach.