Mojo Lang - Tomorrow's High Performance Python? (with Chris Lattner)
Vložit
- čas přidán 30. 04. 2024
- Mojo is the latest language from the creator of Swift and LLVM. It’s an attempt to take some of the best techniques from CPU/GPU-level programming and package them up in a Python-compatible syntax.
In this episode we explore why the Mojo programming language was created, and what it offers to Python programmers and non-Python programmers alike. How is it built for performance, and which performance features matter? What’s its take on functional programming and type systems? And can it marry the high-level programming of Python with the low-level programming of LLVM/MLIR?
If you’re a Python programmer who needs better performance, a C programmer who expects more from a ‘scripting language’, or just someone who’d be happier if Python had a first-class type system, Mojo might well be for you…
-
Mojo: www.modular.com/max/mojo
Mojo’s Roadmap: docs.modular.com/mojo/roadmap...
The Mojo Discord: / discord
MLIR: mlir.llvm.org/
Chris’s Talks: nondot.org/sabre/Resume.html#...
Chris on Twitter: / clattner_llvm
Kris on Mastodon: mastodon.social/@krisajenkins
Kris on LinkedIn: / krisjenkins
Kris on Twitter: / krisajenkins
-
#software #podcast #mojolang #ml #pythonml
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](http://i.ytimg.com/vi/MDblUyz0PtQ/mqdefault.jpg)
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](/img/tr.png)
I'll be honest, this is a seriously impressive language by an absolute giant in the field. To oversimplify a bit, it has the safety of Rust, the performance of C, with the syntax of Python.
Couldn’t agree more, but I think something that’s understated is that via MLIR you’re basically getting access to a free hardware optimization abstraction layer!
The docs (and some folks who’ve messed around with Mojo more than me) have shown off how easy it is to literally command SIMD, which is usually just something most programmers can only hope their interpreter or compiler happen to do.
So sick!
like Nim for the last 7 years?
@@alelondon23but nim isn’t a superset of Python; Mojo aims to be one and it’s getting there fast
This is great but if it’s built on top of LLVM…and touching hardware to that degree-it’s hardly worth a look for the next 5 years for any GP programmer.
People truly don’t grasp just how little being a superset of Python matters-because the vast majority of people are productive in Python due to C / C++ libs.
It’ll be a crapshoot waiting for X lib to support Mojo’s way of doing things-the same way Typescript was supposed to be drop in superset of JS; but anybody that actually did web dev knows it was anything but seamless.
And all languages have the speed of C by Mojo’s standards 😅
Love these two guys though, awesome interview
@@alelondon23nim is alot of fun 🤩
Chapters:
00:00:00 - Python as a high-performance parallel programming language?
00:03:05 - The Journey to Building a New Language
00:05:55 - Writing High-Performance Loop Nests and IR
00:08:47 - MLIR and AST Generation
00:11:40 - Choosing Python for AI Development
00:14:23 - Introducing Mojo: A Different Language
00:17:01 - Interoperability with C in Mojo
00:19:50 - Introducing Mojo's Type System
00:22:38 - The Nature of Typing and Conversion
00:25:19 - Language Libraries and Data Types
00:28:16 - Hardware Acceleration and Library Extensibility
00:31:08 - The Power of Mojo and SIMD Vectors
00:33:51 - The Max Engine and Custom Operators
00:36:41 - Building bridges in the AI world
00:39:23 - Mojo programming in Python
00:42:26 - Compile time metaprogramming with Mojo
00:45:06 - Compile-time Python Programming
00:48:03 - Memory management in Mojo
00:50:58 - Lifetime Management in Rust and Mojo
00:53:45 - The Journey of Rust and Mojo
00:56:36 - Creating New Values in a List
00:59:19 - Parallelization and Threading in Mojo
01:02:09 - Parallelization in Mojo Programming Language
01:04:48 - Portable Algorithms and Applications
01:07:36 - GPUs and Multi-dimensional Vectors
01:10:37 - Utilizing Hardware Accelerators and Memory Hierarchy
01:13:25 - Mojo: Talking MLIR and LLVM
01:16:16 - The Growth of Mojo and the Open Source Community
01:19:00 - The Excitement of Open Development and Patent Coverage
01:21:37 - The Community Side of Programming
01:24:12 - Conclusion with Kris Jenkins
Kris, you never disappoint! I've listened to Chris talk about language design before. He has a brilliant approach, meet people where they're at, not where you want them to be. You have to be able to set your own ego aside in order to do that.
I really like the interviewer here, intelligent questions and he let's is guests actually talk, seems to be a rarity these days
This is a historical interview and goes straight to favorites.
I was skeptical when I first heard about Mojo, then I saw Chris's name, now I'm pretty sure we would be able to train huge LLM's on my microwave pretty soon. And I'm only slightly exaggerating in the faith I have in this man 😋
This channel is a hidden gem and it deserves atleast 10x the current number of subscribers. Thank you for this excellent interview !
MOJO is my last hope for solving the "computer language disaster". This man has all it needs to get it done (in time). Great Interview (as always). 👍👍👍👍👍
Outstanding interview. Chris is a true language engineer. Great interview as it gives a large audience an idea of the architectural drivers and technical challenges that led to mojo. Few people ever get properly exposed to these considerations to appreciate what it takes to do innovative language design and engineering.
Holy heck! This completely changed how I see mojo working out. I assumed it was some second-system project that ignored cython, and was making a moonshot fueled by hype. It'-s so incredibly funny that the real motivation is the part of it that no one ever mentions, the MILR backend!
This is by far the best developer focused channel on CZcams. Amazing!
Thanks, glad you think so!
Another fantastic episode. What a great guest. Really articulate, and you guys had great energy. Mojo is genuinely very exciting as a language. Zig was exciting too, but I can really see where Mojo fits in, and I think it could be really important in the next 10 or so years.
Soon as they open source this I’m rewriting everything I’ve ever written in mojo
I think they did recently
@@eyekey346 I think they've only open sourced the standard library, and some other bits, but not the compiler yet.
@@lojicdotcomwhy would most people care about the compiler being open source? From my understanding they will open source that too, just not now. They probably won’t open source their MAX engine which makes sense as that’s their actual money maker.
Chris Lattner is great. Thank you for interviewing him!
0:00 - Introduction and questioning Python’s potential as a high-performance language.
0:25 - Introducing Mojo and its creator, Chris Lattner.
0:43 - Chris Lattner’s notable contributions to programming languages.
1:13 - Lattner’s ability to work from Python syntax down to hardware level.
1:22 - Mojo’s approach: combining Python syntax with high performance.
1:37 - Start of the interview with Chris Lattner.
1:57 - Lattner's background and achievements.
2:18 - Discussing LLVM and Clang as foundational projects.
2:32 - Development of Swift and its motivations.
3:05 - Swift's design and adoption by the Objective-C community.
3:32 - Transitioning to why Mojo was created.
4:00 - Starting Mojo from hardware efficiency needs.
4:46 - Building Mojo’s code generation before focusing on syntax.
5:09 - Challenges in programming modern hardware.
5:40 - Introduction to MLIR (Multi-Level Intermediate Representation).
6:05 - Differences between LLVM and MLIR.
6:39 - Use of MLIR for domain-specific compilers.
7:26 - Explaining multiple levels of abstraction in MLIR.
8:04 - Benefits of MLIR in compiler development.
9:06 - Decision to adopt Python syntax for Mojo.
10:03 - Challenges and benefits of building a new language.
10:54 - Importance of meeting developers where they are with familiar syntax.
11:59 - Compatibility and integration with the Python ecosystem.
12:35 - Discussion on Mojo’s type system and performance optimizations.
13:28 - Targeting AI and high-performance computing sectors.
14:26 - Addressing the absence of a language like Mojo in the current market.
15:01 - How familiar Mojo is to Python programmers.
15:16 - Mojo’s current development status and future features.
16:18 - Compatibility with existing Python packages.
16:49 - Explaining progressive typing in Mojo.
18:18 - Benefits of having real types in Mojo.
19:04 - Integrating Python’s dynamic features with Mojo’s static typing.
20:35 - Metaprogramming capabilities in Mojo.
21:23 - Memory management and referencing in Mojo.
22:17 - Differences between Rust and Mojo in handling lifetimes.
24:24 - How Mojo manages resources efficiently.
26:09 - Explaining zero-cost abstractions in Mojo.
27:25 - Parallelism and handling multiple cores in Mojo.
28:11 - Handling matrix operations and memory hierarchy.
29:14 - Optimizing for specific hardware in Mojo.
30:23 - Creating portable algorithms for GPUs and CPUs.
31:54 - High-level programming and libraries in Mojo.
32:19 - Discussing AI model building and deployment.
33:15 - Shifting focus from research to deployment in AI.
34:31 - Integration of AI researchers and production engineers.
35:54 - Addressing the complexity of AI deployment with Mojo.
36:51 - Benefits of using Mojo for AI and high-performance computing.
38:22 - Explaining the max engine and graph compiler.
39:01 - Overcoming current limitations in AI graph compilers.
40:09 - Challenges and benefits of building Mojo from scratch.
41:00 - Example use cases and improvements in Mojo.
42:22 - Practical benefits for Python programmers using Mojo.
43:00 - Encouraging community growth and contributions.
44:23 - Meeting developers’ needs with familiar tools.
45:02 - How Mojo simplifies and extends Python’s capabilities.
46:00 - Using Mojo for high-performance numeric programming.
47:04 - Emphasizing practicality and usability in Mojo’s design.
48:22 - Potential for community-driven improvements and optimizations.
49:05 - Future developments and community engagement.
50:00 - Final thoughts on Mojo’s impact and vision.
51:04 - Encouraging Python developers to explore Mojo.
52:09 - Closing remarks and encouragement to join the Mojo community.
53:16 - Additional resources and ways to get involved with Mojo.
54:00 - Encouraging Python programmers to contribute to Mojo’s development.
54:35 - The importance of inclusivity and collaboration in the open-source community.
55:12 - How Mojo handles performance-critical applications.
56:05 - The integration of async-await for high-performance applications.
56:34 - The differences between Mojo and Rust in terms of memory management.
57:06 - Using Mojo’s type system to manage resource lifetimes efficiently.
58:08 - The benefits of exclusive ownership in Mojo’s type system.
59:00 - Simplifying memory management for developers with Mojo.
1:00:03 - Discussing the practical aspects of implementing parallelism in Mojo.
1:01:00 - Options for parallelizing code in Mojo.
1:02:04 - Potential future development of an actor system for Mojo.
1:03:05 - Encouraging the use of high-level abstractions for parallelism.
1:04:10 - Handling different CPU architectures and their impact on performance.
1:05:20 - Practical examples of writing efficient code for different hardware.
1:06:14 - Benefits of portable algorithms in high-performance computing.
1:07:02 - Importance of optimizing memory hierarchy usage.
1:08:09 - Practical tips for working with two-dimensional arrays and matrices.
1:09:02 - Leveraging modern hardware features for performance gains.
1:10:16 - The future of high-performance computing and evolving hardware.
1:11:28 - How Mojo bridges the gap between hardware advancements and software development.
1:12:32 - Using Mojo’s advanced features for specific hardware optimizations.
1:13:39 - Practical application of MLIR in real-world scenarios.
1:14:25 - Benefits of using Mojo for AI research and deployment.
1:15:35 - The practicality of transitioning Python code to Mojo.
1:16:28 - Current status of Mojo’s development and future roadmap.
1:17:14 - The importance of community feedback and contributions.
1:18:00 - Concluding thoughts on Mojo’s potential impact on programming.
1:19:00 - Encouraging developers to experiment with Mojo.
1:20:02 - How Mojo aims to improve the developer experience.
1:21:06 - The broader vision for Mojo’s role in the programming ecosystem.
1:22:09 - Final remarks on the inclusivity and accessibility of Mojo.
1:23:00 - Encouraging the use of Mojo for various programming needs.
1:24:00 - Closing statements and thanks from Kris Jenkins.
1:24:10 - Encouraging listeners to like, share, and subscribe for future episodes.
1:24:30 - Kris Jenkins’ final goodbye and signing off the episode.
With reference to Rust dealing with immutablity with memcpy... I wish I could remember what talk it was... it might have been Anjana Vakil ❤ ... talking about implementing immutable trees of immutable values without copying in JavaScript... it was such good stuff.
This was impressive and I had a lot of fun following along and searching through things you all were mentioning throughout the discussion. I have a lot more to learn!
Chris seemed to be genuinely happy to share everything he did, phenomenal interview.
Just discovered this channel, what a great interview.
If a guy like Lattner is fed-up with C++, what should us mortals do?
Great interview! Happy I found your channel!
Excellent interview! Chris Lattner is an amazing engineer. Would it be possible to get Bjarne Stroustrup for an interview? Is the man still alive? If so, it would be really interesting to hear the thoughts from the man who created the most influential programming language ever created, just a thought. Thanks for such a wonderful interview.
Thanks for the interview!
Nice interview, I really like your format. For me Nim do the job for now.
It would be interesting to have an interview with the creator of the V language (Vlang) Alex Medvedniko :)
Mojo just might be good enough to pry my fingers off of D, Julia and Crystal. It's on my list of languages to try.
Those are unique languages, what has your experience been with them
Someone needs to document as much as possible in a formal study over the next decade so we can finally empirically understand why some languages get adopted and others don't. There are so many good languages available now it is almost overwhelming.
Sounds like what Julia is currently doing with a different syntax and fancy approaches like leveraging multiple dispatch. Chris is a legend and it would be good to see how Mojo disrupts the data science and AI space
Julia isn’t a superset of Python though. I would say this is very different than the approach Julia took. The biggest factor here from a developer’s standpoint is that, when completed, mojo will be a superset of Python. You would be able to compile already exiting Python code with mojo as is and get a noticeable performance improvement and you can integrate mojo into that codebase bit by bit and gain significant performance, safety and control improvements. Julia can’t do that and that isn’t their approach. They built what they consider as a better, separate language for scientific computing.
Very good episode. Congratulations.
Wonderful conversation. Enjoyed the nuances of IR and AST and all kinds of compiler construction areas. Made me go to my grad school :)
Chris, I really enjoy your interviews and the quality of guests you land. I have no doubt your channel will grow in following tremendously.
Thanks! I hope so. 😀
Omg! Yes! Chris is my hero.
awesome interview thanks!
Im very interested in Mojo. It still seems to be too young for me but as Rust developer I look forward to moving to Mojo at some point.
Looking forward to seeing Mojo evolve. Maybe I'll have an option to transition to from Cython - as long as there is an upside.
I really hope Mojo can deliver on its promises
I think it is a very neat move to use a syntax plenty of people know and use it for a bit different language. Also, having a python with compilation to binary is on my wishlist already. :)
Amazing as always. I would love it if you did an episode on NATS the message broker technology. Given the popularity of the kafka and big data episodes, i think it would fit right in
A good replacement for rust... now that caught my ear. Looking forward to mojo.
And Mojo is/will be JIT, or do I have to compile a bundle to run a binary? Or can I do both? It sounds amazing!
Mojo seems to have a sharp focus on abstracting the hardware acceleration. Regarding the title question, Nim has a pythonic syntax and is quite mature. It would be nice to know the differences between them.
Nim is very very good in speed and executable size. Very nice language. Very nice way to interface with Python too.
great podcast
Has the Arch compiler dropped yet or they still only supporting Ubuntu and RedHat?
Love the tail call optimisation and strong typing. Machine learning/cuda style use case is great but it also pushes python towards being that viable functional programming lang while at the same time improving performance.
I think for specialist use cases this is going to be awesome. But I always wonder about language speed when developing run of the mill business applications (which Ive done for 35+ years), you have network latency, disk i/o database performance so real world code performance is less of an issue.
please make a book for MLIR
One thing to convince Chris Lattner is to use type inference where possible than gradual typing and being dynamic.
You should have called it Monty instead of Mojo.
Monty is funnier, but Mojo is a much better name.
Kepp up the Good Work Chris and Chris, you are doing gods work. #chrislike
The tech is probably cool but I can sense that this is going to generalize and extend and abstract its way into a complex ecosystem that mortals don't understand but which corporations will pay for. I'm way over on the "small languages for everything" front so it offers very little for me.
You had me at "replacement for cuda". ❤
Awesome interview I agree with the other commenter that said you should have 10x the subscribers!!!!
Thanks! Hopefully in time, we will. 🤞
Woooww!!! Chris lattner❤🔥❤🔥❤🔥
What a treat, thanks for this. Love hearing Chris Lattner talk
Im so interested in mojo i hope it was released soon on windows.
APL/Morten Kromberg/Aaron Hsu/Arthur Whitney interview When?
Haircut looking good!
Nice!! Lattner is a Genius.
Here’s to you Chris Lattner, the 10000x programmer 🤣
Great interview with a compiler legend. Thanks!
Another great interview. It's been a breeze and very informative. Thank you!
Python's syntax is its best innovation.
Chris is a compiler titan. Mojo looks cool.
have you seen the new BLEND language? it is a similar concept, high performance + massively parallel language with Python-esque syntax
Such bliss! Apparently, PyTorch and Numba doesn’t exist.
I have a question - does Mojo require powerful hardware to run? As it could do a lot and im afraid I may not have what it takes hardware-wise for it to be used optimally... Or could it just be run with the same specs like Python? I know it really depends on what you're doing with it but im speaking in general terms as well as in more broad ones
It's like 100x lighter than Python. And because its compiler is faster than C++ or Rust's Mojo is basically as light as it gets.
@@Navhkrin Wow ok, thanks a lot!
Also open source the whole stack as quickly as possible.
What IDE would you recommend for Mojo?
There's an official VSCode plugin: docs.modular.com/mojo/faq#is-there-ide-integration
And I've been using Neovim. The mojo support was was straightforward to set up, as it's already part of in 'neovim/nvim-lspconfig'. Well, straightforward if you're already using Neovim for other coding. :-)
Notepad for you should be ok
Use Ms Word is enough for pojo😂
PyCharm
Lol why notepad? @@r2com641
Question: When Chris says code generation, he's means machine code n NOT bytecode/IR ?
No. He uses libraries written in a mix of Mojo and his new IR (Intermediate Representation) to do the Code Generation rather than have a bloated monolithic compiler for a robust, parallel superset of Python. Presumably this IR compiles again from there in a form that suits the native architecture of the host machine, but I don't know much about LLVM or its replacement so I don't know if they are doing Java / Julia style static compile whole file first, or more immediately responsive at the cost of performance as it interprets this simple IR which pretty closely maps to Opcodes for most chips.
@@____uncompetative It compiles to machine code. But it doesn't do all compilation AoT. It's a hybrid mechanism between JIT and AoT depending on whether function is declared with def or fn. This allows you to match C++/Rust performance with fn and python dynamism with def.
Compiler is also really fast, even when compiling pure static files, it takes few milliseconds to get the job done. In fact, it is so fast that you can compile->run projects faster than Python does bytecode compile -> Launch
@@Navhkrin Thank you. That's very informative. It sounds like they have a good language that could in time displace C++ with sufficient library support.
Every time I listen to this guy I have to google a bunch of stuff lol.
When Stroustrup took C and bolted layer after layer of new and good concepts onto it, C++ became a large, if not cluttered, language without beauty. Still very successful, though. I wonder if taking Python and bolting new and shiny things onto it is doomed to become a large complicated clutter and if starting from scratch with a type system and an actor model and parallelism and ... would not be wiser (looking a Julia, maybe?).
Me, I would love to see some strong data sciences modules be written for something clean and pragmatic and widely spread such as Golang, but that is not going to happen.
Great video, by the way.😊
I wonder how this compares to taichi?
Great interview, thanks for the great content!
This is a very well done interview. :)
But will Mojo be full opensource and free?
I understood yes, it will be, but the world of GPUs seems so closed to me, and cloud service companies tend to be vendor locked.... Am I too paranoid?
#1:17:58
@bart2019 Yep, as I said above, I'm just a little paranoid about GPUs and service provider companies 😅
As I remember him explain it, in another interview. The reason why the programming language didn't start out as open source, was because of bad experience from his previous one, where he listened to what everyone wanted and had to redo a lot of work, over and over again and still there will always be those that are mad that things didn't turn out the way they wanted.
That's why he wants to make the language on his own, until it reaches a certain maturity, before he open source it.
The service parts (including the ability to contact them and get help), that is the business model of Modular, might never be open source. But they are not a part of the language. They are written in it, so technically someone else can write something similar.
Without their service, you will still be able to get a few x (up to about 10x, but might get closer to 15x when it is complete) better speed, with the same Python code running on Mojo, without having to do anything (because of their more modern and intelligent compiler).
If you start using Mojo specific functions then that's when you can see 100x and 1000x numbers (by utilizing vector hardware, multi threading etc). Numbers higher than that, is basically cherry picking problems that can be up to 35 000x (at this point and the language isn't even done).
I find that Mojo has a lot of hype around it. However, I’ve only been programming in Python for about 2 years and I find that the Mojo docs don’t have nearly enough examples.
That’s because Mojo is still a work in progress that hasn’t even been truly released yet.
when will Mojo be ready for Windows?
It will come GPU support
still not available on the most used OS.
Mojo: Login to compile your code - lol
Idk where you're seeing that. I'm on Linux, it's very straightforward: run curl to install modular, download mojo, modify your path. I've been compiling mojo code for the last 24 hours, no login. To use the MAX SDK you have to authorize, but not to compile mojo code.
why would you want a dynamically typed language that isn't typesafe?
Maybe this is a dumb question, but does mojo replace python or triton/cuda/open*l?
It extends Python to those Domains, so you can write GPU code with mojo instead of cuda or cuda binding to python while still able to write all the CPU code that python normally is used for.
Chris Cross
I thought it's turtles all the was down!?😂
I really like the design advances from zig and rust, but they totally missed the boat on accelerators. Programming languages should help you get the most out of your hardware, and cpus have largely plateaued. There are going to be 100s of billions invested into AI, and they can't get enough accelerators, so getting the most out of what they have will be critical. I hope mojo can get enough funding (perhaps from AMD & MS) to execute on the promise.
Are you the same person who does the Morgonaut Channel?
No.
My biggest question is: Does compiling my existing Python projects with a thin Mojo wrapper bring performance advantages or will I have to port it to native Mojo?
there's a demo that you can prob find online showing that just wrapping python code into mojo already can make it quite fwster
short answer, no. Some python syntax is supported but no all. And you need a cpython interpreter to use libraries, so no performance gains there. The plan of modular is to support any python script as it, but that is not the case nowadays.
He made opencl too? Wtf
this will be Chris Lattners Masterpiece, i am beyond excited, thanks for this amazing interview
You misspelled his name :)
I know! 😭 I missed out a 't', and only realised after it was published. CZcams doesn't let you edit videos, so I will have to live with my shame. 😔
@@DeveloperVoices the interview is excellent BTW
Thanks!
@@DeveloperVoices ask him to legally change his name so the video title is correct
@@blindshellvideos😂
javascript 4 lyfe
this guy looks exactly like that one actor and i cant get over it
Over here, we're all trying to guess which actor you could mean. 😁
@@DeveloperVoices your guest looks like Jed Reese, had to look it up lmao first saw him in the ringer.
@@BrentMaliceOh wow that is a CRAZY resemblance!
The one thing I never understood: WHY make it a superset of python, i.e. introducing a ton of new syntax, instead of just using all the syntax python already has, namely typing and decorators, and just use those by making them mandatory, if you want to have the speedups?
Python syntax has semantics - if people use type annotations for mypy, you don't want that to interfere with compilation.
@@ZeroPlayerGame Ever heard about mypyc? They do exactly that: Use the annotations for compilation.
Ideally you want anything that is written in the current CPython to just run. If you want to use the Mojo "extensions", you just use the Mojo types.
The Mojo installer blackscreened my PC and that's the end of my Mojo journey
😂
Awesome, but I really wish to see a roadmap?
Why do people think that python isn't good for deploying ?
(In the context of AI)
Global Interpreter Lock would be 1 problem I think
I think he meant CPython, which as the standard Python is interpreted so is very insecure for production code. Using compiled Mojo Python code should be fine.
I will switch to mojo when it becomes available. I love python but its just too slow for production right now.
My major problem with python is typesafety...
Although not by choice, I use Python in prod. The performance critical algorithms are always compiled with a Python interface.
Types are not much of a problem in my experience. It is a strongly typed language after all. Newer iterations allow for annotations so that helps with tracking types.
With all of that said, I am very interested in mojo given that the main weakness for Python is all of the handholding it does with threads and the GIL. It’s great for pure researchers. It’s awful for experienced programmers out the box. I have to go back and forth between threads and processes to achieve maximum parallelism.
Assuming I am a robot, I come across two nuts threaded onto a bolt, sandwiching some washers (they really didn´t want this to shake free). I can decide to remove this equipment, and my colleague can decide to help. I have a spanner, and he has a socket-driver. Whilst the socket driver is faster, it can´t tackle really long threads, due to lack of depth. So mostly he unbolts stuff, and asks me for the deeper threads. Hey, were working on a schedule to get this stuff unbolted, and repaired, before sun up. You get roasted on the moon.
Hang on, this isn´t working well. WTF. Why-o-why do americans insist on using inches, and wierd threads... ? We´ll use a different library. It´s not an exact fit, but I can wadge some white plumbing-tape around this nut, to help convert from mm to inch socket. Hey, it´s off, phew.
Flexibility wins... and we fixed Mamma robot, so can have a million more siblings, to help mining operation...
@@wld-phWtf are you talking about?
Chris Lattner work on Swift was a disaster.
Care to actually substantiate your claim or was it just a bad day?
@@markcoren2842 Of all the languages I've programmed in, Swift is plain awful, especially when there were inspiring languages such as C#, Ada, Object Pascal and Java around. I would put it up there with Rust as one of my least favorite languages. It doesn't solve offer any real advantages over other languages.
The syntax is hard to get your head around and very hard to read, such as the optional semicolon and return statements. Its curly brace usage is a gratuitous and a nightmare to visually parse. It relies too heavily on symbols instead of keywords. Finally, its OOP is quite limited and its constructors are overly complicated. It's too bad Apple chose it as the only first class language for developing iOS and MacOS apps.
What happened?
CZcams keeps deleting my comments.
Oh
I like the haircut
Do any of these people have any spare time/family life outside nerding at genius/psycho level 16 hours a day?
Lattner is married and has a family. As do most of these superstar engineers. Have you not considered that some of these people (like Lattner) are incredibly productive engineers who simply get way more done in a typical 8 hour workday than you or I do? That seems a lot more reasonable than assuming none of them have any sort of life outside of work.
Why would you base a language around interoperability with 2 vastly different languages, when the only benefit is getting a head start on the ecosystem building? The trade-offs made now become permanent technical debt for the life of the language, while the benefits fade after a few months while breaking the intuitive readability and usability of the language. By the time we graduate school you have 12 years of using the character set for a well defined math/grammar rules and you are turning half your character set into a push/pull door. When you start redefining words or mixing languages, you lose readability and intuitivity causing bugs.
Ie. square brackets [ ] define sets, while parenthese ( ) are used for grouping, while : is used for listing separate items. These rules are engrained in our brain and become instinctive. What you call breaking your brain is not something to laugh off, because it becomes a constant mental load on the developer and a major stumbling block.
When you write a language like C you are really writing algebra equations and using standard grammar rules. That is why things like arrow functions in JS are harder to interpret, as it redefines what we know about a syntax we have used all our life. When people talk about a language being bad, it is usually the syntax they are talking about.
it's not the "only" benefit, it's arguably the only benefit which matters for actual adoption.
No offense, but have you considered that the guy who built LLVM, Clang, Swift, and OpenCL might understand things about the trade offs of different approaches that you’re not aware of? This guy has decades of experience writing some of the most useful and widely used tools/languages in the world. I’m inclined to trust his judgment. That’s not to say you can’t have opinions, but you should at least be skeptical of your own opinions and ask yourself whether it’s possible someone who’s been doing this his whole life at the very highest level might know something you do not.
@@therainman7777 don't need to go so hard on it, but yeah, the guy's smart, he knows adoption matters in the real world far far more than elegance.
Please rewrite Django in Mojo.