ฝัง
- เผยแพร่เมื่อ 30 มิ.ย. 2024
- Let's explore the future of programming languages and look at some examples:
Rust: www.rust-lang.org/
Nim: nim-lang.org/
Vale: vale.dev/
Contact:
david.devonduty@gmail.com
#rustlang #nim #vale #programming #coding - วิทยาศาสตร์และเทคโนโลยี
![Nim - First Impression [Programming Languages Episode 12]](/img/n.gif)
Whoah... real news is that Java updated their website
Miracle miracle 😂
Fucking finally, it's about time!
That caught my attention too
Lmao
Is Java still running on 2 billion devices?
Thanks for the video. It's nice to hear the point of view of someone speaking naturally about a shared interest they're also knowledgeable about. I've enjoyed all of your content so far. See ya on the next one
Thanks, Nicholas, glad to meet like-minded people!
Really nice to hear about Nim and Vale. AOP is something that really should be explored further in programming languages. C++ is here to stay for a very long time, but as you said, it will slowly adapt concepts from other languages to get beter one step at the time.
Wow, this looks great. I've been using Julia a lot lately to address some of the things mentioned, but it isn't really a good embedded choice. I'm definitely going to look into these more. Very cool!
I am currently working on a project in Rust, and every time I look at(for maintenance) an old Nim project, I get really sad that such a great language isn't receiving more love. It has great potential (especially with 2.0 being round the corner), but it's really lacking on core developers(manpower) and its current "marketing" is absolute garbage, so I doubt it'll bring in developers who can work on the compiler(which is showing its age). To me, it's the language with the highest productivity to efficiency ratio. You can also use it for hard real-time systems despite having a GC thanks to ORC. readability, flexibility, efficiency, fast compile times, viable for prototyping/quick to write code, compiling AOT, one of the best c interop, etc,... are all features that I've yet to find in any other language whereas Nim sits at a nice spot.
except, white space sensitive.. no thx
@@_slier well Nim won't compile if you mix tabs with space, in fact, only space are allowed to indent your code.
But tell me whats so bad about whitespace scope? Like no C / Rust / Java code is wrote with an inconsistent spacing, code editors (even the smaller one like vim) will all auto indent the code you are writing to make scope easy to guess. If you need to write your code with random indentation your coworkers will hate you. So what the fuss about the "indent based == bad programming language"
@@briannormant3622 true, but I also like my curlys.. just let us use either & we can all be happy ☺️
@@everyhandletaken i agree, i do prefer curly over indentation. But I just don't get why some people goes " indentation based? I pass"
At least Nim let you use unnecessary parenthesis so you can "mimic" curly.
Like would compile
proc add(x,y:int):int "(
x+y
)
@@briannormant3622 explicit blocks have some advantages over indentation based syntax:
- you can write poorly formatted code and let the autoformatter clean it up
- in some cases having an if statement or switch case on a single line is more readable, most indentation based languages don't allow this
- in text editors like vi you can run operations on blocks (e.g. yi{ would copy the contents of the block to your clipboard)
- no "mixed tabs/spaces" compiler errors
I can't think of any reason to prefer indentation based syntax other than that it subjectively looks slightly nicer, so any language that chooses aesthetics at the detriment of the features mentioned above kinda just looks like a toy in my eyes
Wow! Just found and subscribed to your channel! Excellent stuff! Your voice has a nice soothing monotone sound and is easy to understand. (Also great at 1.5x speed). Thanks for the content. I’m looking forward to more! (I love the neovim content btw!)🎉❤
Hey Chad, thanks a ton for this nice comment!
Not pursuing a job in STEM does give you the privilege to focus on innovative programming languages. The language market is in need of more hobbyists that write programs just for the art and creativity's sake, to realise what one's dreamt of or make something special that just a few people care about but for them it really matters. Such things don't require that one should use a language with an immense ecosystem and that makes for a true expression of freedom in software development. Peculiarly, some of the new languages seem to target primarily this non-industry niche, Raku and Red come to my mind, and that's really awesome imo; not to say you couldn't fulfill such tasks with Rust/Vale/Nim/etc.
Even if you don’t get paid, language development is still a technology job.
@@Funcijej Language developers are one thing - usually computer scientists and software engineers by education, whether it's official or self-taught. Their role is indispensable and their professionalism - essential. But the programmers-by-profession around the world are too occupied with trying to meet the requirements of the job market with their skillset; to the point where very few of them have the spare time to learn and use an early-bird language in some side project of theirs. On the other hand, people with jobs outside of STEM and enough spare time could consider taking up just one or two highly potent languages in order to create the handful of programs/webapps which they feel are lacking and want to contribute to their own lives and to the world. Such people thrive at least as well in a small community of peers as they would in a large one like Python's. Thus I consider it beneficial for small and new languages to be promoted outside the circle of people already occupied with programming.
Very interesting point of view, I feel languages like Python and Ruby have also followed the same path.
BeefLang
@@lucarosania1358 They've enjoyed exceptionally organic growth (and decline?) for sure; and among a very diverse contingent ("for children and PhDs" - anyone?) so indeed they can serve as an excellent example. (They were innovative too, with their whitespace-significant syntax.)
@Blinded If said hobbyist happens to value development productivity and pleasurable debugging highly, I guess.
Nim really should be the go-to lang for everyone writing multi-threaded server software - the kind of programs that are written in php, Node JS, Python today.
why not go ?
Nim
Thanks for the video, David. I enjoyed it!
I was wondering that nobody mentioned Swift. I use it for just trying out something, for developing small UI apps for macOS, iOS and iPadOS as well as for server-side apps. I even developed my terrarium controller using Swift. The pro is its availability for all the main OSs (Linux, macOS, Windows), at least when it comes to non-UI apps, good amount of usable packages and of course its strict type checks. The cons is the lack of a production-ready cross--platform UI framework.
Thanks for watching, Thomas! I think Graydon Hoare (initial creator of Rust) is involved in Swift, didn't know it was cross platform. Will check it out!
BTW it‘s even possible to develop shell scripts using Swift. Makes sense for Linux and macOS only.
Because Swift is so wedded to refence counted objects, the Swift folks should take a look at this generational reference stuff. The problem is going to be all the libraries that assume reference counted objects - the MacOS and iOS have been largely built with Objective C and the refence counted objects of that Objective C world are what Swift was designed to interact with.
But consider Swift on a non Apple OS such as Linux - would be entirely feasible there to use a compiler option to specify switching from reference counted objects to generational references
Is nobody gonna talk about the absolute fire that is “Easy to write, and easy to make right”??
Nice video! I want to recommend you the Avail programming language, which is very young and doesn't yet have a lot of attention, but has some very interesting and promising traits. I especially like the concept of articulate programming and the "infinite algebraic type lattice" they've implemented.
Thanks, this sounds interesting, will check it out!
I fully agree. Languages are popping up all over the place. Rust is a game changer but not an endpoint. All new languages will have to have all the Rust features. Many languages won't reach puberty. A bit of a frustrating time for users of languages, unfortunately.
I wish you spoke about the multithreading capabilities of each language as well.
Me too.
I love c++ except for when I need other dependencies, the makefiles, cloning and compiling is bit a pain, if c++ has a decent package manager it would be perfect for me
Fearless FFI in Vale is absolutely mindblowing...since even Rust with all it's safety and people working on it so far can not claim to have achieved it yet. If they do achieve it it will be because they reproduce what Vale is doing.
Yes, it's a fantastic language and very interesting to follow its process.
Araq had expressed scepticism of Vale's approach, saying something like "been there, done that", iirc. Wonder if he's ever elaborated on that.
I would be very interested in Araq's opinion of Vale. Do you happen to know which feature he tried?
@@devonduty I saw the quote on the Nim telegram channel, but it's originally from a Discord channel where Araq replies to j-james saying that "generational references suck 😉 been there, done that...", but I'm afraid it was just a quick-tempered dispatch and he might not have argumented himself.
@@gimlam5909 I see, thanks for the info! I'm also a bit critical regarding generational references as it would also change how you would use them in your code. E.g. instead of having multiple owners (Rust's RC), you have references whose objects might not exist anymore and you'd need to check that. So I'm not sure if it would work well in practice.
you make nice videos. thanks
nim can compile to c, c++, obj-c as part of one set of backends (with the main difference being which it's easiest to integrate with, but you can integrate with all three and almost anything else with usual c ffi), and js and i think nodejs as well as part of another set (which has some limitations in some stdlib modules, some procs aren't available on js), and with the use of third-party code, thru llvm.
afaik there are some bits of compiler magic in some stdlib code, i think just the packages that say to not manually import them but i'm not sure.
notable for the modern type system is object variants/variant types (ADTs), which have compiler semantics like preventing an enum change that changes the declared variables.
the garbage collector is by default not stop the world but not deterministic performance (iirc), but it is trivial to switch to ARC/ORC to have deterministic performance, and you can disable it and do all manual memory management if you desire (and do manual with the gc enabled). you can also use go's GC for better interfacing with go.
would be pretty neat to have nim but with some of vale's memory stuff, like i forget what it's called but the extension to something to require you to call a method on something before deallocating it
Thanks, good video! I think I'll stick to learning rust for now. Can you make a video about Zig?
Yes, Zig is on my todo list! But I can't promise when.
@@devonduty cool!
Though not a language, I'm liking Deno, you get all the advantages of TS but none of the headache of getting it to work with Node. The ability to easily compile to an executable and the ease of containerising is just a pleasure.
buns js is here
I'm surprised there's zero talk about zig
@@KManAbout Why are you surprised?
@@SkegAudio because zig is bigger than nim or vale I believe
@@KManAbout Yeah that makes sense. Maybe it's due to their features?
Go is easy to write, and easy to make right. The addition of generics has also opened the door to a more functional style.
i find go to be absolutely revolutionary. it has changed what i expect from a programming technology. i now am frustrated when i use a technology that doesn't allow me to reason about time as easily as go makes it
I did enjoy the video, but I have to say that I prefer the first parts (talking about existing languages and limitations, introducing LLVM and Rust) over the rest. The first part feels like you're sharing thoughts - whether generally accepted concepts or things you found out yourself - freely. The post-Rust video is .. mostly you reading things on screen 1:1, sometimes even highlighting the exact words you're using in the voice over. Please don't take me wrong: I doubt I could do a better job. But while the first part of the video feels organic and like you sharing a personal (if common) position, the second half is basically like a prof at a university, reciting their own slides if you will?
Thanks for the constructive feedback! In the first part I was concerned to not reach the people who care more about the visual content (like myself), that's why I focussed more on the text in the second part when explaining more difficult concepts (like generational references). I probably overdid it a bit. In the next video, I'm going to take your feedback into account and try to speak more freely, I can see that this would make it more enjoyable!
You should have covered reasonml as well.
I love all the languages you showed in the video.
Reasonml is probably the closest to nim, not as in performance but as in idea. You write your code in reasonml(which is ocaml wearing a fancy suite) and using the ocaml backend you can compile to multiple targets from binaries to js.
Yes, reason and OCaml are great languages. And I heard with the latest OCaml update, the language got support for multi cores making it quite fast. I will definitely check it out more.
Modern Java has algebraic data types and they are surprisingly lightweight (see records + sealed interfaces).
Thakyou
I would love to see another video devoted to fearless-ffi -- your writeup is interesting for sure.
I was waiting for Roclang!
Yes, I'm also having an eye on that one. Beauty of Elm, combined with the speed of Rust or Zig... It's great!
Have you heard of zig?
Dart is amazing right now, named params, mixins, it's possible to create super clean code
Great video, would only point out that Linux is primarily written in C with many contributors, which seems to contradict your point about it being impossible to develop safe programs given those conditions. Thoughts?
I don't think he claimed it's impossible to write safe programs with C.
@@gJonii at 0:30 he said "I would even argue that for complex systems with many developers, it's impossible to create safe programs written in C".
So yes you are right - he didn't claim that it's impossible to write _any_ safe programs with C.
I was just pointing out that, given the conditions he mentioned and I pointed to (complex systems with many developers), Linux seems to be a possible counterpoint. Although I suppose you could argue that some part of Linux is unsafe, and then his point is valid. Thanks for clarifying the point I was trying to make 😁
@@andrw_ the amount of memory corruption vulnerabilities in the Linux kernel suggests otherwise
Need to do a follow up one with Crystal, Elixir and Zig
+1 for zig
Zig it is ;)
@@devonduty lets goooooo
Like before watching, since its 99% quality content lol
Both Nim and Haxe can compile to JavaScript, but I see only Haxe being used for JS game dev; A follow-up video to compare Nim with Haxe would be appretiated.
great video ! could you make one for vlang too?
Thank you! After all this controversy with vlang, I'm not sure if I want to take a look at it.
I was thinking of learning Julia as a hobbyist but it didn't get a mention. Is it worth learning Julia in 2022??
I think it's relatively popular in the area of machine learning, but I haven't tried it myself.
@@devonduty thanks I'm a novice but like your content even tho a lot is above my level. I am not sure if many people are getting into Julia, was pretty hyped at one time.
My professor said it's a waste of time to learn so many programming languages, he said learning C++ (System), Python (Web and ML) and Scala (Functional) is enough.
Depends what you want to do. If you just want to write programs to solve a particular task, it's a waste of time to learn more than one programming language. If you're doing frontend development, then C++, Python and Scala won't take you far. You'd need to learn JavaScript. If you want to broaden your horizon, then you shouldn't stop at any language and always keep an eye on current developments, there's innovation happening all the time.
I think it make sense for a professor to say things like this. For a student, the focus should be on general computer science knowledge, such as data structure, algorithms, compiler, or fundamental math knowledge say linear algebra, probability theorem for ML/DL. Most of the time a bad program is a result of inexperienced programming knowledge rather than the language itself. Besides, understanding the fundamental will enable one to pick up new languages fast. This is why most tech companies give you choices to decide which language to use for coding interviews. That being said, it doesn’t mean one should always stick to one languages for their whole career, if there is better tools to solve problems, then make sense to switch tools. Also, you might need to adapt to new languages because the company you work for are using that specific language. Having been a graduate student in the university myself, I wouldn’t disagree with what your professor said, but i also wouldn’t limit myself to just few tools.
@@devonduty i certainly would advise against learning javascript for front end development. it's rather like learning assembler for back-end work. i would suggest learning a language which can be compiled to something that will then run in a browser be it javascript or web assembly.
I wish there were some tutorials for the Vale language so that you can learn the language building small utilities.
Vale is very interesting, but I'll wait a bit until I'll try it out.
@@devonduty Also Odin seems like an interesting language, looks like C and Go with lots of power to control your memory and optimize as you want.
@@eduardabramovich1216 Yeah, I've heard of Odin, but I haven't yet looked into it. But I only heard good things.
the most revolutionary modern language that i know of is go. compared with rust, vim, zig etc i find go to be truly revolutionary. if i need to write anything with concurency, i really would not like to go back to managing threads. that's why i find go revolutionary. it allows an average programmer to write safe concurrent code. it is the only language i know that allows you to reason about time just as easily as reasoning about memory safety.
I invite you to learn both Procedural Pascal and Object Oriented Pascal, can be use for both Systems Programming and easy to express ideas ...
I heard good things about Pascal, and Nim also took inspiration from it.
Did u know about Elixir? It's simple to write and simple to do right.
nir is really interesting
If you had to choose a lang for a personal project. A shopping website with let's say a couple thousand requests per day, nothing more. And you had to choose between Nim and Golang, which one would you choose and why?
Good question, probably Golang because I'd be less afraid of missing libraries and it's well tested in that area. Even though I dislike Golang itself.
@@devonduty go also supports concurrency for the average developer. i know of no other programming language that does this. all others only offer a couple of usable functions for specific use cases (aync/await for example) or low-level controls (new threads, joining etc)
Mostly I end up using TS or Python+Mypy at home, because fiddling with Java is just annoying and I like having at least disjoint unions. I’ve considered Ocaml/Bucklescript though, just for that sweet, sweet ADT support. I suppose Elm could be used for the front end, but I haven’t touched that in years despite essentially writing most of my sketch apps in that style, and should probably look back into it.
Reading about the new stuff Java has been gaining over the years hurts because work won’t update Java beyond 8 for what they said was licensing reasons. Maybe liability, too. Dunno. Above my paygrade, but boy is it annoying. Back to A Thousand and One Exception Classes in FactoryFactoryFactory Land for me I guess…
Universal Software Model (usm) is a unique, universal, simple, natural, Clean and Clever (KICC) programming language, based on a unique informational entity - the Informational Individual (XX).
I talk about a complete new conceptual approach, a big change in our thinking about software, on a new informational model - inspired from the biological world, and not the history of the programming languages (as Ada!).
Hmm. Where to invest my time where I can get the best return on investment… Nim or Vale? I had already learned a bit of Nim, but will it take hold? Is it revolutionary enough to gain traction?
Depends what your "return on investment" shall be. If you just want to either learn new concepts or write some programs on your own, Nim is definitely a good choice. But if you want to use it in a company, I wouldn't recommend learning Nim.
@@devonduty Take into consideration that it is fairly easy to write C or C++ libraries with nim. So you get C-ish speed with a language about as difficult and productive as Python. I think there are many opportunities to use it as a supplemental language, e.g. combining Python (for eco system) and nim (for speed and C/C++ eco system).
I need a language that can be compiled for microcontrollers. Currently the only alternative to C is Rust. Nim and Vale are nice languages, but as far as I can see they are not made for bare metal programming.
Rust aims to be a system programming language, so you need unsafe access to the hardware and you don't want a garbage collector.
Nim is absolutely made for bare metal programming
@@leonlysak4927 Maybe, but what about microcontrollers? Is there any support for MCUs like Cortex M0 or ever AVR? Or libraries for external periphery written in Nim?
@@MarkusBurrer There is dedicated tooling for Nim for microcontrollers like PMunch/badger, pmunch/ratel and exelotl/natu on GH.
Alright, I was provided with some more insightful references to share with you, th-cam.com/video/O8Y4faZPnsc/w-d-xo.html is a talk "Nim on everything from microcontrollers to websites" and /j0fUqdYC71k is another, again by PMunch, about "meta-programming for 0-cost abstraction on microcontrollers".
Zig is a far more appropriate tool for bare metal programming compared to rust.
Using straight C is also a far more appropriate tool for bare metal compared to Rust.
Even good old ADA is a more appropriate tool compared to Rust.
Using Rust actually adds extreme and uneccessary risk to the lifecycle of your project. I would avoid at all costs.
the generational referencing is indeed very interesting. Now Zig is one of the languages that garners attention right now. Some of its fortes for system development (i.e., as a replacement of C) is that it has a build system tool chain that is getting lots of notice because even existing C code base gets a lot of benifit. Zig tool chain has become a superior way to build C projects. Hint: it makes cross-compilation a breeze and allows things such as specifying the glibc version - truly a huge pain point for most build tool chains). But the language high points are things like compile time expression evaluation. For instance, a type can be a function parameter if specified at compile time which opened the door to Zig having a completely different (simplified) approach to generic programming (say, relative to the complexity of C++ templates or even Rust templates). But another fascinating thing about Zig is that it's building out a standard library of collection types where utilizes columanar efficiencies as like seen in the big data SQL query engines that use things like Parquet and Apache Arrow. Certainly lot more to be said about Zig as an alternative to C for systems and embedded programming (it truly is a boon to embedded as is not dependent on std lib in same way as, say, C++, which has many assumptions in its std lib that don't mesh with embedded programming world
Generational referencing is nice 🎉
V and Zig are also very nice.
How do we make operating systems without C?
Even python is whiten in C so we cant use that and no one uses assembly and forchan anymore as they don't know it
At first, a compiler of a new programming language is written in another programming language. But eventually, you can even write your compiler in this new programming language, making the other language obsolete.
Rust tries to position itself as successor of C.
a lot of operating systems are not written in C. z/OS for example. older ibm mainframe OSes were written in mainframe assembler (which is much higher-level than x68-64 assembler)
Personally I would like to have a language that is a more powerful and expressive version of Haskell thats also efficient and has a package manager that is reliable. Haskell++ maybe. Although Rust is the closest thing its still nowhere near as expressive as C++. And C++ does have smart pointers that makes memory management safer than it used to be.
An efficient (and simpler) Haskell would be my dream language. The closest I've found so far is Roc, but it's not yet available.
@@devonduty Yeah Roc seems really nice. Personally i prefer expressiveness over simplicity. Haskell is very hard at the beginning but once you get going at it is starting to click its highly addictive. The thing Haskell is lacking is built in support for lenses and inheritance. Derving keyword is the closest but I would like full inheritance to make the language as expressive as possible. Great video btw
have you looked into ocaml?
I am probably in the minority, but I have always hated the cluttered c-style syntax. Far, far too many characters that make the code look ugly as hell.
Atm, I'm using Python, but I haven't found an elegant way to package Qt-GUI-apps into executables that people can easily install on other machines, which is a shame. Nim might hit the sweet spot I was looking for, *if* one can write Qt-Gui-Apps with it.
Interesting video. We’ll know when the “post C” future is here when operating systems in common use are not written in it. I personally think we are at least 20 years away from that day, maybe even a lot longer. It’s also telling that LLVM is written in C++.
well Rust is the only language that has been close to being accepted as the only alternative language to be used in the Linux Kernel, even C++ never achieved that. Then there of course is Redox which is a from scratch OS written in Rust. I do I agree Rust has only just started out so a long road ahead for sure.
In regards to LLVM being written in C++, not sure what your point is? LLVM existed before the existence of Rust so being it being written in C++ is no surprise and pointless point.
Allowing rust in a kernel is a big mistake. That language is already suffering from bloat despite being 3 decades younger then c++
@@jakelexington7610 Rust is bloat? are you drunk?
Rust has the same code bloat problem as C++ caused by overuse of templates which causes generation of large amount of duplicated code. C doesn't suffer this problem since C programmers use more dynamic style of programming for generics using void* pointers and dynamic dispatch using function pointers. This is "less efficient" than template code which can be optimised more, but there is less overall code in the executable.
@@shaurz lol then you don't understand "zero cost abstraction" first Rust doesn't use templates it has hygienic macros, and those code generations are monomorphised by the compiler and then further optimised by the LLVM compiler. C is an extremely basic language with a million footguns has very little higher level language features and essentially completely unsafe.
Maybe 40 years ago it was the best choice, but these days literally no point other then if you're working on a legacy codebase.
tell me who would do a kernel in something like zig, jai or other obscure programming language.
Hobbyists. But yes, no one is using those languages for production-grade kernels and I also wouldn't recommend it. However, Rust already gained enough traction to be used for Linux drivers (soon?) as well as in Google's Fuchsia OS.
V lang may also be worth a mention. There is a lot of work to do on it but it sets out to do a lot.
I get so tired of programming languages these days, sometimes I think I'll just write some assembly code instead.
5:15 easy to write easy to make right
4:9 architecture must not be an after though
You said Java lacks Algebraic data types. That's misleading. Java has had sealed interfaces since 15 or 16 I think.
Lack of null safety is the bigger type system hole but that can be solved if you as a team agree on a checking framework to enforce nullablity checker.
Yes, null safety requires a lot of discipline, that's why I'd rather have the language enforce it.
I didn't know about sealed interfaces, but at a first glance, it looks kind of clumsy.
@@devonduty it is a bit verbose, but it's not that bad in exchange for what you get in return.
Null safety in Java doesn't require discipline. You have to set it up in your CI once and disallow merging without a clean CI pass (which you should be doing anyway, even in Haskell). The good analyzers don't have soundness bugs. They treat @Nullable T exactly the same as a built in nullable type would be.
It would be nice if it was built into the language but that's not really practical now (at least super immediately) because of the amount of pre existing code that would have to be Null annotated. It's possible but it will be time consuming.
@@hamesjetfield0 thanks for the detailed explanation!
in java every class is an algebraic data type in the sense of Class or Void. the trouble is, the type checker doesn't know about it. the result is NullPointerExceptions :/
Could you look at D language and tell me why its so underrated?
Good question, I think it's really hard for a programming language to become popular. Most of the time, it's more related to marketing and less about the language itself.
D is overrated. it's just a C with garbage collection (and additional features). That automatically makes it fail as a C replacement. Sadly D will never catch on, newer languages have already taken it's place for various niches
@@FlanPoirot How its overrated when so few people are talking about it? Also I would choose to use D over C with -betterC switch almost in all cases. Slices are just too good.
@@FlanPoirot someone once told me that D has schroedinger's garbage collector - sometimes it's part of the spec and sometimes it isn't.
Nice video, maybe you should also consider the V language (or VLang) in your list, a Go under steroid and simpler. :)
my current favorite language is Typescript, it's fast to write and catches more errors at coding-time than vanilla js
that's really not a high bar to clear now is it
@@ilonachan please tell me about a language with a better mix of development speed, fun to use and safety. I'd love to try it out
@@SandwichMitGurke how about python? it's easy to read, intuitive to write, and anything is safer than JS frankly
@@ilonachan catching those runtime errors in production is a nightmare, ts handles types much better
@@_hatred agreed. I have to run every python Code like 3 times before it works without crashing.
You missed THE
Odin Programming language!
Heard about it, but didn't have the time to learn it yet.
How about Julia?
It wasn't really on my radar because I don't do machine learning, but certainly an interesting language.
Where is zig, vlang, odin, julia etc ))))?
Why do "new"ish programming language doesn't have traditional OO features with classes?
Because certain OO features (e.g. inheritance) turned out to be not really needed would introduce unnecessary complexity.
Because OO is literally Rat Poison
It smells so good that rats can’t resist it, and will have a nibble on the juicy bait.
The antiduretics in the bait then kick in shortly after, making the rat thirsty and hungry.
The only cure is to eat more bait.
The anticoagulant compounds in the bait, once fully injested, start to work their magic over the next few days.
The victim begins bloating as their kidneys fail, and they become unable to flush out excess fluids.
They literally swell up into furry spheres, and get crushed under the weight of their own bloat.
Modern languages, having seen their predecessors choke to death on their own bloat from the OO rat poison, thought that would be a good thing to avoid
@@devonduty encapsulation though
@@KManAbout you dont need class keyword to do encapsulation
@@user-py9cy1sy9u nobody said you did lol?
Respectfully I think you're missing the point; the future is new kinds of programming paradigms emerging. Consider punch cards evolving into the Burroughs 5XXX evolving into compilers evolving into, "live systems" (Smalltalk, Erlang's BEAM) which laterally gives rise to REPL-style interaction which makes the previous "write a tome and let the computer read it and then let you know what it thinks" seems superfluous and antiquated compared to, "the computer is listening and will respond back instantaneously when it is talked to." It's worthwhile to think in those kinds of terms-- we can with historical precedent consider that whatever supersedes current human-computer interaction will probably be along similar lines. I think so far we've gotten to a kind of responsive Cartesian, List-evaluating (wink, wink) object which can respond to our commands and that's where modern L337bro from California coding comes from. I'm really saddened for everything we've done with phones that Erlang isn't somehow standard for developing high throughput systems. I digress.
Larry Tesler and others were working on, "Actionable Programming" in the late 80's which I think is now referred to as, "Programming by Demonstration." There currently (prove me wrong here) a comprehensive system where-in the actual computation that takes place can be, "recorded" and, "played back" with arbitrary constraints applied to which (depending on constraints), "timeline" (consider branching web histories) the computer ends up, "deciding on." If memory serves the last time.I was at the Viewpoints website Alan Kay was working on something to do with ontologies. There definitely is a way forward.
"Computer I want you to display to me a system of constraints. Based on this constraint what might be the possible behaviors of the system in the future; of all of these constraints which most fits the criteria. Return(Critera)"
There's a demo by Bret Victor ("Inventing On Principle") where he actual demonstrates this kind of thing in real life along with other, "future programming" paradigm examples. Definitely worth looking at.
th-cam.com/video/8pTEmbeENF4/w-d-xo.html&ab_channel=JoeyReid
I absolutely love the talk by Bret Victor, it's funny, informative and just mind blowing. I agree that we need to be more open minded and need to distance ourselves from how things are done _at the moment_. Only then one can come up with actual revolutionary ideas. I think in some years, computers will drastically change the way we code - or not code at all if you will. AI will allow us to define the constrains, the computer will do the rest. We already see a glimpse of that with DALL-E etc. Soon, we won't know the difference between generated and non-generated (human made) content. The internet will be a sad place and we will lose the ability to recognize real things. But until computers will produce programs on their own, we still need good programing languages, so let's enjoy the remaining years of manual coding!
@@devonduty I know some people will fixate on "remaining years of manual programming" to mean that AI will one day take all the jobs. Blatantly unacceptable notion IMHO because spreadsheet programs didn't magically ban all "human calculators" from ever working again; they were just training to use those spreadsheet programs or went off to a different industry entirely. Notice that pay _barely_ increased for those workers using spreadsheet, yet production increased a whole bunch.
The only people who substantially benefit from "AI taking all the jobs" will be CEOs/board members hoarding all that $$$ and repairmen fixing the machines at a fraction of the cost they used to charge since AI does 99.9% of the "simple repairs". Everyone else who learned the "fancy schmancy AI constraint solver 835784" will just wait for their next food stamp which barely covers one meal, let alone a healthy meal, as life expectancy dips to lows that we haven't seen since the middle ages.
After all that, do these CEOs really think it's worth destroying the very economy they cherished for so long because they made the game where no one can buy anything because they didn't have the monies to pay for the overcharged necessities? This is the final outcome of "remaining years of programming", you just haven't realized it yet.
Until then, keep pushing for MUCH better, more revolutionary languages that are made, tested, and run faster than they can say "let them eat cake"!
@@SimGunther Honestly the idea of AI replacing coders is probably not going to happen anytime soon. While programmers will probably use AI driven tools to help generate boilerplate, the big picture coding stuff is still going to have to be done by people that understand coding, because you're just not going to be able to take a giant system specification and have the AI magically generate all that. It'll be more like "AI, create me a Pathfinding algorithm for the following inputs" and it'll spit out a function that you use in your code.
@@taragnor So a better version of Github CoPilot, which is already easily influenced by its input from public AND private repos, is somehow our future? Not a new paradigm or notation that allows us to see software engineering completely differently? Not "literally the best source code search engine ever"? It's really not a future where the imagination gap is practically closed with new tools and processes, just "I have 100% blind trust in this AI in that it'll just make the right code for me"? At that point, why wouldn't we have a snippet search engine that integrates well into existing text editors/IDEs...
We really are doomed as a society.
jai
Nice video, but honestly it felt like it was an advertisement for Nim. I know you like it, but half of the video felt like you tried to sell us the language.
On the general topic of the video, I like where the future is going, I love typescript but I also love how devs are more aware of memory safety, and I hope Rust or any of similar languages can become more mainstream, more stable and more used, but also agree that not every software needs to be written in rust.
Yes, I like Nim but I'm not involved in the language in any way, I'm not even programming in it (apart from learning it at some point). But it was really an eye opener for me how easy it is to write efficient code.
I think being excited for something, and talking about its strengths, is very different from shilling, which is what you're insinuating, and the vibe I got from your comment, even though you probably didn't mean to. I get excited talking to my friends about something I enjoy, and even "advertise" it; that's pretty normal as long as no deceptions involved.
@@balen7555 yeah, I think living in this age where most of youtubers are faking excitement for something because they're being sponsored, is making it hard to differentiate true excitement.
But yeah, I didn't mean to be rude or anything
All of them are different flavors of the same old language
I really enjoy learning and using V, so easy and fast. Recommended
I'm a bit reluctant to look at V since the author apparently made many claims which turned out to be false. There was a recent discussion on Hacker News and the author of V announced he would publish a blog post clarifying things, I will read it and then think about it again.
@@devonduty i havent went deep down so much yet, so I still dont see anythong from these claims just basic programs
Nim is Kotlin for outside the JVM.
The problems I saw in Nim.
1. There is no concept for package. Assume that you are writing a gui library in Nim. You want to write it as a single package and inside that package you may have different modules. In any of that module, you may want to declare any object (variables, types, procs) with package visibility. That means if you write "package class Foo {}", you can access it from any of the modules in that single package. This package feature helps you to write code easily. Nim lacks this.
2. Forward declaration - I know that there is an experimental feature to avoid the need for forward declaration. But it's a must have feature for every language.
3. Initialization of type members - It's very easy if you can give default values for your type members in the declaration area. So you don't need a constructor proc for simple structs.
4. Circular module dependency - Assume that you have 3 modules in your project. Sometimes you want type A from module1 in module2 and type B from module2 in module1. Nim won't allow you to do this. It will force you to write the source code as single file. The compiler will be happy if you arrange your code in a sequential manner. I think that's why the "include" statement exists.
5. OOP suport - Nim's oop support is minimal.
There is a language called D. You will love it. None of the above said problems are solved in D.
What about Golang?
meh.
@@user-vj4ql5ul7q any arguments?
@@angrysmilex Hardly innovative.
@@user-vj4ql5ul7q wtf
Does anyone else like the verbose syntax I love it makes me feel Code-y
Language not mentioned here that deserves praise is F#
All functional languages are great :)
What about V lang?
There was quite some controversy around V lang, so I skip it for now.
Without telling what problem you are trying to solve, your introduction make no sense.
V vs Val vs Circle man ?
Can y ?🎉
rust is outdated now🎉
Nim ? Uhm space tab ?
Nooo tks
There are too many languages and too many options. :-+) And you can write safe programs in C/C++. Just not very many can do it.
Regarding safe programs in C/C++: Small programs yes, large, complex programs with many developers - I don't think so.
In theory, sure. In practice, just look at the cve reports. Programmers sure are good at overestimating how good they are.
why all these languages when Lisp already exists?
No mention of c#?
Why isn't golang mentioned tho?
Yeah, these are for noobs. I still code in binary. ;)
Obligatory XKCD: xkcd.com/378/
My current favorite language is Go
Go doesn't seem to be a language I would fall in love with. The type system is lacking, convenience functions are lacking (map, filter, ...) and I'd rather have Rust's error handling. What I do like is how you write concurrent programs with it.
I really wanted to love Go, and for many types of projects it’s still my favorite. It’s fast, efficient, with some great ideas, like goroutines, and it produces a single executable with no dependencies. Refuses to compile a lot of stuff that would result in runtime errors. Awesome.
Then I had to create a backend server for a JavaScript front end, with lots of JSON sent back and forth. What a nightmare. Libraries like gjson help, but it would be so much easier if maps could hold arbitrary, "unstructured" data without resorting to convoluted "objects inside objects inside maps inside objects inside a map".
Not a big problem if you have control over both front end and back end, and can format the data as you please. That’s just not always the case.
@@rhandeymaahrsch2151 i would certainly use something like json schema or swagger to generate the client code in javascript and go/java/whatever. writing json parsing code by hand is not fun.
Where is Go in future of programming?
go is the present (and also the future) :)
Nim looks like F# without the .NET marriage and everything that entails
Everyone's so obsessed with safe code. It'll all be in the trash in 2-3 years anyways.
If you can make safer code, you can maintain it longer, add new features longer, and avoid the need for rewriting systems. Even small increase in safety would have exponential effects for larger corporations who spend massive amounts of money to maintain large code bases. And, it would push the limit of how complex a system can get before it turns into unmaintainable trash.
V is a cool language
Rust is a very tough language to learn and as you said yourself it is kind of difficult to implement certain things that is easier to do in other languages.
However, considering obscure language such as Vim and Vale as "the future of programming languages" is either kind of naïve, either insulting to Rust (that's a mainstream and a very good language), or both.
On the other hand, you completely forgot one language that is already becoming mainstream and that has features that are much better than Vim or Vale, and that is far easier to program than Rust. This language is GO, aka GoLang. Everyone has the right to have opinions and speculate about what is going to be the next big thing in programming languages, but completely ignoring Go is very strange, particularly considering that it is already getting there with a huge acceptance in the community.
I'm not saying that Nim (not Vim btw) and Vale are the future of programming languages. I just say that they bring great ideas to the table and we should never settle with the current status quo. I also mentioned that I don't think that those languages will ever reach mainstream adoption, so I think we're on the same page here. I explicitly didn't mention Go because personally I think that this language could've been a lot better. Especially regarding the type system, it lacks important features, which should be standard in modern languages. However, the concurrency story is quite good. Personally, I'd rather not use Go.
@@devonduty: To "forget" Go just because you don't like its type system it's a huge mistake. You can even do OO. What's missing? Inheritance? Come on! Inheritance is the most atrocious invention and "states" are not far behind. Interface is a much superior abstraction, allowing polymorphism as well as information hiding. Multiple interfaces mimics multiple inheritance, creating several "masks" for the same "object" and at the same time guaranteeing consistence. I programmed in C/C++ and Java. I do like Java, especially for the JRE, but I simply avoid inheritance and keep it to strict minimum. Go captures good qualities of Java, like files structure and a huge standard library. This is what is missing in C/C++. It captures also good qualities of C/C++ with pointers, but they are safe just like in Rust.
For low level programming Go is also fantastic. It has a virtual machine assembly that allows you to program in a very low level, allowing the compiler to optimize it to the target architecture. SIMD parallelism, for example is a breeze in Go. There is even a library to use it when the processor has SIMD or just implements a normal calculation if the processor doesn't have it. Go also has support for a lot of stuff you can only find in Java, like, for example, vector graphics. If Rust had an equivalent support, I would use Rust instead, but Rust has a big inconvenient. It's hard to do low level stuff. Go is perfect for that.
My only complaint about Go is its awkward way to access the window to do graphics or GUIs. But isn't it Java awkward too? What about forcing double buffering when using JPanel? That's so inefficient! And you have no way to get rid of it, without getting rid of the the JPanel itself. But if you do, keeping only a JFrame, your interface starts flickering. I opted to buffer myself using BufferedImage and saving the vectorial Graphics2D using createImage, but only once, just to record the initial interface state. In this way I only use it when I need to refresh the whole interface efficiently, and I update simpler individual items (such as buttons) directly in Graphics2D (no, it doesn't flicker, but if it does it is straightforward to buffer that too). No need of double buffer. I discovered that the real efficient solution is just buffering, not double buffering. But talking about inefficient code, Java excels in it! Go is exactly the opposite. Go is probably the most efficient language in the planet nowadays. It beats even C/C++. As a graphics man I couldn't have asked for a better language than this.
I have just scratched Go myself using VSCode for building and debugging existing code. I am not yet programming with it myself. After 23 years of C/C++ (14 of C++, 9 of C) and 12 years of Java, I'm quite tired of those C++ linking problems and segmentation faults, as well as of Java inefficiency. Go seems to be the intersection of both with several bonuses. By the way, considering Python as a reference is a second big mistake in this video, in my opinion. I can't even understand how this horror became mainstream. Not even talking about JavaScript! But JavaScript became so pervasive that one just cannot just ignore it. There are so many fantastic libraries written in JavaScript, that it's no sense not to use them. I use it for reading fonts, for example, using Opentype.js. I modified it to generate fonts as classes in Java and I use inheritance to deal the with individual fonts in a generic way (using polymorphism) just because it was more compact and convenient since the class comes from an external program (no, I don't hate inheritance, but I find it consumes too much memory and in most cases not very convenient).
Therefore, I can't agree with your opinion, since I can't find anything like Go around. I'm not into code poetry, but in hardcore programming, and Go simply rules on that as far as I can see. Go is also excellent as a KISS language and good for prototyping. Prototyping is my software design paradigm and to use Java with it sometimes requires other languages around (mostly script languages). Go seems to be self-sufficient all along.
@@schizoidman9459 thanks for this elaborate answer. Regarding Go: It's definitely not inheritance which I miss, in fact I like its absence very much. Rust also didn't include inheritance, as it would've just opened the door to so many wrong designs, so I think we're on the same page here. What I miss most is algebraic data types, better error handling à la Rust and better ways to loop, filter, map. And Go is not the most efficient language for low-level programming. But it's easy and efficient _enough_ for most things.
@@devonduty
I never said Go was the most efficient language for low-level programming. I said Go was fantastic to program in low-level and that it allows programming specific features in certain processors very easily using its virtual machine Assembly.
Where Go beats C/C++ is in compilation time, not in execution time, especially in complex systems. Go was simply built for compiling faster and it does!
But execution time performance depends on the compiler and now there is gollvm. It's too early to talk about performance with this compiler since it's still not mature. I recall that once the C++ Intel compiler generated the most efficient code (for the PC, obviously) and had ways to code SIMD (but obviously not portable). Now Intel is using LLVM and claiming it generates the most efficient code. Many people disagree with that (obviously).
Notice that I didn't say Go was the most efficient language. I said "Go is PROBABLY the most efficient language in the planet nowadays." I should have written that it has the fastest compilation time and that it is just a question of time that code generated by Go compilers run with the same performance as C/C++. Time will tell.
About the features you describe I don't miss any of them. Go was created to be simple, following the KISS paradigm. If one puts the features you want, Go would not fulfill its purpose anymore. You completely missed the point.
@@schizoidman9459 Go will never reach the same performance characteristics as C/C++, let alone because of its garbage collector. I never understood the argument "Go is simple', no it's not. The language is simple. It has simple constructs. Programming in it is not simple. It would be simpler if it had more sophisticated features.
Bun still in beta already making cool go and rust kids tremble. Flexibility, ecosystem and speed? Unifying browser and server js with out of the box typescript? Who wants anything else
My opinion rust wont take over system programming. Too much time,money, knowledge investment in c/c++ . It also is not easier to write compared to c++/c. If a language can fix the issues of c/c++ and also become easy to write like python. That language will take over
Yes. c/c++ will remain to be the king of systems programming for a long time to come. But if Rust can take over some parts of it (as it's being done in Linux/Fuchsia/...), it will lead to more robust software. And slowly expanding on that seems more likely than completely taking it over altogether.
Rust is being take over by Amazon.
We have to have an eye on them!
Golang
bro, look at go