7 ms·

Makes me wonder if there could be room for a SimpleString library. I love/use Rust. I don't think any of this is complicated. BUT, i'm a big fan of just "clone

Makes me wonder if there could be room for a SimpleString library. I love/use Rust. I don't think any of this is complicated. BUT, i'm a big fan of just "clone your problems away" for beginner Rust users. Going knee deep into techniques which merely reduce memory usage when people likely don't actually care - at all - about it just feels wrong to me. So yea, maybe a cursed library where SimpleString is just some niceties around some Cow + Arc thing which is also Copy. Hell, you could probably just apply it Vec and who knows what else. Anyway, clearly not something i'm advocating anyone _really_ use. But it seems a nice way to make stuff "Just Work" in the beginning.

codedokode 4y ago
But Rust is designed to write high-performance code. If you don't care about performace, you don't really need Rust. Swift or Go seem more readable and easier to use.
- astrange 4y ago
  Making memory management obnoxious by not handling copying for you doesn't really encourage performance. It just encourages people to prematurely optimize things that don't matter.
- howinteresting 4y ago
  Swift is well-designed but is virtually non-existent outside of Apple platforms, so it doesn't have nearly the third-party ecosystem that Rust does. Go has the third-party ecosystem but is poorly designed and doesn't have basic language features like sum types. Rust is likely the best combination of thought-out design and ecosystem support that exists in a programming language today.
  - pjmlp 4y ago
    Rust is also pretty much focused on Linux workloads, mostly. Also the Apple ecosystem has plenty of third parties, including commercial libraries.
    - jeroenhd 4y ago
      Interestingly, Microsoft is also pushing Rust quite hard with special API packages, tutorials, and even some IDE integration. Windows tools are often closed source, though, so you'll probably never notice it if your favourite tool uses Rust or not.
      - pjmlp 4y ago
        What IDE integration? VSCode plugins aren't done by Microsoft, finally they got a spot on MSDN docs as of last VSCode release. Currently there are no plans for proper VS tooling on par with C++ across all Windows development workloads. If you mean Rust/WinRT, the new toy from the folks that produced C++/WinRT, after they successfully managed to kill C++/CX and turn the UWP development experience back to the glory days of Visual C++ 6.0 with ATL 3.0 (apparently very dear to their hearts), then it isn't something I look forward to ever use, if C++/WinRT is any indication of their understanding about developer productivity. Or do you mean the Azure Sphere OS, with the whole security marketing sales pitch while have a C only SDK available, and only now evaluating if Rust is something they would support in addition to C. Working really hard? Doesn't look like it.
        mwcampbell 4y ago
        > Rust/WinRT, the new toy First, it's now called Rust for Windows (or windows-rs), because the scope has expanded to include (fairly low-level) bindings for all the Win32 and COM APIs in the Windows SDK. I strongly object to calling it a toy just because it doesn't have certain RAD conveniences. I'm happily using that crate (though currently only the Win32/COM portion) in the native parts of a Windows app I'm working on [1]. Yes, I have to use a lot of unsafe when working with the Win32 and COM APIs, but I keep my unsafe blocks as small as possible, and try to do as much as possible using safe Rust abstractions like slices and the various string types. FWIW, windows-rs recently removed the bindings for the Windows.UI.Xaml namespace, on the grounds that they were nearly unusable, and because the in-box Windows.UI.Xaml is no longer Microsoft's recommendation for app developers. I think the latter policy is a mistake, because some of us actually want to produce something with a minimal memory footprint, using a GUI toolkit that's already in the working set on all Windows machines. But maybe someone can bring back Windows.UI.Xaml bindings in a separate crate. > they successfully managed to kill C++/CX IMO C++/CX was a mistake. It was an attempt to make C++ into something it was not. From what I've read [2], C++/CX spectacularly failed to uphold C++'s zero-overhead principle, and the code size of newer shell components in Windows 10+ suffered as a result. Yes, I felt some of the frustration of working with the current (or at least, mid-2020) tooling for C++/WinRT when I was mentoring an intern on the Windows accessibility team at Microsoft (which I left later that year). But I think the Windows developer platform team had to do what was right for runtime efficiency. Developers who value rapid development over runtime efficiency can still use C#. > the glory days of Visual C++ 6.0 with ATL 3.0 They were glorious, for code footprint. But like you, I wouldn't want to write new code using ATL (and on the Windows accessibility team at Microsoft, we avoided that as much as practical). Luckily, C++/WinRT is a big improvement over ATL, thanks to modern C++. It's just a step backward from C++/CX for some RAD conveniences that were really a better fit for a language like C#. And to bring it back to Rust, I think Rust's macro system allows for some powerful high-level tooling on top of the WinRT bindings. For example, I think we could have a macro-based DSL for succinctly declaring a tree of UI elements, and that syntax could be more integrated with the rest of the language than the markup/code dichotomy that was introduced with WPF. Such tooling could also avoid the trap of boilerplate-heavy code generation that's typical of the Visual Studio wizards, and be available to developers who don't use VS. [1]: The non-native part is using Electron. I'd love to write the whole thing in Rust, but Electron in general, and access to Chromium's full WebRTC stack in particular, is just too convenient. [2]: https://devblogs.microsoft.com/oldnewthing/20220606-00/?p=106713 https://devblogs.microsoft.com/oldnewthing/20220606-00/?p=10...
- pjmlp 4y ago
  Swift is pretty much about performance, as replacement for C, C++ and Objective-C in the Apple ecosystem, it is even on Apple's official sites. What Apple isn't willing to do is sacrifice productivity while achieving that goal.
- lijogdfljk 4y ago
  Okay, maybe (i disagree, but w/e) - but the point is for learning. You'd have a difficult time learning Rust with Go, hah.
- Santosh83 4y ago
  Maybe, but Rust is also targetting higher levels of the stack like Webassembly, so I wouldn't say Rust is only meant for maximum bare metal performance/safety. Lots of higher level applications are also now being written (or rewritten) in Rust, so a canonical "simple string" crate won't be amiss I feel.
  - solar-ice 4y ago
    > Rust is also targetting higher levels of the stack like Webassembly The /reasonable/ Rust vision of Webassembly is "you write parts of your application in this when they need to be faster than javascript". You really shouldn't be writing your whole web application in Rust, frankly, there's no good reason to. (I write Rust for a living, and I reach for other languages the moment I'm trying to do Normal Web Stuff.) And if people are using wasm as a sandbox outside the browser, instead of a reasonable VM with all the garbage collection niceties, they're probably doing it wrong unless there is a reason to require developers to write low-level, performant code without a GC.
kzrdude 4y ago
Some weird construction around Cow + Arc that is also Copy is not really possible in Rust, I'm sorry to report. No way to implement it and even if you could (you technically "can" by reimplementing most of Cow and Arc) - the result is not useful, the destructor of it doesn't work.
- nyanpasu64 4y ago
  You can't override moving to run a copy constructor, and this is usually a good thing, as much as having one would be convenient for Rc/Arc (where cloning is an incref rather than an actual deep clone).
- lijogdfljk 4y ago
  Huh, i figured you could actually just implement `Copy` yourself (ie on the SimpleString). Can you not for this? Now you have me curious hah
  - kzrdude 4y ago
    You can't if the parts are not Copy. I wrote something hand wavy about reimplementing Cow/Arc but that doesn't really work either - atomics are not Copy, so that's another building block you need for Arc but can't have. Not mentioning the allocating bits because those are the obvious ones. Can't define a destructor for a Copy type, so literally nothing works.
    - lijogdfljk 4y ago
      TIL. I had just figured you could manually make an unsafe Copy impl or something haha.
nicoburns 4y ago
Isn't the SimpleString just String? Most of the complications disappear if you avoid str entirely. The one simplification which I would like to see added is support for string literals that produce a String. (s"foobar" syntax has been proposed).

codedokode 4y ago

But Rust is designed to write high-performance code. If you don't care about performace, you don't really need Rust. Swift or Go seem more readable and easier to use.

astrange 4y ago
Making memory management obnoxious by not handling copying for you doesn't really encourage performance. It just encourages people to prematurely optimize things that don't matter.
howinteresting 4y ago
Swift is well-designed but is virtually non-existent outside of Apple platforms, so it doesn't have nearly the third-party ecosystem that Rust does. Go has the third-party ecosystem but is poorly designed and doesn't have basic language features like sum types. Rust is likely the best combination of thought-out design and ecosystem support that exists in a programming language today.
- pjmlp 4y ago
  Rust is also pretty much focused on Linux workloads, mostly. Also the Apple ecosystem has plenty of third parties, including commercial libraries.
  - jeroenhd 4y ago
    Interestingly, Microsoft is also pushing Rust quite hard with special API packages, tutorials, and even some IDE integration. Windows tools are often closed source, though, so you'll probably never notice it if your favourite tool uses Rust or not.
    - pjmlp 4y ago
      What IDE integration? VSCode plugins aren't done by Microsoft, finally they got a spot on MSDN docs as of last VSCode release. Currently there are no plans for proper VS tooling on par with C++ across all Windows development workloads. If you mean Rust/WinRT, the new toy from the folks that produced C++/WinRT, after they successfully managed to kill C++/CX and turn the UWP development experience back to the glory days of Visual C++ 6.0 with ATL 3.0 (apparently very dear to their hearts), then it isn't something I look forward to ever use, if C++/WinRT is any indication of their understanding about developer productivity. Or do you mean the Azure Sphere OS, with the whole security marketing sales pitch while have a C only SDK available, and only now evaluating if Rust is something they would support in addition to C. Working really hard? Doesn't look like it.
      - mwcampbell 4y ago
        > Rust/WinRT, the new toy First, it's now called Rust for Windows (or windows-rs), because the scope has expanded to include (fairly low-level) bindings for all the Win32 and COM APIs in the Windows SDK. I strongly object to calling it a toy just because it doesn't have certain RAD conveniences. I'm happily using that crate (though currently only the Win32/COM portion) in the native parts of a Windows app I'm working on [1]. Yes, I have to use a lot of unsafe when working with the Win32 and COM APIs, but I keep my unsafe blocks as small as possible, and try to do as much as possible using safe Rust abstractions like slices and the various string types. FWIW, windows-rs recently removed the bindings for the Windows.UI.Xaml namespace, on the grounds that they were nearly unusable, and because the in-box Windows.UI.Xaml is no longer Microsoft's recommendation for app developers. I think the latter policy is a mistake, because some of us actually want to produce something with a minimal memory footprint, using a GUI toolkit that's already in the working set on all Windows machines. But maybe someone can bring back Windows.UI.Xaml bindings in a separate crate. > they successfully managed to kill C++/CX IMO C++/CX was a mistake. It was an attempt to make C++ into something it was not. From what I've read [2], C++/CX spectacularly failed to uphold C++'s zero-overhead principle, and the code size of newer shell components in Windows 10+ suffered as a result. Yes, I felt some of the frustration of working with the current (or at least, mid-2020) tooling for C++/WinRT when I was mentoring an intern on the Windows accessibility team at Microsoft (which I left later that year). But I think the Windows developer platform team had to do what was right for runtime efficiency. Developers who value rapid development over runtime efficiency can still use C#. > the glory days of Visual C++ 6.0 with ATL 3.0 They were glorious, for code footprint. But like you, I wouldn't want to write new code using ATL (and on the Windows accessibility team at Microsoft, we avoided that as much as practical). Luckily, C++/WinRT is a big improvement over ATL, thanks to modern C++. It's just a step backward from C++/CX for some RAD conveniences that were really a better fit for a language like C#. And to bring it back to Rust, I think Rust's macro system allows for some powerful high-level tooling on top of the WinRT bindings. For example, I think we could have a macro-based DSL for succinctly declaring a tree of UI elements, and that syntax could be more integrated with the rest of the language than the markup/code dichotomy that was introduced with WPF. Such tooling could also avoid the trap of boilerplate-heavy code generation that's typical of the Visual Studio wizards, and be available to developers who don't use VS. [1]: The non-native part is using Electron. I'd love to write the whole thing in Rust, but Electron in general, and access to Chromium's full WebRTC stack in particular, is just too convenient. [2]: https://devblogs.microsoft.com/oldnewthing/20220606-00/?p=106713 https://devblogs.microsoft.com/oldnewthing/20220606-00/?p=10...
pjmlp 4y ago
Swift is pretty much about performance, as replacement for C, C++ and Objective-C in the Apple ecosystem, it is even on Apple's official sites. What Apple isn't willing to do is sacrifice productivity while achieving that goal.
lijogdfljk 4y ago
Okay, maybe (i disagree, but w/e) - but the point is for learning. You'd have a difficult time learning Rust with Go, hah.
Santosh83 4y ago
Maybe, but Rust is also targetting higher levels of the stack like Webassembly, so I wouldn't say Rust is only meant for maximum bare metal performance/safety. Lots of higher level applications are also now being written (or rewritten) in Rust, so a canonical "simple string" crate won't be amiss I feel.
- solar-ice 4y ago
  > Rust is also targetting higher levels of the stack like Webassembly The /reasonable/ Rust vision of Webassembly is "you write parts of your application in this when they need to be faster than javascript". You really shouldn't be writing your whole web application in Rust, frankly, there's no good reason to. (I write Rust for a living, and I reach for other languages the moment I'm trying to do Normal Web Stuff.) And if people are using wasm as a sandbox outside the browser, instead of a reasonable VM with all the garbage collection niceties, they're probably doing it wrong unless there is a reason to require developers to write low-level, performant code without a GC.

kzrdude 4y ago

Some weird construction around Cow + Arc that is also Copy is not really possible in Rust, I'm sorry to report. No way to implement it and even if you could (you technically "can" by reimplementing most of Cow and Arc) - the result is not useful, the destructor of it doesn't work.

nyanpasu64 4y ago
You can't override moving to run a copy constructor, and this is usually a good thing, as much as having one would be convenient for Rc/Arc (where cloning is an incref rather than an actual deep clone).
lijogdfljk 4y ago
Huh, i figured you could actually just implement `Copy` yourself (ie on the SimpleString). Can you not for this? Now you have me curious hah
- kzrdude 4y ago
  You can't if the parts are not Copy. I wrote something hand wavy about reimplementing Cow/Arc but that doesn't really work either - atomics are not Copy, so that's another building block you need for Arc but can't have. Not mentioning the allocating bits because those are the obvious ones. Can't define a destructor for a Copy type, so literally nothing works.
  - lijogdfljk 4y ago
    TIL. I had just figured you could manually make an unsafe Copy impl or something haha.

nicoburns 4y ago

Isn't the SimpleString just String? Most of the complications disappear if you avoid str entirely. The one simplification which I would like to see added is support for string literals that produce a String. (s"foobar" syntax has been proposed).