I imagine for most web dev’s using a fast memory unsafe language is like taking a bullet train to the local shop to get milk.
The computers are fast, but you don't know it
501–510 of 819 posts
Re: The computers are fast, but you don't know it
#502Earlier quoted context omitted.
Why should I care what Numpy is written in? All I see is Python.
Because it is like saying you use a bash script to configure and launch a c++ application and saying it is a bash script. Python is not a high performance language, it isn't meant to be and it's strengths lie elsewhere. One of it's great strengths is interop with c libs. Your assertion was that numpy etc will be faster than something else despite being python: > Try writing a matmul operation in C++ and profile it ag…
I mean TensorFlow is c++/cuda!
No. When I write Tensorflow code I write Python. I don’t care what TF does under the hood just like I don’t care that Python itself might be implemented in C. Though I got to say TF is quite ugly and not a good example of Python’s user friendliness. But that’s another topic.
Re: The computers are fast, but you don't know it
#503It feels like the gist of this article is just, don't use python.
Re: The computers are fast, but you don't know it
#504Earlier quoted context omitted.
Doesn't Rust mostly abstract the memory management away as well? It tends to be low overhead, and has sensible defaults with respect to memory management, but it's built around RAII and for instance if you use a lot of reference types as far as I know there's nothing keeping you from having fragmented memory the same way you would with another high level language. I know Rust also offers arenas and other purpose buil…
Well yeah, you can write slow code in any language if you don't think about memory layout ;) I see Rust roughly in the same bucket as C++. You can abstract the details of memory management away - which mostly also means giving up control over how things are arranged in memory - but if needed the low level explicit memory management features are there.
I guess the difference is that C++ still gives you pretty much direct access to memory (i.e. pointer arithmetic). Rust tries very hard to keep you at arms length from the actual memory as a rule, and forces you to work through a safe abstraction unless you use an escape hatch.
Re: The computers are fast, but you don't know it
#505Earlier quoted context omitted.
It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.
I remember a video of a guy running an old version of Visual C++ on an equally old version of Windows, in a VM on modern hardware, to try Windows development "the old way". It took about one frame to launch. One. Frame. By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max. edit: probably this video https://youtu.be/j_4iTovYJtc?t=282
> It took about one frame to launch. One. Frame.
I really liked Win 2000 because of this feeling of speed. Most programs would simply "open" when you clicked their icon. There wouldn't be a loading screen. I remember getting frustrated because I could not look at the pretty spalsh screen that Excel had added because it would flash and disappear in milliseconds. Amd this was on hardware of that time.
Re: The computers are fast, but you don't know it
#506I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…
Why can't we have a language easy to read and maintain but also have the speed of C?
Zig!
Re: The computers are fast, but you don't know it
#507I imagine for most web dev’s using a fast memory unsafe language is like taking a bullet train to the local shop to get milk.
It also doesn’t stop when you reach your destination so you have to jump and roll out. Get it wrong and you die. Questioning this method is widely frowned on.
Re: The computers are fast, but you don't know it
#508Earlier quoted context omitted.
I was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).
I delved into Python recently to work on some data science hobbies and a Chess program and it's frankly been fairly shit compared with other languages I use. Typescript (by way of comparison with other non-low-level languages) just feels far more solid wrt type system, type safety, tooling etc. C# (which I've used for years) is faster by orders of magnitude and IMO safer/easier to maintain.
I have found that Python with `mypy --strict` for type-checking is actually quite nicely typed.
Re: The computers are fast, but you don't know it
#509Earlier quoted context omitted.
Why can't we have a language easy to read and maintain but also have the speed of C?
It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…
So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for.
What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum memory efficieny. Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.
Can someone from the old guard tell me, how often we have been here in the language design cycles through the desert?
Re: The computers are fast, but you don't know it
#510I imagine for most web dev’s using a fast memory unsafe language is like taking a bullet train to the local shop to get milk.
I would say to the local farm, then you have to wait for the cow to be milked (like an external api call...). At the end you just reduced you journey time by 0.1%, and incread you code complexity by 100%.