Hey! I''m a software developer with strong interest in hardware and firmware topics.
On this channel, I look at interesting projects from across the whole stack.
Some topics I talk about: - Embedded development, - Programming (C, Python, Go, Rust, Java, JavaScript, Shell, You name it!) - 3D printing - Neovim - Linux - ...
Python is similar to Fortran in concept. Fortran was easy to use (much easier than Assembly, which were prevalent at the time or C, that came after a while.), so researchers and people who are not computer scientists but need to code liked it. Python, when using the right libraries, is fast enough for a lot of scientific computing. The problem is that, like Fortran, you have to pull up C when you need to do something more advanced or if Python is too slow for your purpose. Python is still a very good glue between various languages. Basically, if Python is faster, researchers in every area that isn't computer science are going to have a better time with their code. Fortran was easy to use and fast. If python becomes fast, even if it is not as fast as Fortran, it will keep being used. Julia was born with this premise.
This is the third time I've seen someone tough filename before editing it... and I'm not sure why. vi (or any other editor) will happily save the new file for you.
Snake lang has some of the nicest syntax imo. It is far easier to read and comprehend existing code than other languages that have more complex syntax (e.g. Rust Thing[Something]<T<W>>'A), which is important if you care about maintaining code bases. The main downside to Python is the low performance compared to all the other languages -- for example, when I ported my bluegenes library from Python to Go, I got a 100x speed improvement before doing any Go-specific performance tuning and memory optimization. But I still love Python and write the majority of my FOSS projects in it, so I'm kind of stuck with it for now. Hopefully they figure out a solution that removes the GIL without making the runtime twice as slow. Iirc, Guido said that the GIL was a solution for a time when single-core performance was all that mattered, and More's Law was still in effect for individual CPU cores.
1:05 and 2:34, GIL was not introduced just for simplicity but for the SPEED! Without a global lock you'd need to introduce many local ones which make single-threaded processing slower. Your example proves that!
@@cheesed_up Python come on time there was no alternative to VB & C# many projects didn't need the speed of C/C++, and they need simplicity of C# and it is massive .Net Library, I know many ppl will hate me saying this, but I still prefer using PHP from cmd applications/script rather using Python, Specially in Python you have to include a library to do every basic stuff e.g. getting user inputs from command line, or running a web server, or executing external command, PHP got it bad reputation because of it early (legacy) projects spaghetti codes, and it being too easy many newbie programmers write terrible codes on it ( _and got their sites hacked_ ) , and not implementing OOP since it beginning.
Is it... really that hard to use smart pointers? Stick to unique pointers and bounds-checked containers for nearly everything and you'll be fine. Macro them too so they're shorter. This is the way I write all my C++ code nowadays anyway, and I've never had issues.
The biggest drawback of mojo is the same one when python 3 came out: it's a different language. The python 2 to 3 transition should be a good reminder of why backward compatibility is important. In an interview with Lex Fiedman, Guido Said cpython incompatibility was the main reason that killed those project that tried to make python faster. And mojo is doing the same mistake. So, I don't see a bight future for mojo. Maybe I am wrong, time will tell. The Faster-CPython team has some great optimization ideas that (hopefully) will be implemented on 3.14. Look at 701 issue on the faster-cpython repository for a quick recap of what they are doing.
3:27 okay, I love your content, but maybe try and learn more before you say something that is just false. an interpreter takes in code and runs it, a COMPILER (not a JIT compiler) takes in code and turns it into machine code, and a JIT compiler runs in the background and updates the existing machine code according to the changes made. usually interperters are fast during build-time, but requires every client to also have a copy of the interperter, a compiler is slower than interperters, but works for every client with the same OS/architecture as you, and a JIT compiler is slower than both for the first compilation, but becomes extremely fast for every compilation after.
Thanks for this comment. Oh, man - I went and watched this part again and it's really just a mess, so I really appreciate your feedback. It was a genuine error, so I won't even try to justify it. I'll pin your comment, so hopefully as much people as possible see it. It's not that I don't know what a JIT compiler is, it's just that this video took me pretty long to make. While reding the script I just didn't catch the fact that there is way too little context here and the sentence was very poorly designed. I'll really try to catch stupid mistakes like this one next time. Thanks again for this!
Not exactly. In fact, the JIT becomes faster if it cashes machine code. But even if it does not, it becomes faster after a while. It looks at the code ahead of time and compiles it. So it can improve performance in the first run. There is an effect that JITs take a while to heat up, it has to start the JIT and after a while start running the code. That's why you shouldn't use them in lambda computing. Saying a JIT is slower in the first run is factually wrong. It depends on the size of the code. If you run a longer script using the JIT, it will be faster than interpreted. Edit: my comment applies to mature JITs. It is possible that some stuff is slower than interpreted, as the Python JIT is not ready yet.
@@vidal9747 saying JIT is slower on the first run was a mistake, but everything else you said was true for ahead of time compilation, not just in time compilation. python's compiler currently only has a just in time compilation.
I'm always suspicious of anything as overhyped as Mojo. In fact, that's all programming languages seem to be now driven exclusively by hype, not by observable performance indicators recorded after something mature is produced in them. Things like the TIOBE index and the youtube "programming" bubble also hint at this hype over substance approach to programming languages.
I think the licence is basically so they don't get copied by bezos the next day. in the discussion they said if you want to make a commercial AI/ML infrastructure, just approach them.
@@DataPastor I think it's a fair point but the alternative is probably that they will go bankrupt when AWS & Azure & GCS basically copies them and drive them out the market. Mojo is till now no Go or Swift so they need to make a language and a profitable product to keep the lights on.
If it helps, Chris has said that whether it'll be completely opensource is a matter of "when", not "if". They just have to protect themselves at this early stage.
Didn't know about the try-catch being sugar - thanks. I thought I said in the video that if no one uses the variable after it's taken by the function, the copy is not made. Looks like I wasn't clear enough :)
Now it needs a Bython because significant whitespaces suck and make writing code super slow because you always have to check for whitespace errors which is a super dumb misfeature of Python. Ugh!
@@hanteroes in “the old days” IDEa just weren’t as smart if you even used one… so indents could get all screwed up if you moved code around.. copy/paste spaces vs tabs, etc you could accidentally muck up your code with a copy/paste and mot easily recover
A lot of insane optimizations will come with python 3.14. You can read an abstract on the 701 issue of the faster-cpython repository. They even has a plan to reduce reference counting overhead. The future python garbage collector is way to overlooked IMO.
Codon looks like an interesting project, thanks for sharing. However, the way I see it is it's just an implementation of Python, whereas Mojo is basically a different language, that happens to share the Python's syntax. Codon looks promising too!
A superset of C++, this is like infinity times infinity. And there is probably already something to help with memory safety, smart pointers and containers to name a few.
I dislike the syntax, i dislike that it wants to do 300 things at once, and I do not understand what the technology do. Other than that it is a nice idea to have a language that can do everything.
I see your point. I felt the same way before trying it out - I must say that the syntax becomes a lot easier on the eyes after a while :D. But yeah, we'll see how it turns out...
lol i dislike the fact you can’t decide what your priorities are. thankfully you’ll continue to not be relied upon to contribute anything worthwhile, anywhere, likely ever.
@@dude2542 you mean targeting these other architectures? That's more a function of MLIR than Mojo. It is a capability unlocked by the underlying technology.
When people think smart pointers == safety, or thar rhis matter is just people wanting to use rust, you see how important the discussion is. I like C++, but it is true that without breaking changes tbe language will never catch up with real modern techniques and what toolig can do. New librart features cannot solve it, the language must enable things like safety, good straightforward meta programming and assist tooling functions
I like how the video on Theprimetime channel reacting this video of yours has more views and impressions than the original That guy didn't even include a link to your video because God forbid some of his viewers would come here and consume the content from its source, classic RU-vid debauchery and it's so infuriating how some people can just steal away other's ingenuity and their ideas to make some low effort reaction videos
Right now it seems that to convert an existing class from C++ to Safe C++ only requires rewriting about 95% of all the lines. And the lines that do not require rewriting are mostly "{" and "}" if you use Allman-8 formatting. I wish the syntax gets much nicer or it will be easier to use Rust and write a bridge between C++ and Rust in C.
it would be cool if they just would stop adding stuff to c++, but start deleting shit. I mainly write C++ and in my opinion the main problem is that its tooo fucking bloated. Noone uses every C++ function.
I think we'll sooner have LLM's capable of transforming large C++ codebases into Rust than this proposal getting accepted and implemented by compilers on all platforms.
This is called putting the cart before the horse. Hardware is inherently unsafe, the CPU is a machine, and it is capable of unsafe operation. A subset of the machine's capabilities will always be an inferior representation of the maximum. Even assembler is already a subset, because most of us acknowledge that the micro sub-operations such as fetch, cache, and the use of ALUs is well tuned for the machine specs as they are given to us. Making a declaration such as, "You are not allowed to address memory yourself," as a general rule, is simply asinine. You may believe in the future, but some of us are actually responsible for hardware, and someone needs to write your compiler.
Very interesting take. I agree with you to some extent, however, I still think that putting safety constraints to a language is beneficial. If C++ is a language for this kind of constraints.. that's another topic :D
