4 ms·

Eventually you realise this split sucks though. it creates a world where programmers of the higher level language can't reasonably debug their most important li

by jpgvm 4y ago

Eventually you realise this split sucks though. it creates a world where programmers of the higher level language can't reasonably debug their most important libraries. This is different from not being able to debug the runtime, which has a smaller API surface than important libraries and frameworks generally have (though I guess it depends on if you count stdlib etc sometimes). It's generally much better to simply go to a language that still operates at the same or similar level of abstraction but with higher performance. i.e going from Typescript to Kotlin isn't a substantial move from an abstraction level perspective but you no longer consider needing to write the code in C because it's not fast enough. (you might for other reasons, like runtime portability)

cercatrova 4y ago
How does that work if end users want to use JS though? They're not all going to move to Kotlin. Since one must meet people where they are, rather than where we want them to be, the best we can do is instead have the end user still program in whatever language they want but then translate that into a higher performance language. That's basically what Python is doing now. Users don't want to write C/C++, they want to use Python, but Python is too slow, so here we are.
- jakobnissen 4y ago
  What you're describing is known as the "two language problem". The long-term solution is to move to fast, high-level languages. I think Julia and LuaJIT are the only examples currently, but surely more will crop up. This is s fundamental problem that will not go away on its own. Efforts like Numba can alleviate some of the pain of a slow Python, but it turns out it's generally not possible to retroactively fit a JIT compiler onto a language designed not designed to be compiled. In my experience, once I tried moving my work code to Julia, it became clear to me just how much energy I had spent trying to overcome the performance wall of Python, and I can't imagine going back now.
  - v3ss0n 4y ago
    Python have PyPy and it's underrated. Imagine 7-20x performance boost without changing a line of code.
    - jakobnissen 4y ago
      IIUC, the performance of PyPy is still quite far behind normal compiled languages, due to limitations inherent in Python. And then it has limitations in its interop with Numpy and C libraries, at least last I checked. That's the general picture when trying to overcome Python's performance wall: Sometimes you can use Cython, or Numba, or PyPy or Numpy vectorization, or call into C. But only sometimes, and they each come with their own set of awful restrictions and caveats. It's such a breath of fresh air to switch to a fast language and just forget all those hacks and workarounds. I get why people just migrate to static languages
  - zem 4y ago
    second time this week i've had occasion to mention lush[1], which was in many ways an early attempt at what julia is doing now. from their homepage: 8<-------------------------------------------- Lush brings the best of both worlds by wrapping three languages into one: (1) a weakly-typed, garbage-collected, dynamically scoped, interpreted language with a simple Lisp-like syntax, (2) a strongly-typed, lexically-scoped compiled language that uses the same Lisp-like syntax, and (3) the C language, which can be freely mixed with Lush code within a single program, even within a single function. It sounds complicated, but it is not. In fact, Lush is designed to be very simple to learn and easy to use. 8<-------------------------------------------- [1] http://lush.sourceforge.net/ http://lush.sourceforge.net/
fnord123 4y ago
'It's the platform, stupid.' The language is secondary to the platform. Having fast libraries is great. No one ever wishes that numpy was written in python. And switching from typescript to kotlin? That's changing platforms. If you're in the browser or in node and replace it with the JVM? That's a wild suggestion to avoid some fast libraries. Imo you're just wrong.
- DrScientist 4y ago
  Totally agree with the 'It's the platform, stupid'. However, I do wonder if for javascript/typescript that's only for 'in browser' stuff. If you look at the server - one of the best platforms is the JVM - lots of quality libraries - easy to write stable long running processes etc. ie if you are driven by platform isn't it Javascript on the browser and Java on the JVM on the back? ( typescript or kotlin are both moving a bit away from the platform ). The beauty of the network ( message passing ) means the stuff on the server doesn't need to be in the same language as that on the client. Now I'll admit there is some benefit to having front and backend the same, in terms of validation code, or perhaps occassionally moving logic from server to client or back - but does this override the platform effect? Also note you can run js on the JVM/GraalVM - so client/server validation libraries could be written in js and reused both sides.
  - AYBABTME 4y ago
    JVM is not good for tooling, at least not in comparison to Go or Rust, which are both faster to write, easier to distribute and faster to execute for short lived CLI invocations.
- myko 4y ago
  Like many other languages targeting the web Kotlin will "compile" to JS and is deployable to the web.
lucasyvas 4y ago
I would argue this means the users of the higher level language need to learn the language their tooling is written in, or consider switching to the underlying compiled language altogether where possible. My entire career has been with scripting languages, but I think the pendulum is swinging again and they are back on notice. Anything that isn't strictly a scripting need is orders of magnitude more ergonomic to do in a compiled language than it was a decade ago. Why fight it? I'm still watching the developments of WASM closely, because while JS does the trick and always will, if you can build an app in a language that produces an equal or better result in WASM, why wouldn't you consider it from an engineering point of view? Then there would no longer be a language split. There's a lot of "ifs" here for sure, but the possibility exists that the languages we currently use are not the best for the task. I think when we see projects like this, it's a good opportunity to reflect.

by jpgvm 4y ago

cercatrova 4y ago

How does that work if end users want to use JS though? They're not all going to move to Kotlin. Since one must meet people where they are, rather than where we want them to be, the best we can do is instead have the end user still program in whatever language they want but then translate that into a higher performance language. That's basically what Python is doing now. Users don't want to write C/C++, they want to use Python, but Python is too slow, so here we are.

jakobnissen 4y ago
What you're describing is known as the "two language problem". The long-term solution is to move to fast, high-level languages. I think Julia and LuaJIT are the only examples currently, but surely more will crop up. This is s fundamental problem that will not go away on its own. Efforts like Numba can alleviate some of the pain of a slow Python, but it turns out it's generally not possible to retroactively fit a JIT compiler onto a language designed not designed to be compiled. In my experience, once I tried moving my work code to Julia, it became clear to me just how much energy I had spent trying to overcome the performance wall of Python, and I can't imagine going back now.
- v3ss0n 4y ago
  Python have PyPy and it's underrated. Imagine 7-20x performance boost without changing a line of code.
  - jakobnissen 4y ago
    IIUC, the performance of PyPy is still quite far behind normal compiled languages, due to limitations inherent in Python. And then it has limitations in its interop with Numpy and C libraries, at least last I checked. That's the general picture when trying to overcome Python's performance wall: Sometimes you can use Cython, or Numba, or PyPy or Numpy vectorization, or call into C. But only sometimes, and they each come with their own set of awful restrictions and caveats. It's such a breath of fresh air to switch to a fast language and just forget all those hacks and workarounds. I get why people just migrate to static languages
- zem 4y ago
  second time this week i've had occasion to mention lush[1], which was in many ways an early attempt at what julia is doing now. from their homepage: 8<-------------------------------------------- Lush brings the best of both worlds by wrapping three languages into one: (1) a weakly-typed, garbage-collected, dynamically scoped, interpreted language with a simple Lisp-like syntax, (2) a strongly-typed, lexically-scoped compiled language that uses the same Lisp-like syntax, and (3) the C language, which can be freely mixed with Lush code within a single program, even within a single function. It sounds complicated, but it is not. In fact, Lush is designed to be very simple to learn and easy to use. 8<-------------------------------------------- [1] http://lush.sourceforge.net/ http://lush.sourceforge.net/

fnord123 4y ago

'It's the platform, stupid.' The language is secondary to the platform. Having fast libraries is great. No one ever wishes that numpy was written in python. And switching from typescript to kotlin? That's changing platforms. If you're in the browser or in node and replace it with the JVM? That's a wild suggestion to avoid some fast libraries. Imo you're just wrong.

DrScientist 4y ago
Totally agree with the 'It's the platform, stupid'. However, I do wonder if for javascript/typescript that's only for 'in browser' stuff. If you look at the server - one of the best platforms is the JVM - lots of quality libraries - easy to write stable long running processes etc. ie if you are driven by platform isn't it Javascript on the browser and Java on the JVM on the back? ( typescript or kotlin are both moving a bit away from the platform ). The beauty of the network ( message passing ) means the stuff on the server doesn't need to be in the same language as that on the client. Now I'll admit there is some benefit to having front and backend the same, in terms of validation code, or perhaps occassionally moving logic from server to client or back - but does this override the platform effect? Also note you can run js on the JVM/GraalVM - so client/server validation libraries could be written in js and reused both sides.
- AYBABTME 4y ago
  JVM is not good for tooling, at least not in comparison to Go or Rust, which are both faster to write, easier to distribute and faster to execute for short lived CLI invocations.
myko 4y ago
Like many other languages targeting the web Kotlin will "compile" to JS and is deployable to the web.

lucasyvas 4y ago

I would argue this means the users of the higher level language need to learn the language their tooling is written in, or consider switching to the underlying compiled language altogether where possible. My entire career has been with scripting languages, but I think the pendulum is swinging again and they are back on notice. Anything that isn't strictly a scripting need is orders of magnitude more ergonomic to do in a compiled language than it was a decade ago. Why fight it? I'm still watching the developments of WASM closely, because while JS does the trick and always will, if you can build an app in a language that produces an equal or better result in WASM, why wouldn't you consider it from an engineering point of view? Then there would no longer be a language split. There's a lot of "ifs" here for sure, but the possibility exists that the languages we currently use are not the best for the task. I think when we see projects like this, it's a good opportunity to reflect.