What’s the point in writing huge server side applications in scripting languages?

What's the point of letting server side applications get huge?

Stupid question for a stupid question.

What's the point of anything we do?

@rantsauce uuh you just need coffee

Fine, everything now needs to be built by hand in binary using punchcards again, no excuses.

@C0D4 my question was serious, why you have to be so sarcastic about that? The choice isn't behind WriTiNg EvEryThIng In BiNarY or using very inefficient scripting language, there are a lot of reasonable choices in the middle like Java or Go, both are pretty easy to learn, both take care of the memory for you and both are significantly faster than scripting languages with the added benefit which many stupid bugs are usually caught early in a strongly typed compiled language.

@ElectroArchiver micro services aren’t the answer to everything, not every business in a Google and sometimes a big monolith just makes sense

@DEVil666 Lol, I never said anything about micro service, you completely missed the point.

@DEVil666 the simplest reason is, Time to live and cost to replace developers - for the most part.

@uNrEaL-jAsE that’s basically what I wanted to say, since we have straightforward compiled languages like Java or C# why should we write complex and demanding applications in slower and less structured languages like Python or JavaScript, they are still good languages but it’s far better to use the right tool for the job in hand

@DEVil666 Because it's possible.

I'm a firm believer in using the right tools for the job, but not everyone shares my belief. And I can accept that.

For some people, the easiest tool is the right tool. Because it makes them the most efficient.

It's also possible to use scripting languages for ease of development, but defer the heavy lifting to libraries written in compiled languages. That's how e.g. Python is used in AI/ML.

@rantsauce asking the real question here. What is the point of anything? If everything is futile then futility is futile. So I guess if nothing has a point then that itself is a point. It's like the same structure of 'if everything is a priority, nothing is' but reversed. 'If everything has no point, that's the point'

@uNrEaL-jAsE the only good reason I see for using JS on the server is if the application can benefit from a combined use of server side and client side rendering. If client side rendering is enough no need to endure JavaScript on the server, if server side is enough an old school solution (PHP, ASP…) may be faster and less painful to implement.

Man… These backends I’m sure that if the people knew beforehand how they would scale would have made different choices. But that’s not how it works. It’s also not how companies want to invest their time and money for most. Not everyone is Google/Microsoft etc.. not everyone wants to invest a year in remaking bits by bits their backends in a different paradigm, language, framework and so as opposite of YouTube that rewinds their UI every year because they don’t know what to do of their UX people companies prefer to invest in marketing and whatnot.

@DEVil666 I'm a c++ and python dev. Fairly experienced in both.

C++ is a lot faster to run. Python is a lot faster to write. The question is, which costs more, dev time or server time? Usually its dev time. For some stuff, interpreted languages aren't fast enough no matter how big your server is. Or real time stuff. Then you need the likes of c++. But for some random webserver doing CRUD? Python is fine.

Because a lot of big hits start as either someone's hobby project or a quick script to take care of a highly specific problem. For both purposes, any language that the author personally likes is appropriate. If an app is meant to be more than a toy or a small utility from the get go, if it's meant to be re-read more than a handful of times, or by someone other than the original author, static guarantees are always a good investment.

I personally prefer static guarantees because I don't want to care about typos or trivial logic errors, but for the purposes of a script only I will ever read they are more an external representation of my thoughts than a productive component. If someone else is working with the code as well it becomes pivotal that those thoughts have an external representation and that adherence to them is enforced automatically.

@DEVil666 Because there is such thing as “good enough”. Being slower than a compiled language might still be fast enough for many use cases.

the same point why some people use nipple clamps. they enjoy pain and humiliation

If this isn't about language performance (and it definitely shouldn't), then you got your question wrong. There are statically typed scripting languages and dynamically typed compiled ones (you count Java as compiled - so you have to count Erlang too). So whether the languiage is initially made to be interpreted or to write small scripts doesn't matter. The resulting language design choices are what matters. And even then, you can build and maintain huge applications in Python even though that language doesn't do any static type checking at all and is the slowest language on the market... In the end, it often just boils down to preferences of the lead dev.

define a scripting language for me

@kiki

Probably impossible to give an exact definition, but I always defined them as high level interpreted languages that offer "building blocks" often implemented on a low level language and REPL capabilities of if the box.

@atheist The question is how sustainable that is. It's not like energy is abundant anymore, we have entered the era of scarcity (and no, not just because of Putin and not just in Europe).

@Oktokolo It's still a huge waste of computing power to implement an application in market's slowest language when Java or C# would require just a little more effort. It's like designing a nice car and then building the chassis with lead pipes killing most of its speed and fuel efficiency.

@atheist Thanks for the answer!

@arcadesdude someone is inspired by the thought train of June from Zero Escape, I see.

@DEVil666 Huge is relative here. for most applications, there are multiple orders of magnitude between the influences of the application code and that of the libs called by that code.

In you car analogy it would be more like electroplating the chassis with a several µm thick layer of lead (normally, you would use zinc, but whatever). Technically, the car will use more fuel - but you have to measure it to actually see it...

@Oktokolo understood, thank you 😊

@vintprox never heard of that actually but it does seem to be the case that if you have a thought it has probably already been thought of before...

@CoreFusionX @DEVil666 and I have the definition. The main trait of a mature industrial language is fully-featured dependency management mechanism. Deps and imports should be top-notch. Precisely this makes a language suitable for backend.

JS graduated when ES Modules became the standard in Node and package-lock was introduced. In modern npm you can even resolve dependency conflicts.

This is why python is a scripting language, it occupies the prestigious niche of being modern perl and the best language to iterate over text files, parse them and analyze the data.

Modern Node standard library is almost offensively good. It even has crypto, with scrypt, top-grade randomness and stuff.

It is a big deal because OP rightfully mentioned huge systems. Well, to manage huge systems, you have to break them down into smaller parts, optionally outsourcing some of those parts to third-party libraries, and then make those parts work together.

It’s all about imports.

What would be the problem writing anything in a scripting language?

Performance? - You've gotta prove that it's an issue.

Even the slowest of the slow languages don't take more than a few hundred ms and if the server isn't responding to all requests in real time that might not be an issue - like if it's heavily cached.

Don't get me wrong, I am a sticker for performance.

But I've never had any issues with the serverside language remotely being a concern of a slowdown.

More likely it's some very specific thing, like how network calls are handled.

Even if we're talking 100.000 lines of the slowest language ever, as long as it's trivial code and not something computationally intensive or something working with huge number of items - what's the potential savings of rewriting it in another language? 90ms? Seriously, it's often lower than you'd expect and a single blocking network call could be more significant.

@jiraTicket Excluding very expensive things like simulations, language efficiency on the server side is usually not about the time between request and response, it's about cpu time per request, which directly translates to server costs. If serving a request takes 100ms which is 80ms waiting and 20ms computing, by optimizing the serverside calculations until this can be reduced to 90ms you have halved your server costs.

@jiraTicket If you can cut out a sluggish PHP behemoth such as WordPress entirely and replace that with a static site that basically is completely handled in the Nginx reverse proxy at the front, that shows you the upper limit of optimisation.

Let's say it's... massive. It also allows you to get away with cheap ass hosting while still being fast.