I keep waiting for something better than js/ts to do frontends so I dont have to learn it. I'm still waiting... I thought wasm would have gotten further along by now.
Back-end languages are coming to the front-end
141–150 of 328 posts
Re: Back-end languages are coming to the front-end
#142Can anyone clarify what this quote refers to: "what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn't get hung up on any single thread." What's this concept called? Is it simply a matter of setting a priority level on a certain task, that way the scheduler can make sure it doesn't block?
Preemptive scheduling, as opposed to cooperative scheduling. Basically: the scheduler can interrupt an erlang thread at any time, instead of a depending on threads to cooperate with the scheduler to see if they should stop. In go, for example, goroutines will only check with the scheduler at function calls, selects, and a few other things like that.
I believe the BEAM only interrupts after "reduction" limit is reached, and is after function calls end. The big difference is that everything is a function call, so there's frequent opportunity to be interrupted. There's no functionless for-loop iteration, for example. I think having that would be a big sticking point for scheduling
Re: Back-end languages are coming to the front-end
#143Earlier quoted context omitted.
> I did not mean to disparage it just because it was developed for a particular domain. Fair enough, that's all I was saying. I'd agree with you that the increased use of Node everywhere to build applications, with tools like Electron, is an utterly stultifying trend. It's fantastic for I/O-heavy 'server'-type code, and for using JS as an at least surprisingly performant interpreted language, but it's disappointing t…
It's fantastic for I/O-heavy 'server'-type code I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.
“More and more CPU processing” doesn’t sound like a CRUD API.
Re: Back-end languages are coming to the front-end
#144There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second g…
Did you read the article or just the headline?
Re: Back-end languages are coming to the front-end
#145Earlier quoted context omitted.
I actually appreciate domain-specific programming languages. It's fine (for me) that JS is the native front-end language. It's fine that Rust targets systems and embedded. I love that Python is a middle ground, and really great backends are built on it. I'm great with C being a really low level language that forces me to think about the machine. Taking "I'm productive in it so it is great" to an extreme, we end up se…
> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just ha…
> NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software.
Uhm, has V8 come anywhere near LuaJIT's performance by now? And LuaJIT is basically a one-man effort.
Re: Back-end languages are coming to the front-end
#146Earlier quoted context omitted.
As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.
Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money.…
Yes, but as engineers we should strive for the simplest possible approach that solves the problem in a maintainable way. Always choosing the most flexible / the most scalable / the most modern approach is often a waste of resources.
> why do I have to add a new paradigm? The answer to that question also depends on which paradigm you are using currently, not only on which you are choosing for the future.
Re: Back-end languages are coming to the front-end
#147Earlier quoted context omitted.
I actually appreciate domain-specific programming languages. It's fine (for me) that JS is the native front-end language. It's fine that Rust targets systems and embedded. I love that Python is a middle ground, and really great backends are built on it. I'm great with C being a really low level language that forces me to think about the machine. Taking "I'm productive in it so it is great" to an extreme, we end up se…
> Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3] NodeJS relies on V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner), and a spectacular piece of software. The v8.dev blog alone is fantastic reading for anyone who works on compilers, as I do. I don't like the 'dev' tendency in the programming community, to just ha…
It's my understanding that LuaJIT still beats V8 Javascript by a considerable margin. And I would say that Lua and Javascript are roughly comparable languages so it's an apples-to-apples comparison.
> V8, which is perhaps the world's most highly optimised interpreter (/JIT compiler/runner)
I don't think this is true. It's very popular but LuaJIT is still more performant.
Re: Back-end languages are coming to the front-end
#148Earlier quoted context omitted.
It's fantastic for I/O-heavy 'server'-type code I have found nodejs frustrating for CRUD APIs, the is 'fantastic for heavy I/O' while true ends up guiding you to complex microservices(or trying to use a external services for everything) because you don't want to slow down the event loop as you add more and more cpu processing to your app.
“More and more CPU processing” doesn’t sound like a CRUD API.
A CRUD API doesn't mean "just talks to the database and nothing more", a simple example and one of many is how PDF generation can f*ck up your event loop.
Re: Back-end languages are coming to the front-end
#149I keep waiting for something better than js/ts to do frontends so I dont have to learn it. I'm still waiting... I thought wasm would have gotten further along by now.
Pretty much any wasm language will require a JS runtime somewhere if you’re going to do substantial things with it, so might as well learn it either way.
Re: Back-end languages are coming to the front-end
#150I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames. JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF. GWT: main idea is to forget JavaScript/DOM and write pure Java. Turns out -- you really need to know Jav…
There was also https://liftweb.net in Scala…