Are Fast Programming Languages Gaining in Popularity? (techrepublic.com) 158
In January the TIOBE Index (estimating programming language popularity) declared Python their language of the year. (Though it was already #1 in their rankings, it had showed a 9.3% increase in their ranking system, notes InfoWorld.) TIOBE CEO Paul Jansen says this reflects how easy Python is to learn, adding that "The demand for new programmers is still very high" (and that "developing applications completely in AI is not possible yet.")
In fact on February's version of the index, the top ten looks mostly static. The only languages dropping appear to be very old languages. Over the last 12 months C and PHP have both fallen on the index — C from the #2 to the #4 spot, and PHP from #10 all the way to #14. (Also dropping is Visual Basic, which fell from #9 to #10.)
But TechRepublican cites another factor that seems to be affecting the rankings: language speed. Fast programming languages are gaining popularity, TIOBE CEO Paul Jansen said in the TIOBE Programming Community Index in February. Fast programming languages he called out include C++ [#2], Go [#8], and Rust [#13 — up from #18 a year ago].
Also, according to the updated TIOBE rankings...
- C++ held onto its place at second from the top of the leaderboard.
- Mojo and Zig are following trajectories likely to bring them into the top 50, and reached #51 and #56 respectively in February.
"Now that the world needs to crunch more and more numbers per second, and hardware is not evolving fast enough, speed of programs is getting important. Having said this, it is not surprising that the fast programming languages are gaining ground in the TIOBE index," Jansen wrote. The need for speed helped Mojo [#51] and Zig [#56] rise...
Rust reached its all-time high in the proprietary points system (1.47%.), and Jansen expects Go to be a common sight in the top 10 going forward.
In fact on February's version of the index, the top ten looks mostly static. The only languages dropping appear to be very old languages. Over the last 12 months C and PHP have both fallen on the index — C from the #2 to the #4 spot, and PHP from #10 all the way to #14. (Also dropping is Visual Basic, which fell from #9 to #10.)
But TechRepublican cites another factor that seems to be affecting the rankings: language speed. Fast programming languages are gaining popularity, TIOBE CEO Paul Jansen said in the TIOBE Programming Community Index in February. Fast programming languages he called out include C++ [#2], Go [#8], and Rust [#13 — up from #18 a year ago].
Also, according to the updated TIOBE rankings...
- C++ held onto its place at second from the top of the leaderboard.
- Mojo and Zig are following trajectories likely to bring them into the top 50, and reached #51 and #56 respectively in February.
"Now that the world needs to crunch more and more numbers per second, and hardware is not evolving fast enough, speed of programs is getting important. Having said this, it is not surprising that the fast programming languages are gaining ground in the TIOBE index," Jansen wrote. The need for speed helped Mojo [#51] and Zig [#56] rise...
Rust reached its all-time high in the proprietary points system (1.47%.), and Jansen expects Go to be a common sight in the top 10 going forward.
Resetting Easy and Fast (Score:5, Interesting)
The bigger question is whether we can reset the compromise between fast and easy to learn.
People want to use the expressive features and paradigms of languages like Python but all things being equal would prefer the code to go faster.
What is interesting with the newer generation of languages like Rust, Go, or even Julia is that they offer speed without the lower level feel of C. If you can have both why wouldn't you?
Re:Resetting Easy and Fast (Score:5, Insightful)
People want to use the expressive features and paradigms of languages like Python but all things being equal would prefer the code to go faster.
Most programmers don't want expressive features. They want to use the language they already know. That's why we have Javascript washing machines [moddable.com]. If it were about speed, they wouldn't use Javascript. If it were about ease of use, they wouldn't use Javascript.
If it were about elegance...most programmers can't even recognize elegance, let alone produce it.
Re:Resetting Easy and Fast (Score:5, Interesting)
Indeed, as usual the answer to TFS question is no. There are just more non-programmer people patching code together nowadays. I still use bash for those quick and dirty tasks and real programming languages for serious stuff. Bash is amazingly low footprint and efficient compared to python and the likes.
Re:Resetting Easy and Fast (Score:5, Informative)
I completely agree. I use bash and sometimes Perl or Python for simple things, and C and Python for more complex ones, C when they need to be fast. I have probably used 15 languages or so for real work, but these are the ones I go back to when the selection is mine.
One of the distinguishing marks between a coder that can just scrape by and a good one is that the good one has several different languages they can and have done real work in. Because to write good code, you have to select a language that fits the task. One-trick ponies cannot do that.
Re: (Score:3)
Seriously?
Python is probably 100 times faster than Bash.
And no one is doing big data, or gigantic matrix manipulations in Bash anyway.
Re: (Score:2)
+1
Re: (Score:3)
That applies to languages we know, the popularity contest by definition seems to follow languages we don't. As the old guard age out of the industry and the young kids come in, the languages we know change.
I note your washing machine runs on Javascript and not COBOL.
Re: (Score:2)
That applies to languages we know, the popularity contest by definition seems to follow languages we don't.
I don't understand what you're trying to say here.
Re:Resetting Easy and Fast (Score:4, Interesting)
Because the ranks are based on searches, and you don't need to google things you don't already know, the rankings are biased towards students and languages that people don't know already.
Re: (Score:2)
Nope. Wrong. (Score:4, Insightful)
People didn't start using JavaScript because they knew it, they used it because it was the PL available in Browsers. That it was/is easy is a good reason to keep on using it. That it was open source was a good reason to built a FOSS runtime for the server, so web folks could use a single PL on both ends.
Todays washing machines and IoTrash offers JS because JS has the most developers for the cheapest price and usually it's those deciders who ask for IoTrash that have cheap Web developers around and ask them to do IoT. With the usually disastrous security consequences do to shittyweb n00b progging.
Re: (Score:2)
Re: (Score:2)
People only want programs to go faster when they are not already going fast enough.
Which of the apps you use do not run fast enough, that are not slow due to hardware speed limits, like AI bots, file searching or apps that use the net ?
Re: (Score:2)
Microsoft Windows Explorer.
My simple file viewer in dart is so much faster, you can not measure it.
How a file explorer needs a second to display an empty open window, and then 1 or 2 more, to fill it: no idea.
Re: (Score:2)
In the meantime, try Everything: https://www.voidtools.com/support/everything/
Re: (Score:2)
We often talk about using "the best tool for the job", but then we don't do a great job supporting people using "the best tool for the job".
Re: (Score:2)
> People want to use the expressive features and paradigms of languages like Python but all things being equal would prefer the code to go faster.
Memory is still in play, we mostly deal with hungry programs by adding more rams but we could solve some of that with different languages that don't allocate so much.
Perl/Python, they both use lots of memory. The sad thing is nobody really cares about browser ram these days.
Re: (Score:3)
If you need performance, RAM use becomes paramount because of caches and memory bandwidth. One of the main advantages of C is that is allocates almost nothing in the background and you can use exactly the bytes you want in the place you want them. "Cache-aware" coding and coding that respects memory burst size can give you a lot of additional performance.
Re: (Score:2)
Re: (Score:2)
Have you somehow overlooked the story this is in relation to?
Re: (Score:2)
Well, often libc brks more than you asked for, only if you malloc outside of what was previously requested does it make another brk.
A hashmap/dictionary in dynamic languages often preallocates magnitudes more too. It makes sense for virtually all languages to do this as it reduces the context switches to call brk etc.
I am ok with all of this, as it's there for good reason and reduces context switches, which I think became more expensive with meltdown-era mitigations.
Re: (Score:2)
Sure. But one thing you quickly find when doing actual high performance code is that you need to do your own memory management. And then it stops mattering what some libc functions do. The important thing is what gets put on the stack and what is passed on calls, because you cannot really avoid that. Heap management? That you have to do yourself anyways.
Re:Resetting Easy and Fast (Score:4, Interesting)
> People want to use the expressive features and paradigms of languages like Python but all things being equal would prefer the code to go faster.
Memory is still in play, we mostly deal with hungry programs by adding more rams but we could solve some of that with different languages that don't allocate so much.
Perl/Python, they both use lots of memory.
I'm not gonna say memory doesn't matter or anything, or even that it's not relevant to speed, but it's not very relevant to speed.
I have 64GB in my desktop, it wasn't even expensive, and it's plenty fast. So while yeah I prefer efficiency, free RAM isn't holding me back any more. I don't even have swap. Everything but my bulk storage is on SSD and I don't want to wear it unnecessarily.
Perl is 4-10 times the speed of Python depending on what you're doing, even though they both use a lot of RAM, so the RAM usage is really not what's important here for the kinds of tasks people should be using scripts for. Python is just super slow.
Re: (Score:2)
RAM is relevant to speed for almost everything. Even a basic survey of servers will tell you that more processes handling connections equates to better throughput of the system. Quite often the first bottleneck is the number of daemons. After that, more redis/memcache means going to the disk storage less often.
When it comes to caching, a lot of people would rather use redis and memcache for something similar to web, where a cross-process cache is available. RAM dramatically increases this type of task, but
Re: (Score:2)
I've often found Perl to be more memory and CPU hungry than Python. However, Perl often does in fewer lines what Python does (e.g. string regex).
Memory use is irrelevant when a) you have the memory around because you need it for other reasons and b) it's clearly not the speed bottleneck.
I come from a simpler time when people counted bytes, and yeah, it's amazing how much we did with so much less RAM. But it's even more amazing how ram is cheaper per GB now than it was per MB then.
Re: (Score:2)
Whilst I agree, it's wrong to assume that many people fall into the 64GB desktop crowd. It is often the bottleneck though, unless you're doing compute, in which case, static typed languages prevail. Or something like perl/python with calls to a static typed language for those hot zones.
I'd much prefer to put as much web content into cache as possible. How much web is served directly, or in part, from php op/memcache/redis/varnish? Quite a bit I'd hope for the set that exists in dynamic.
With regards to how m
Re: (Score:3)
There are clearly times when it matters, but we are almost to the "My microwave runs Unix" point. It eventually becomes cheaper to throw more transistors at a problem just because of the cost of development, especially as the length of product cycles shrinks. It blows my mind that we have these dual ARM MCUs all over the place for pennies now even though I was expecting it. They have more power (though not yet more RAM) than systems I used to use with dozens of other people at the same time.
Re: (Score:2)
True, but that goes in two directions. The people programming the libraries may well say "meh, they can add more RAM to solve that", just as the operator might. In the end neither programmer nor operator wants to solve a RAM bottleneck by making the software efficient, yet somehow throughput on a VM drops because only 16 connections can be handled at once, because 200MB of RSS for a single PHP page load is ok. Not efficient.
Re: (Score:2)
I do not think so. Fast depends to a large part on education, experience and skill of the coder. Languages can hinder fast, but they cannot assure fast. The basically just can avoid standing in your way. But then you are with C and maybe Rust. C++ requires you to restrict OO use to be fast (because of the demented virtual function dispatch and not very good OO in the first place; look at Eiffel or Python how to do OO right and efficient) and that is just deranged.
And when it comes to "easy to learn" Rust is
Re: (Score:2)
You hardly can do virtual dispatch faster than in C++.
And neither Python not Eiffel do it faster.
If I recall correctly: Eiffel uses the same dispatch as C++ anyway.
void fun() { /* do nothing */ }
This is an empty method, faster a method can not be.
Call it virtually, and the runtime cost is 1.7 on an old processor.
On a modern processor the overhead is zero. Because of the long pipeline, the table look up is hidden.
Faster dispatches are only possible if the amount of virtual methods is low and you can squeeze it into a switch. Look at Rust,
Re: (Score:2)
Re: (Score:2)
There is no compromise between fast (compiled code) and easy to learn.
Languages like C++ or JCL or APL are outliers.
Not only Python is easy, most languages are, if they did not evolved into monsters, like C++.
For example Pascal, object Pascal like Delphi and Free Pascal are still strong.
Oh, why do they not pop up on TIOBE? Because they are easy! And the documentation is good.
If Python is to slow consider Mojo, or check if what you are doing is not already in a C library.
Most slow languages are not slow, e.g
Re: Resetting Easy and Fast (Score:2)
Re: (Score:2)
There is no "compromise" between fast and easy.
Among compiled languages, "fast" is a product of the amount of performance tuning done in the compiler-generated code. For example, C# is fairly easy to learn, and is also nearly as fast as C++ for most operations.
JavaScript is *not* easy to learn, it has many gotchas and dark corners, and is also relatively slow, due to its lack of real data types and being an interpreted language.
Re: (Score:2)
The tradeoff is less about easy to learn than about easy to write correct code in.
Python is very easy to write code in, but it runs very slowly. It's also a 35 year old language.
C is easy to write code in, but very hard to write correct code in. The language is a minefield of chances to make mistakes. It's over 50 years old.
Modern languages like Kotlin and Swift manage to be pretty fast, though not as fast as C, while providing a lot more safety. For most projects, this is the sweet spot.
Rust is notable
no lol (Score:5, Insightful)
Confucius called it out two thousand five hundred years ago: "The superior man thinks always of virtue; the common man thinks of comfort." Getting out of even the smallest comfort zone (of a programming language) is too hard for most programmers.
Speed does matter (Score:2)
You wouldn't use a website where you had to wait 2 mins for the front page to load. The difference is that the speed is Good Enough for most people even using inefficient languages like JS or Python because the hardware now both client and server is so damn fast.
However efficiency also matters these days when literally entire power stations are being dedicated to running single data centres but unfortunately that seems to be taking a back seat. Perhaps writing more backend server code in C++ instead of Pyth
Re: (Score:2)
Perhaps writing more backend server code in C++ instead of Python or Java would be a good start but I won't hold my breath
Python or Java? Please leave your geek card on your way out. I don't think both fit together in your sentence /s
Re: (Score:2)
I doubt you ever had one if you don't think Python is used in server side code and/or that Java is also inefficient compared to C++.
Re:Speed does matter (Score:5, Funny)
Server side java beats C++ anytime unless you want to repeat the concept and re-create everything manually with a long lived process in C++, implementing your own caches, forking threads, optimizing loops etc. etc. By the way, the java JVM is written in C and does all that already for you so there you go.
Throw in some RAM and you are good to go and RAM is cheap nowadays. Java is relatively slow to load and to build JIT data and cache but after a short while your server side code will rock and be difficult to beat if you know anything about writing efficient code. Your whole server side use case will use only 1 long lived process, that's it.
And yes, I have customers running server side python, one even fork a new python process for every request taking about 1GB of ram each (3D visualization) LOL! So, I queue the requests at the reverse proxy and let only 10 request run simultaneously on the backend server. It kind of work but it is very inefficient. Granted it could be faster if he used python tools that would allow him to avoid forking a new process for each request but python was way behind java regarding JITs and runtime optimizations last I looked. Also, thread support in python is still weak compared to java.
Re:Speed does matter (Score:5, Insightful)
"Server side java beats C++ anytime"
You must get throught that kool-aid fast.
"forking threads"
LOL :) Oh dear.
"By the way, the java JVM is written in C "
So what? Do you understand how JVMs work?
Clearly you've never used modern C++ and know nothing about it , so lets just chalk your response up to total cluelessness and leave it at that shall we?
Re: (Score:2)
You must get throught that kool-aid fast.
No need to resort to insults and shaming you know. I am simply sharing my experience hosting many server-side applications for 25 years written in many various programming languages and I write code too. Before that, I wrote C and assembly for 20 years.
I also have been contributing to various JVM optimizations since 1998 so yes, I must at least have a clue on how different JVM flavors work.
Re: (Score:2)
Yet you're unaware of how the Java JVM even with JIT sucks balls compared to a native binary. Whatever.
Java sucks...but everyone else sucks more. (Score:2)
Everyone loves to hate on Java, but always comes back...Java sucks?...sure, I guess so...it's just everyone else sucks more. Java has strengths and weaknesses, but for business programming, it has far more strengths than weaknesses.
It has great libraries, the world's largest and best talent pool, all the major proj
Re: (Score:2)
Server side java beats C++ anytime unless you want to repeat the concept and re-create everything manually with a long lived process in C++, implementing your own caches, forking threads, optimizing loops etc. etc.
You're not arguing about a language, you're arguing about libraries. They are different.
Re: (Score:2)
Most of the JVM is written in C++.
Only masochists would write such a big thing in C.
The only C parts are the FFI/JNI Java-C bridge.
Re: (Score:2)
Server side java beats C++ anytime unless you want to repeat the concept and re-create everything manually with a long lived process in C++
Youngling, I remember reading that 30 years ago when Java was new, and it's STILL being regurgitated. In reality, most every language has very well-written and optimized libraries available to do those things. If you have some custom loop you need to implement in the language, like iterating through a bunch of data, then you're just as responsible for not doing stupid things in that loop in Java as in C++. The advantage with other languages like C++ is you can manually manage your memory to make sure you ar
Re: (Score:3)
You wouldn't use a website where you had to wait 2 mins for the front page to load. The difference is that the speed is Good Enough for most people even using inefficient languages like JS or Python because the hardware now both client and server is so damn fast.
You would have a point if programmers were taking efficiency into consideration at all when choosing their programming languages. Most don't. Most programmers don't know how much faster C is than Python, for example, since they've never measured.
The primary criteria programmers use to choose a language is "what I am comfortable with." That's entirely why this guy chose Python [slashdot.org]. He says "it's convenient" but the unredacted portion is "it's convenient [because I already know it and learning new things is un
Re: (Score:2)
To be fair most programmers in a job setting don't have a choice what they have to use, but yes , most Python coders don't have a clue just how slow their favourite language is because the majority of them have never used anything else. I've used both Python and C/C++ for years and I'd never use Python for any CPU bound backend work. Similarly I'd rarely use C/C++ for any short scripts that are mainly I/O bound, eg DB reports etc.
Re: (Score:2)
Re: (Score:2)
"Cognitive discomfort" is an awesome phrase. I am going to steal that one for future use.
Re: (Score:2)
Re: (Score:2)
Thanks, I like it.
Re: (Score:2)
Are you still here posting your embarrassing straw man crap? Good for you! Every mental ill person should have a dream and a goal. Yours is to "win the internet".
Re: (Score:3)
You wouldn't use a website where you had to wait 2 mins for the front page to load. The difference is that the speed is Good Enough for most people even using inefficient languages like JS or Python because the hardware now both client and server is so damn fast.
Better is always the enemy of good enough. With current hardware, there is as you point out, no real need to spend time optimizing code or looking for a faster solution when you can easily program one that works. I first learned to program where every byte mattered, so writing elegant, efficient code made a difference. Now, I trade a few extra lines for readability so when I look at it a year later it's easier to understand what I did; and Python is good enough for what I do.
However efficiency also matters these days when literally entire power stations are being dedicated to running single data centres but unfortunately that seems to be taking a back seat. Perhaps writing more backend server code in C++ instead of Python or Java would be a good start but I won't hold my breath.
Certainly, in some situations
Re: no lol (Score:3)
I am an old hardware engineer. Squeezing out delays of circuits. Celebrating when we pinched off a nanosecond of something stupid. As a hobby I program microcontrollers these days, in C and assembly. (Simple stuff programs of a few 100 bytes). Looking at my first decompiled C code was shocking. The poor microcontroller was s
Re: (Score:3)
"Putting everything in many functions was not a good idea here"
So use "inline" then, problem solved.
"I wonder what a breakdown of executing python code would reveal."
Most of the CPU cycles being burnt up interpreting the intermediate code rather than doing actual work which is why Python is so horribly inefficient.
Re: no lol (Score:2)
TBH (Score:2)
Python is more of a half-fast language.
Back in the old days, we used to joke about fixing some broken code by inserting a space or two and trying a compile again. Little did we know that this was actually a prophecy.
Re: (Score:2)
You might enjoy getting in there with a profiler and seeing how long things take.
Re: no lol (Score:2)
Re: (Score:2)
Re: (Score:2)
Microcontrollers tend to have memory that runs at full core speed. He said his programs are in the hundreds of bytes, so he probably isn't even having to add slower external memory, and memory latency won't be something he has to think about.
Optimising assembly is complicated (Score:3)
You're working with microcontrollers, which are presumably single-issue in-order designs. I was recently working on a piece of software that generates code on the fly, and I was adding code to inline and special-case a performance-critical operation. At first I was getting worse performance for my generated inlined special-cased version than the out-of-line compiled C++ implementation. It turned out I was getting my arse handed to me by pipeline latency, and I had to rethink the order I was doing things.
Re: (Score:3)
I first learned COBOL (books only) then BASIC, then assembly language, then Pascal and Fortran (the last two at university)
I worked in Pascal first, then 5 years later discovered C. Took me a while to get used to it, but I'm still happy with it.
Re: (Score:2)
Not quite true. You can do things like prototype in Python and then transfer parts or all of it in C. Gives you a very nice way to test the C code as well, by comparing output. Hence yes, the final product will be all or mostly C, but that does not mean Python cannot have a role in writing fast code. Personally, I did this several times with great success.
I do agree that most people are bad coders and stay one-language wonders. In fact, I would go so far that a coder that has not at least done real work in
Re:no lol (Score:4, Insightful)
You're begging the question. Javascript isn't slow. It's actually incredibly fast. The modern browser has optimised it to an incredible degree.
What is slow is idiots using javascript. But that works in any language. The kind of programmer who in assembly creates a delay by having the CPU execute NOP repeatedly and synchronously bogging down the poor thing despite well written assembly being objectively the fastest language.
The problem is websites are written by the cheapest kid a rouble or two can buy. That's what makes javascript look slow.
Re: no lol (Score:2)
You can thank the C/C++ software engineers who wrote the JavaScript scripting engines for you.
Re: (Score:2)
Javascript outperforms C at anything async.
That's something you just made up, because you sure don't have numbers to support it.
But that's beside the point. Would you recognize elegant code if you saw it? Most incompetent programmers can't recognize elegance, let alone produce it.
Meh (Score:5, Insightful)
Re: (Score:2, Insightful)
Slashdot is what you make it. If you think this index shouldn't be on here, post a better more appropriate story instead. The green button at the top of the screen labelled "submit".
I remind you that there are some people here who are anti-vax, pro-Putin, and think China unleashed COVID on the world on purpose. That's the kind of people on Slashdot, and they all have the ability to press that button at the top. Want something better? It's up to you to drown out the noise.
Different underlying trends (Score:5, Interesting)
There always have been properly compiled languages, bytecode languages and completely interpreted languages. Depending on your application you select one over the other. That's why, for example, PHP is mostly used for websites. Very few people use PHP for embedded devices for example.
We use computers for many things, and each area has it's own programming languages. The TIOBE index essentially represents a lump sum of that.
It is the opposite... (Score:2)
We already have good enough slow languages like Python and Javascript - no real gain in creating/learning another one...
so the progress only makes sense in the area they lack - fast compiled languages...
And they are still not even close to Python convenience...
Awful.. (Score:3, Interesting)
Re: Awful.. (Score:2)
It is. I started as a python 1.5 fan was with it for years and hate it now. Nothing cleaner existed at its start for the little quick scripts itâ(TM)s good at, it was exciting. But now, everything is in it, and to do anything big, everyone uses Pydantic basically to create the same strongly typed classes Java or C++ use, at a way slower speed.
Re: (Score:2)
I am with you brother, it is good for simple things but the indenting for codeblocks and gymnastics for magic methods and mixed programming paradigms.
I use C most of the time and BYTHON is something I want to check out.
def print_message(num_of_times) {
for i in range(num_of_times) {
print("Bython is awesome!");
}
}
if __name__ == "__main__" {
print_message(10);
}./qu
Re: (Score:3)
If you find Python awful, then you are not a programmer, but an idiot.
What has "really need to think" to do with anything?
Python programers do not have to think? They touch the keyboard and the code pops up by nothing?
Oh, wait? They do not need to touch the keyboard? The code by thought only?
Oh noes! That would be an oxymoron! Moron.
Re: Awful.. (Score:2)
Re: (Score:2)
Re: (Score:2)
Python is good for all kinds of simple quick and dirty things. It's a good swiss army knife. Would I do everything with it? No. But for all kind of single run things, or utilitarian things. That works reasonably well.
Mypyc - The best of both worlds? (Score:3)
https://github.com/mypyc/mypyc
Fast is good, but... (Score:5, Informative)
The software I develop runs on a TOP100 system [top500.org]. The development process starts from pen and pencil to work out equations, study how they behave, and find possible computational troubles (singularities, loss of precision, best way to set up a parallel execution, etc.). Then we move to python for a prototype, to be run on a small dataset, where "small" it means a few GB of data. The troubles with python is that it is slow, somehow cryptic, and you walk on quicksands, since library functions, constructs, and other stuff becomes soon obsolete. Running a test usually takes day, due to the performance of the python engine (I know, there are tons of libraries for unleashing parallel processing with python, but the libraries are often unmanaged, and compatibility problems with other libraries often arise. Been there, done that, no more).
Once the python code is accepted by our managers and technologists, we then move to C++. I learned C++ in 1998, then followed its evolution till C++20, when I had enough...memorizing and putting at good use all the new features is a mess, it is really too much to remember. Our solution has been to move towards libraries like Boost [boost.org] and especially Armadillo [sourceforge.net], but again there is the problem: will these libraries survive to the evolution of C++ ? We had to rewrite from scratch some code where we used Blitz++ [github.com], since it was no more supported, and I wonder which library will die next...
Re: (Score:3)
Re: (Score:2)
That was certainly my experience. A few years ago, I wrote some code to process files that had messages wrapped with CRCs and started with Python. The CRC used a silly variant of the initialization or update rules that meant Python's standard library didn't support it. Calculating the CRC in Python meant that processing a 1 GB file once took 20 to 30 minutes. My prototyping would need to do that many times so it was quicker to switch to a different language (I used Go) than to use Python. The Go versio
Once again....Delphi is ignored (Score:3)
It's #9 on the list having crawled back up from #30. Once upon a time (2001) it was at #6. It's been in the top 10 for a couple of months now.
It's fast, easy to learn, compiled, memory safe. You can develop Win32/64, OSX, Android, and iOS app. And, with the right tools (ie TMS Webcore), you can build web apps as well. The downsides? It is Object Pascal, uses RAD methodology, IDE still only runs on Windows, and commercial (a free version is available). As of Feb 14, it has been around for 30 years.
Yet, it is constantly ignored by Tiobe in all of their reporting despite its movement in their list - even above Rust. Go figure. Tiobe only likes to talk about their darling or trendy languages.
Re: (Score:2)
Delphi lost its place of respect when Borland died in 2015. The downsides you listed are pretty major, IMO.
For a language to be viable long term, it needs a large community around it. Despite Delphi's relative comeback, that community is not forming around it.
Re: Once again....Delphi is ignored (Score:2)
Oh, I won't disagree with you on the death of Borland. That whole Borland/Inprise/Borland/CodeGear/Embarcadero debacle was brutal - people thought the language and tool died.
Then people bailed to C# or Java or JavaScript (web dev) and others with no clue badmouthed the language (usually, C# devs)
Define "Fast" (Score:2)
It's not clear what they mean by "fast". A fast programming language is, I would guess, one that lets you write a program quickly, so that tends to mean terse syntax, powerful features and a rich library of useful functions. Python fits that list, though I don't use it or like it myself. Alternatively, given the rest of the article, a "fast" language lets you write high-performance programs, and that's mostly down to code generation and optimization, which are far more controlled by compilers than the l
Re: (Score:2)
Rust is actually a pretty simple language to learn
It is just not worth it, unless you are stuck with C and want an upgrade, but can not jump to C++.
Fortran: 2020 #50 - Nov 2024 #8 (Fev 2025 #11) (Score:5, Interesting)
Fortran is never slow. Dot.
It is very difficult to generate slow code ! Eg. any Fortran compiler will always efficiently use the memory (no pointer => no aliasing => no risk of overlapping => better optimizations) and the code will always use vectorization (Go, C++ valarray, functional syntax in Rust, python-like comprehension, etc., I am writing about you).
The performance does not depend of the syntax constructions, types, or compiler arguments, as much as in other languages.
Fortran was going down up to the last 5 years. Yes, string management, the I/O syntax and the type syntax are "slightly" outdated :-) . But the rest (especially arrays) are quite convenient or reasonable. My opinion is that the recent major usage of Python in science has also probably refresh some memory about what is the performance achievable in Fortran compare to Python, with similar lines of code.
Moreover, with just Fortran code, it is possible to code at the scale of millions of distributed cores, to achieve the best performance. Modern Fortran includes, in the language, OpenMP (efficient multithreading, including tasks queues for the threads, and accelerators constructs for the GPU) and PGAS (Coarray, distribued arrays, using MPI calls).
Re: (Score:2)
I've written a fair amount of Fortran when I was working with different groups of physicist. The difficulty to do any kind of string processing or any kind of systems task really made me want not to use it.
I defaulted back to go back to C space for any kind of string, networking (outside of MPI), or file management.
But Fortran is probably a much better language than people think it is.
It's ... (Score:2)
... finally the year of Rust on the desktop!
(see, it's a play on the joke about how it's finally going to be the year of Linux on the desktop ... I'll just show myself out ...)
Good programming languages are. (Score:2)
The problem with classic 'fast' PLs is that they are, by today's standards, pretty shitty. A big like bad upgrades of Opcode/Assembler.
Modern "fast" languages came relatively late, after we got a slew of languages for the Java VM and for Web development.
Something like Go and most certainly Rust was overdue for decades
The last ones upgrading their PLs are the embedded, systems and low-level people, after some systems people finally got fed up of C and CPP.
Re: (Score:2)
I don't know. Modern C++ is really nice to write. It's quite hard to truly fuck it up. And it writes quite similarly to modern python or javascript, except you have proper type checking. I like it a lot.
Sounds wrong ... (Score:5, Insightful)
Surely Python is gaining in popularity not because of the language itself, but because it is the language mostly used for machine leaning / AI, an area that is on fire!
One could go further and ask why Python became so popular for machine learning, which has got nothing to do with it being fast. In fact Python is slow compared to compiled languages like C/C++ that have efficient optimizing compilers, but:
1) For ML/AI it doesn't matter since all the heavy lifting is being done by CUDA/etc libraries, written in C, and anyways offloading the computation to the GPU.
2) ML/AI had traditionally been the domain of people without a software development background, and what made Python popular was that it was easy to learn and had lots of libraries available. What makes Python easy to learn is that it is best suited for scripting and small programs, rather than being a "serious" programming language designed to enhance productivity and avoid bugs in large team programing efforts.
So, basically Python is not popular because it is fast - it is popular because being a simple/slow language doesn't matter when all the heavy lifting is being done by C libraries like CUDA.
A Speed Test that Every One Should Try (Score:2)
Go to this site and pick your favorite language (there are dozens to choose from):
https://rosettacode.org/wiki/E... [rosettacode.org]
Run the code with timers to get an example of Human created code which may or may not be optimized.
Then go to chatGPT and pick the o3-mini-high model.
https://chatgpt.com/?temporary... [chatgpt.com]
Give it this prompt:
Create a program in the XX language that will find a counter example for Euler's sum of powers conjecture for a power of five and integers up to 250.
Define "fast" (Score:2)
Fast to write in - Python
Fast to execute - C++
Go is SLOWER than Java. It's not a fast language. (Score:2)
Fast programming languages he called out include C++ [#2], Go [#8], and Rust [#13 — up from #18 a year ago].
Go is SLOWER than Java, and harder to work with. It's a dogshit solution looking for a problem, but don't take my word for it, ask people who studied it in depth. https://aws.amazon.com/blogs/opensource/sustainability-with-rust/ [amazon.com] I had to work with Go recently and was shocked by how slow it was. I thought it would be so much faster. Why am I bothering with pointers and arcane syntax for something that's so slow? I thought my code would run faster than the Java I'm used to writing, not noticeably slower.
Very old (Score:2)
It appears to me that Cobol and Fortran are still hanging in there.
what is a "fast programming language?" (Score:2)
Fast executing languages obviously are tied to how close to the hardware they are so... obvously, nothing will be faster than machine code and then assembler... then c... then you're into a lot of bullshit. I don't understand that anyone can say "fast" and "python" or "php" in the same sentence.
But this is all moot... take the slowest executing languange and run it on faster hardware. Bam. Now it's fast.
anecdote: I ran an old virtualbox I kept for