FWIW my school introduced e as a base of natural logarithms with “it’s a special number, don’t worry about it. Good thing: your calculator knows them, too” and for a while we all thought that “natural” somehow related to being calculator-friendly.
Then later we got introduction to e in terms of derivatives and complex numbers. However, compound interest was never used for exploration, and I only got introduced to the it’s connection to e and as an explanation for what e is late in my thirties.
Actually, it’s because we believe innovation is easier the further you are from HQ. And Portugal is wonderful. I’m spending about 4 months of the year there with the team who hail from around the world.
Plus, many "wealthy expats" don't live in the city, preferring neighboring suburbs like Cascais or Sintra. The Lisbon proper is very dense, lacks greenery, and chokes in traffic, an interesting place to visit, but not to live in.
Meanwhile, every single real estate developer / agent sets their prices incredibly high hoping to sell or rent out the property to those mythical "wealthy expats". I saw a stat somewhere that less than 0.2% of all real estate transactions in the country each year involve foreigners, and yet everyone blames them for high real estate prices.
> why forking VS Code when all this functionality could just be an extension, same as Copilot does?
Have you programmed extensions for VSCode before? While it seems like a fairy extensible system overall, the editor component in particular is very restrictive. You can add text (that's what extensions like ErrorLens and GitLens are doing), inlay hints, and on-hover popup overlays (those can only trigger on words, and not on punctuation). What Cursor does: the automatic diff-like views of AI suggestions with graphic outlines, floating buttons, and whatnot right on top of the text editing view - is not possible in vanilla VSCode.
This was originally driven by necessity of tighter control over editor performance. In its early days VSCode was competing with Atom - another extensible JS-powered editor from GitHub, and while Atom had an early lead due to larger extensions catalog VSCode ultimately won the race because they manged to maintain lower latency of their text editor component. Nowadays they still don't want to introduce extra extension points to it, because newer faster editors pop out all the time, too.
Even with administration change in the US there is a long-term initiative across multiple agencies to eventually move to more robust software, and a part of it is the push towards more safe programming languages (where safe means fewer memory issues, fewer vulnerabilities, less bugs in general, etc.). Similar government initiatives now start in Europe and elsewhere in the world, too.
This regulatory change is not new, it has been going on for years and will take more years to finish. And even without a regulatory pressure, the migration would happen eventually. Look at the cars. As they get more features like adaptive cruise control and various driver assistance features, the need for software that runs with no lag and is reacting to surroundings correctly and quickly becomes absolutely critical. Car companies now can go out of business simply because their software is buggy. The car vendors now produce more software than ever, and they are in dire need for better programming tools than ever.
Languages like Java, Scala, C#, Go, etc. cover many scenarios like cloud services and, for example, car entertainment system. But for devices, microcontrollers, real-time low latency systems etc. C and C++ have been the go-to languages for decades, and now it is starting to change, because turns out it is very, very hard to write correct, bug-free, safe, and secure software in these languages.
Rust is one language that is getting into this market: Rust Foundation established a Safety-Critical Rust Consortium last year, for example, and Ferrocene compiler has a bunch of certifications done already. Ada is another option that would work for many such use-cases, too. The selling point of Ada is that it's been around for a long time and many vendors already have established compilers and tools with all appropriate certifications and qualifications done for all sorts of industries.
So, it's not really "Ada is interesting" and more "Languages that can replace C and C++ are interesting".
A lot of this movement continued to happen under the previous Trump administration; we have no idea what is going to happen, there are good arguments that it may go away, but also ones that argue it will accelerate or intensify. We’ll see.
Am I a bad programmer if rust is really difficult for me. I desperately want to learn a low-level language, since I think I'm missing something hanging out with my buddies C#, Python and NodeJS.
C and C++ are too difficult, Rust is also hard. I think my best bet is Zig at this point.
No, Rust gives you a lot to wrap your head around very quickly, and it took me three or four epiphanies to get it, and I tried to learn and stopped twice before I was able to get far enough along with it that it became easy to think about and work with. It doesn't make you bad programmer, but I'd still suggest giving it another shot every 6 months or so as your time allows, and see if you're getting farther each time. As long as you're still learning each time you bounce off of it, it was probably time well spent, most Rust concepts will show up in other languages, and the ones that won't are still useful paradigms to be aware of so you can contrast it with other paradigms as you get more experience with those.
C is small enough as to be very valuable to know. It's not the "high level assembler" that it was originally sold as, but as a conceptual model it's invaluable. It's also very valuable to run through CVEs, bug reports and such to find out how it falls down, and why safer languages have value. You can learn all that without even learning it to such a degree that you can write code in it.
I know you said C seems too hard - I felt the same way some 30 years ago. Then I learned Pascal, and found learning Ada to be a bit of a breeze after that. After that, coming back to C was a different experience - very natural. You don't have to force anything, and you can learn whatever you want whenever you want (or not at all).
Sometimes your capabilities can quickly level up in unpredictable and exciting ways - which I find to be one of the most fun parts of programming. And it tends to unfold like a horizon - you learn low-level stuff, then you get interested in high-reliability software, or real-time systems, or highly parallel / functional systems, etc. This is all great, and no one brain is big enough to hold it all - so have fun!
If you have written multithreaded C# code which encountered deadlocks, race conditions and had to build a mental model of which thread is responsible for what and currently "owns" a resource and is allowed to modify them... then you already kind of know a bunch of things implicitly that rust makes explicit and can transfer that knowledge.
At least that's how things clicked for me when I came from Java and I already had to debug lots of concurrent code before.
Similarly, if one has fought with a garbage collector and thought about efficient memory representations, where things get allocated and deallocated that transfers to some extent.
If you have been living blissfully in effectively-single-thread-land, then yeah, there'll be a bunch of new concepts to digest.
Note that Rust only covers such scenarios for in-process data, any kind of resource that is external to the process, there is no help at all from Rust's type system in concurrency or threading.
Which always gets forgotten in fearless concurrency discourse.
At least for the work I typically do, including my hobbyist projects in Unity, I almost never have to use threads. Praise be to Async, which has abstracted a lot of this.
I couldn't really grass programming until I found JavaScript. Even now my criteria for learning a language is one of two things .
One, do I want to build something and this language would be the best tool .
Or, two, is this language going to make me a ton of money.
I really want to find a good use case for Rust that isn't superseded by what I can do in the languages I already know. I might take some time to make a game in Rust one day...
> Or, two, is this language going to make me a ton of money.
I don't think any language per se is ever going to make you a ton of money. Even COBOL is not enough to make a ton of money. What might make you a ton of money at some point is being highly skilled at developing in some broad area where that particular language happens to be used.
> I couldn't really grass programming until I found JavaScript.
This is a bit surprising to me, because JavaScript is not at all an easy language to work with. You might want to look into TypeScript as a way to make quicker progress in that same domain, with Rust as more of a side-project to help you grok lower-level programming in general.
> I might take some time to make a game in Rust one day...
Game development in Rust tends to be especially challenging, since the main competition is C++ - another low-level language. Take a look at this example of a very simple Breakout game in Bevy, one of the most well-known game engines (though still very much at a highly experimental stage!) https://github.com/bevyengine/bevy/blob/latest/examples/game... - this might help you realize the level of effort that's typically involved.
I've been a salaried software engineer for a long time at this point.
JavaScript just clicked. A lot of more complicated things you need to understand for c and c++ are just handled for you.
To be fair I was technically using Unity Script, which has everything in a nice game engine sandbox. Want to move a cube, takes 1 line of code.
I am working with Typescript on my latest project. It definitely helps when dealing with more complex projects. My current project is basically a website built in React.
I still like Unity, but I don't trust the company so I'm looking for a new engine.
No, Rust is definitely hard. One of the best memes I’ve seen about rust goes like “Other languages have a garbage collector, with Rust you are the garbage collector.”
I also haven’t had as much fun learning another language in a long time. Keep with it! It’s worth it.
Rust is very different from Python or C#, let alone NodeJS. I'm not sure what exactly is so difficult about Rust for you, but the basic feature-set of Rust as "your first programming language" (i.e. no prior experience with C/C++) is one where the main emphasis to begin with should be on passing stuff by value and explicit copying, almost like a functional language - avoiding both references and interior mutability. These latter features should be looked into after you've become familiar with the basics, so as to avoid any confusion.
If you encounter specific diagnostics that are cryptic, file tickets. A lot of things were aware of and we improve them regularly, faster when easy, slower when complex, but we eventually get to them. We can't fix cases we haven't been made aware of, so reports from the field are very useful (sometimes users are more creative when it comes to misusing Rust than even fuzzers are).
The D programming language is far safer than C/C++, with the same amount of power. The syntax/semantics are such that it's very easy to learn if one is familiar with C/C++.
For example, although one can use pointers in D with abandon, it's better to use slices, where array bounds overflows cannot happen. Array bounds overflows are the #1 cause of security bugs in shipped C/C++ software.
The people who do use D really like it. It's a mature language with solid compilers.
I haven't experienced a memory corruption problem with it in maybe a decade, and I write D code every day. That's a big change from my days writing C and C++.
Rust has a steep initial learning curve followed by a plateau of enlightenment.
The language has a lot of corners though -- not so much messy edge cases like C++ but just emergent complexity from its sophisticated grammar and type system.
As with all such languages: you do not have to make use of all language features everywhere, and in fact you should not.
> The selling point of Ada is that it's been around for a long time and many vendors already have established compilers and tools with all appropriate certifications and qualifications done for all sorts of industries.
This makes it sound like the field is dominated by proprietary/closed-source tooling. That is a huge red flag for the health of the language if true.
Well, yes. But that's the feature in this context. The point is: places where Ada is used require certain levels of qualification and certification, all the way down to the compiler. You have to be able to prove that that binary fragment was produced by that particular code fragment. Think aircraft, nuclear reactors, rockets.
So this tooling is already certified and it fills the "compiler + various verification tools" space. Otherwise you'd have to certify your tool chain yourself every time it changes.
Say you are building an aircraft. The whole software stack is part of the aircraft certification, all the way down to the compiler. A complete aircraft is a system composed of other systems which themselves are composed of other systems. Eventually, there's a software system. Systems are certified independently and for a complete configuration.
Of course, requirements get stricter as the criticality of the component increases. Not every component has such strict requirements as discussed above. But a lot of them do.
Interesting that they decided to adopt the word "crate" (from Rust) for libraries published to the registry, and just like Rust they use TOML as a format for a package file.
We’ve used AsciiDoc for some of our documentation and for generating slide decks.
It is obviously a nice system but over time our frustration with it grew. Every other piece of software we have uses Markdown: GitHub, work chat, chats of open source projects we work with, things like StackOverflow, HackMD, personal note taking apps, the list goes on and on. Every new person joining our team had to adjust to AsciiDoc just for some of the work they would be doing while staying with Markdown for everything else.
We pulled the plug last year and migrated everything we had to Markdown, and while sometimes I need to use HTML tags to do something advanced I don’t mind it as much as I thought I would.
The frustration for me is then which "flavored" version of markdown you're now using, because the evolution seems to always be "MD is simple and popular" until gets extended with subtle differences. Those subtle semi-random differences in flavors get tiring really fast.
What's the frustration about? Basic things are same everywhere.
If you need complex things, you already have enough skills to figure that out. Also there's almost always a help button around that lists what it supports.
For me the frustration is that you cannot learn markdown once and use it in different places - for non-trivial things you always have to use a reference for a particular flavor.
Adoc is too cumbersome and the tooling around it are always subpar; sometimes unusable. It also is trying to be somewhat of a replacement of html and is really bad at it.
It all comes down to web engines. There are many browsers built on top of Chromium and a few that use Gecko or WebKit. Some of these try to make as few changes to the underlying engine as possible to ease the engine upgrades in their codebases, and due to the nature of the web they have to keep updating their engines.
So, a big question then is if Google, Apple, or Mozilla decide to change their engine in such a way that it would improve user tracking on the web how many of these custom browser companies and individuals (Vivaldi, Brave, Arc, Tor, folks, etc.) would be willing to undo those changes, or add code to mitigate the tracking? And then how many of them will keep migrating their patches from one version of the engine to the next? And how many of them will continue doing so when the engine maintainers will actively try to make this work harder? And how many investors will keep giving money to these browser companies?
The web is very vulnerable, and Mozilla with its board slowly leeching off all the resources out of it has long been loosing its ground for a long time. I'm afraid that we are at a point when the only way to preserve user privacy is via regulatory means. EU is clumsy, but at least they make the user tracking more annoying for advertisers, and some actors like Apple would be more hesitant to blatantly add ad supporting code to WebKit just to avoid further confrontations with the EU.
> For 2, hopefully those traits will eventually be standardized in std.
We got async functions in traits, but we can't create trait objects with these traits yet without using a separate crate and without boxing. Once it will be possible this would mean that projects like embassy can rely on these traits in environments that don't allow heap allocations. Another relevant feature is async iterators / streams. This would be the point when these traits will be standardized. We are probably 1-2 years away at this point.
Tokio and other runtimes meanwhile made effort to be ready for when these traits become standard: tokio keeps all relevant `read` and `write` methods in custom `AsyncReadExt` / `AsyncWriteExt` traits so that when a standard version of these methods appears people won't end up with conflicting implementations and broken code.
Great post: it's something I wanted to write for the past 2 years or so and I'm glad this post exists now. Thank you so much!
Then later we got introduction to e in terms of derivatives and complex numbers. However, compound interest was never used for exploration, and I only got introduced to the it’s connection to e and as an explanation for what e is late in my thirties.