I stopped with rust

very true

I'd point out that "can be computed at compile-time" is rarely the important part of a const block.

The vast majority of the time, the reason for the const block is that assert!(foo); is a runtime check, and the reason to write const { assert!(foo) }; is to promote that to a compile-time check. There does need to be some syntax for that distinction, because it matters.

If someone is using const blocks to write things like

let x = const { 1 << 20 };

just tell them to stop doing that. There's no reason to do that; it doesn't help at all. The optimizer will do that at compile-time even without the const block.

2 Likes

I quit my job and devoted myself fully for half a year to truly experience the convenience of Rust development. It is truly one of the excellent languages; the convenience of development becomes much better than other languages after getting used to macros and various features. Whenever I encounter a common feature during development, I can use macros to intuitively wrap it, instead of packaging it into a complex feature or structure as in other languages. I am still exploring its use and don't know if I can find a good job. But it is indeed fascinating, and I look forward to your return.

1 Like

I'm also in my late fifties and I love to learn new stuff. Iv'e done Rust for 4 years and would like to say: Hang in there it gets better. You have to see the borrowchecker as your friend!
If you want a language to be quick and dirty just use Python.
Good luck finding the language that makes you happy!
/Magnus

2 Likes

Definitely not! i like speed!

If you like it enough, and you also want memory safety and reliability, then I think you will be back soon! :slight_smile:

3 Likes

I do not want memory safety.
Like for example in Delphi this has to be done.

try
    // create things
finally
    // free things
end;

But Delphi is totally exit for me. I do not know C or C++ and do not want to go there.
Maybe I will be back.

And i want to control memory myself. I want circular references with the risk of dangling pointers - if needed.

But I think the speed of Rust is (partly) possible because of the strict rules.

Maybe I find alternatives inside Rust once...

Thank you for sharing @ericlangedijk!

Regarding the example you provided, if you compare it to other strongly typed but high-level languages like Java or C#, you’ll find that similar type conversion operations—such as dynamic casting and reflection—can also become quite complex really quick. Even though the language helps manage types, when you start dealing with more advanced patterns, it requires a deeper understanding of the underlying mechanisms.

My advice would be not to give up but to just take a break. Allow your brain time to create new pathways and process the information naturally, rather than forcing yourself to understand. It's a normal process that just takes time.

Don't throw your handdoek in the ring yet :slightly_smiling_face:

Cheers!

1 Like

Pretty much none of the stuff you mentioned is related to the languages readability in any way.

Languages like Nim can do all of that, and are miles more readable than C++. Ada is way more readable than C++.

1 Like

It was not intended to be. If we want fast, small, portable programs in a high level language (points 1, 2, 3 and 4) without any surprises (point 5) then we have little choice today. So when C++ is said to be the "low bar" to compare Rust to I wonder what high bar(s) were in mind.

Thanks for the heads up on Nim. That looks very interesting. But at first glance I don't see that it is comparable. Nim uses a garbage collector and compiles to C.

I do agree I would rather read Ada than C++. I Ada your high bar then? If so I think Rust is doing very well :slight_smile:

1 Like

Oh I forgot to mention!
I am using vscode for compiling / debugging.
Being used to C# debugging, i find debugging in vscode almost unusable.
I reverted to println statements like I did 40 years ago!!!
Bytes are shown as chars, and you can hardly watch any arrays / vecs.
'Watch' expressions do not work.
Is there a better environment to work in?

Yeah, I'd really like the debugging story to be better in Rust. While it's true that you can get a lot further with printing debugging in Rust, I still end up in situations where I want to use a debugger.

Funnily enough, one of the better debugging experiences I've had with Rust is using Visual Studio and msvsmon (its remote debugger agent).

But I wish I could just fire up lldb (using the rust-lldb helper) and use it to debug Rust applications.

I don't think so. Debugging in Rust just sucks in general.

That said, I rarely feel the need to fall back to raw debugging in Rust. Generally, if it compiles, it works. If it doesn't work, you may be using too weak types to encode your invariants. And of course println! debugging is always there. One can also use more powerful forms of it, like the dbg! macro, trace macro attribute, or logging (log, tracing).

It's not that there is no need for proper debugging. I felt that need many times. But it's definitely needed way less than in most other languages, due to strong typing and control over aliasing and mutability. Avoiding global variables also helps, and easy built-in testing helps to debug small pieces of code, before the bugs spiral out of control and require a strong debugger.

Maybe RustRover will satisfy you more? I haven't tried their debugger but I am generally very satisfied with jetbrains products.

It's... middling to poor. Collections and enum views are pretty bad to unusable, but you generally get quite reliable debug stepping etc.

I think it's just a thin wrapper view on lldb, with not much suffix to Rust done from their CLion work, so it's lucky it works at all I suppose!

At least since Nim v1.6 uses ARC/ORC memory management avoiding the use of a Garbage Collector, and I think since v2.0 this is the default. ARC/ORC is some form of scope and destructor based memory management, similar to Rust and C++. This avoids all the drawbacks of a traditional GC, while providing all its benefits. Nim's ORC can even handle cyclic data structures, while Rust might create memory leaks for these. The fact hat Nim creates intermediate C code is more an implementation detail, and provides no disadvantages. An unofficial LLVM backend is available as well, and for the just released version 2.2 they seems to plan even to support direct native machine code generation, perhaps then combined with incremental compilation. But I finally left Nim 18 months ago, so I am not any more familiar with the most recent changes.

1 Like

Depending on what types of applications you were trying to write, you could have a look at the underrated F#. It shares a subset of the robustness concepts from Rust, while being syntactically simpler and more concise, and you can still access the ecosystem you were familiar with from C#.

It also has a couple of "superpowers" - type providers and units of measure - that enable you to play very nicely in the AI and scientific computing world, if that's of interest. It's also cross-platform and has Jupyter Notebook support.

1 Like

I'm assuming that eventually Microsoft will provide Rust tooling in Visual Studio that is comparable to their Visual C++. they said about a year ago that they intended to provide "first-class tooling," without elaborating further and I've heard nothing since.

But there will be a catch - Visual Studio requires a Windows host, although with C++ you can cross-compile and remote debug in Linux (personally, I've not used C++ for well over a decade).

Or "first-class tooling" may mean an enhanced package for VS Code.

Either way, there might be a long wait.

There's Pony, but it's taking a very long time (> 10 years?) to reach 1.0 and I've no idea whether it will be a goer or not. Designed for high-performance, concurrent, and distributed systems.

Similar focus on safety and robustness. Eiffel-like syntax.

I know quite a few languages, from C to F# even against my will, PL/SQL... Once you've experienced C#, and WPF, the bar is set high, from a programming language design point of view, C# is a masterpiece... from this guy Anders Hejlsberg, worked on Pascal, Turbo Pascal, then latter C# and Typescript... because there are no "obscure" ways, or clumsy workarounds, it is coherent and clean, it is not hard to start learning, but given all the new (or inspired) constructs and imperative (in unsafe it's just C at that point, useful for pinvoke)/declarative/OO/functional paradigms and also concurrent, highly distributed, context oriented.. and indeed the tooling is very good. Poor Java had to deal with terrible tooling, and was attacked by Spring and NHibernate, which are terrible, but against the rule "create as few objects as possible", a teacher said that once, I still follow that rule... I like the topic a lot, so seeing Python, good as scripting and automation language used now for anything because it is "easy" (building software is not easy, and easy is not a valid reason, overcomplicated isn't either...) is sometimes a pain really :smiley: Then I'm not a full-time dev, nor an enterprise architect, but I do both, lot of C - I used ipc and python a few times to avoid long tedious C, works well (with HSM calls, OpenSSL :broken_heart:, tens of millions of TLS + specific protocol (payments)) or my team also rebuilt the monitoring for all systemic platforms (cool stuffs, HP non stop, open vms, old message queues, the rest is Linux or Windows, but no explanation like always), le generic host dans dotnet core est un excellent composant... support for systemd/service Windows, client, serveur for rich web platforms/or just a rest endpoint, anything...

So all this to say that I like Rust quite a lot, it isn't just memory safe C, the syntax and concepts are elaborate, very modern, and indeed not that easy, but it does not need to become cryptic... I'm only beginning, but it's been a long time since I had some enthusiasm for some languages... which is really needed, given the number of vulnerabilities still due to C.. and no one is immune, and this is part of software, at least on the Linux Kernel side, there is plenty of info, Microsoft has an entire portal with all the info you may imagine (they also are the leading cybersecurity company worldwide, they don't parade much, this avoid a lot of clueless sarcasms from tech illiterates, they is enough already) and the most secure OSes ever, Apple's embedded, simplistic, are very present, and no info of course...

The tooling, so the package management is a good point.. but both the Linux Kernel, Windows', Firefox oc, and Apache httpd for instance too, seem ready, and supply chain must be secure too..

For Visual Studio, I read it, remote development works very well (in VSCode too) I work like that for a long time, whether Linux or Windows Server (+ HSM, or some DB, or some resources aren't locally available), I did not see any official roadmap about Rust, but in the telemetry I saw unusual files... now I know, they are metadata that allows to build a rust crate with access to the Win32 sub, also for C#, but in fact any language...
Otherwise, there is an unofficial extension pack or rust.. not well integrated, but working...
And Visual Studio on Linux, is not likely to ever happen, because VS is not a text editor, it's a entire platform, UML, DB design, dev, debug, profiling, code metrics and analysis, testing, devops, azure and other clouds, containers, office and VS extensions, but also all the gaming features, used by pretty much all game studios, PlayStation included... quite a lot of change in Windows, WinUI3 which is pretty good, AI + ML + Data science.. There is no such platform on any other OS, but this is Windows...a vast and complex set of platforms ^^ not a taskbar and a start menu... and it works quite well... They had the same question: Visual Studio for Linux - Developer Community "We need a lot of MS IDE for Linux, VSCode is very good for front end, but we have specific needs in the backend that only an IDE can supply. I do not understand why VS for mac already exists and for Linux nothing !!" the first message, the few hundreds that follow are insults about Microsoft, the stupid employees, wife's or partner and kids, the cat too, educated statements about Windows, then We want VS, it's good there is nothing like it (??????), but free, open source, and now ! I had some fun replying...

Ah and maybe some functional language would help with Rust, it's not obvious but F#, the F is for fun... :wink: I used to do a lot of exercices on hackerank...