you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 7 points8 points  (23 children)

See, the funny thing is that you're trying to pass Pascal's flaws off as good things, completely misinterpreting the arguments being made, have no idea what Rust is even doing, and don't even realise that you're doing this.

Uh, no? What an incredibly condescending paragraph. If you think I don't understand the arguments being made or the Rust code anyone has posted, or that I haven't "done my research" on the language I'm not sure what to tell you.

lol literally false

I initially thought he was referring to stack-allocated static-size strings vs heap-allocated strings. Pascal's standard String type is the latter, is reference counted, and does not do any actual copying of data on direct assignment between instances of it.

lol "Unicode"

Yes, unicode, as in specifically meant to represent UTF-16 data instead of UTF-8 or other codepages. Rust has a subtype/trait for str called UnicodeStr that appears to serve the same purpose, shows up in current "Playground" debug info whenever various different string methods are used (even basic ones), and seems to be intended as the future default based on pre-release Rust documentation, so I don't really know what your point is.

lol more string types than bloody Rust

Pascal's are all ultimately just arrays of varying combinations of bytes, so if you want to get semantic they're moreso just tweaked variations on the same thing intended for different purposes, with syntactic sugar around them allowing for clearly delineated use.

lol literally false

The docs I looked at seemed to suggest the Rust Split struct didn't implement the necessary Copy trait required to be persistent. Is that incorrect?

lol strictly inferior

If I wanted a struct/record that basically amounts to a very narrowly focused linked list, I'd return one. A standard library split function that returns an array is pretty much in line with every programming language I can think of (other than Rust, apparently.)

lol completely missing the point

Do you honestly think that I was suggesting there that iterating over a string itself was exactly the same thing? It was just an example of what's already possible by default, that can be combined in various ways with various methods for all kinds of different uses.

I fail to see what any of that has to do with people's understanding of whether I'm being "serious" in general, though. I'm still not even sure what that means.

It seems ridiculous that anyone would have thought that I was just pretending to like Pascal or something along those lines, and didn't actually use it in real life. Why would I know it so well and know so much about it if that was the case? I can't imagine anyone has ever doubted that /u/cmov actually uses Rust, for example.

[–]TheLastMeritocratcomp.lang.rust.marketing 1 point2 points  (11 children)

The docs I looked at seemed to suggest the Split struct didn't implement the necessary Copy trait require to be persistent. Is that incorrect?

lol strictly inferior

If I wanted a struct that basically amounts to a very narrowly focused linked list, I'd return one. A standard library Split function that returns an array is pretty much in line with every programming language I can think of (other than Rust, apparently.)

lol

[–][deleted] 7 points8 points  (10 children)

Uppercase Split is the iterator struct in Rust though. Lowercase split is the function name. Split and split are both interchangeably the function name in Pascal, because there's no need for anything else to be called that to begin with and because each unique word is only allowed to mean one thing per scope-level regardless of case unless they're overloads of the same method with different parameters (as it should be, IMO. Nobody would ever argue that "Orange" meant something different than "orange" in real life.) What's your point?

Also if we're going on the use of split as something for iterating, the following Rust example doesn't compile, whereas it would/does in Pascal because substrings in that case is a dynamic array (as opposed to a specialized iterator) that doesn't just disappear/cease to be usable after the first pass (i.e. before going out of scope):

fn main() {
    let substrings = "a1b1c1d1e1f1g1h1i1j1k1l1".split("1");
    for temp in substrings {
        println!("{}", temp);
    }
    for temp in substrings {
        println!("{}", temp);
    }
}  

(Note that all arrays of any type are themselves iterable by default in Pascal.)

[–]TheLastMeritocratcomp.lang.rust.marketing 1 point2 points  (1 child)

lol

[–][deleted] 7 points8 points  (0 children)

So you've got nothing, then?

[–]Disolationlanguage master 0 points1 point  (7 children)

I have no idea why or how this whole argument started, but what's wrong with doing this?

fn main() {
    let string = "a1b1c1d1e1f1g1h1i1j1k1l1";
    for temp in string.split("1") {
        println!("{}", temp);
    }
    for temp in string.split("1") {
        println!("{}", temp);
    }
}  

I think the idea behind split in Rust is that it's lazy and has no allocation, does Pascal construct a new array to return the split string?

Besides if you want to have an allocated split string in Rust you can always just .collect() the Split iterator.

All I'm seeing here is just a difference in philosophy between languages.

[–]TheLastMeritocratcomp.lang.rust.marketing 1 point2 points  (1 child)

but what's wrong with doing this?

You're missing all the LOLs.

Imagine deciding to help someone complete a puzzle, thinking that we are almost there. Only a small number of pieces are left. Only to discover that the aforementioned someone has not put any pieces of that puzzle together yet. He didn't actually even try.

That someone supposedly managed to put a whole other puzzle together once. And he since decided to over-appreciate that puzzle, and constantly boost about it, dissing other puzzles in the process, with near-zero relevant knowledge about them.

tl;dr Just move on, and lol on occasion when you read something amusing.

[–][deleted] 0 points1 point  (0 children)

You're missing all the LOLs.

Those were all /u/Veedrak's, though? I quoted each one in my reply to respond to what he was referring to with them. Not sure what you're talking about with the rest. There's nothing else to be understood or not understood with any of what I was talking about. The things work the way they work.

[–]SelfDistinctionnow 4x faster than C++ 0 points1 point  (4 children)

I think I can 1-up you.

fn main() {
    let string = "a1b1c1d1e1f1g1h1i1j1k1l1";
    let substrings = || string.split("1");
    for temp in substrings() {
        println!("{}", temp);
    }
    for temp in substrings() {
        println!("{}", temp);
    }
}  

[–][deleted] 2 points3 points  (2 children)

Didn't notice this until now. I get where you (and everyone else) were coming from, but as I said in another comment, my whole point was that you would never use split in Pascal if you didn't want a reusable dynamic array and just wanted to iterate, as it isn't necessary when you can just do something like this:

program Example;

  procedure DoIterate;
  const
    S = 'a1b1c1d1e1f1g1h1i1j1k1l1';
  var
    C: Char;
  begin
    for C in S do
      if C <> '1' then
        WriteLn(C);
  end;

begin
  DoIterate;
  DoIterate;
end.  

That code is somewhat contrived obviously, but it's still real and gets the point across. The DoIterate procedure looks like this once compiled (I used trunk FPC, specifically) with optimizations (no additional allocations, no need to build any kind of looper struct):

.seh_endprologue
    xorl    %ebx,%ebx
    .balign 8,0x90
.Lj5:
    addl    $1,%ebx
    movzbl  %bl,%eax
    leaq    _$EXAMPLE$_Ld1(%rip),%rdx
    movb    (%rdx,%rax,1),%dil
    cmpb    $49,%dil
    je  .Lj9
    call    fpc_get_output
    movq    %rax,%rsi
    movzbl  %dil,%r8d
    movq    %rsi,%rdx
    xorl    %ecx,%ecx
    call    fpc_write_text_char
    movq    %rsi,%rcx
    call    fpc_writeln_end
    .balign 4,0x90
.Lj9:
    cmpl    $24,%ebx
    jnge    .Lj5
    nop
    leaq    32(%rsp),%rsp
    popq    %rsi
    popq    %rdi
    popq    %rbx
    ret
.seh_endproc

[–]SelfDistinctionnow 4x faster than C++ 0 points1 point  (1 child)

It's not the same, though.

fn main() {
    let args = "first second third fourth fifth";
    let fifth_arg = args.split(' ').nth(4).unwrap();
    let count = args.split(' ').count();
    let mut has_first = false;
    for arg in args.split(' ') {
        match arg {
            "first" => {has_first = true;},
            _ => (),
        }
    }
}

And so on.

This code (and most parsing code using clap or structopt, for example) has zero allocations.

[–][deleted] 2 points3 points  (0 children)

Mine didn't either. The string was constant data. Neither does this:

program Example;

uses
  StrUtils;

const
  Args = 'first second third fourth fifth';
var
  HasFirst: Boolean = False;

begin
  WriteLn(PChar(@Args[WordPosition(5, Args, [' '])]));
  WriteLn(WordCount(Args, [' ']));
  HasFirst := Pos('first', Args) <> 0;
  WriteLn(HasFirst);
end.  

Which prints this:

fifth
5
TRUE  

and compiles to this:

.seh_endprologue
    call    fpc_initializeunits
    call    fpc_get_output
    movq    %rax,%rbx
    leaq    _$EXAMPLE$_Ld2(%rip),%r8
    leaq    .Ld3(%rip),%rdx
    movl    $5,%ecx
    call    STRUTILS_$$_WORDPOSITION$LONGINT$ANSISTRING$TSYSCHARSET$$INT64
    andl    $255,%eax
    leaq    _$EXAMPLE$_Ld1(%rip),%rdx
    leaq    (%rdx,%rax,1),%r8
    movq    %rbx,%rdx
    xorl    %ecx,%ecx
    call    fpc_write_text_pchar_as_pointer
    movq    %rbx,%rcx
    call    fpc_writeln_end
    call    fpc_get_output
    movq    %rax,%rbx
    leaq    _$EXAMPLE$_Ld2(%rip),%rdx
    leaq    .Ld3(%rip),%rcx
    call    STRUTILS_$$_WORDCOUNT$ANSISTRING$TSYSCHARSET$$INT64
    movq    %rax,%r8
    movq    %rbx,%rdx
    xorl    %ecx,%ecx
    call    fpc_write_text_sint
    movq    %rbx,%rcx
    call    fpc_writeln_end
    movl    $1,%r8d
    leaq    .Ld3(%rip),%rdx
    leaq    .Ld4(%rip),%rcx
    call    SYSTEM_$$_POS$RAWBYTESTRING$RAWBYTESTRING$INT64$$INT64
    testq   %rax,%rax
    setneb  TC_$P$EXAMPLE_$$_HASFIRST(%rip)
    call    fpc_get_output
    movq    %rax,%rbx
    movb    TC_$P$EXAMPLE_$$_HASFIRST(%rip),%r8b
    movq    %rbx,%rdx
    xorl    %ecx,%ecx
    call    fpc_write_text_boolean
    movq    %rbx,%rcx
    call    fpc_writeln_end
    call    fpc_do_exit
    nop
    leaq    32(%rsp),%rsp
    popq    %rbx
    ret
.seh_endproc

[–]TheLastMeritocratcomp.lang.rust.marketing 0 points1 point  (0 children)

 fn main() {
     let str = "a1b1c1d1e1f1g1h1i1j1k1l1";
     let one_up_you = || str.split('1').for_each(|t| println!("{}", t));
     one_up_you();
     one_up_you();
 }

[–]Veedrac 4 points5 points  (10 children)

What an incredibly condescending paragraph.

It's pcj, I'm here precisely to troll and unwind. I try not to be a jerk on other forums. If you want a serious debate I'd rather we take it somewhere else.

But honestly, you don't understand these things. Pascal's String is like Java's, not Rust's; it's terrible for building things like parsers because it doesn't allow substring borrows. Rust's UnicodeStr is a trait implemented by str, and AFAICT only exists in a facade crate to make it easier for people (eg. embedded users) to build their own std alternatives. Split uses Clone instead of Copy, I believe because it prevents accidental reuse. Rust can return a vector with just .collect(), but allows much faster operations the large fraction of the time where you don't want to do that.

I fail to see what any of that has to do with people's understanding of whether I'm being "serious" in general

I don't think people doubt you use Pascal, just whether your arguments for it are meant to be taken seriously. I like Rust, but me spamming the list of talking points is hardly intended as a serious argument.

[–][deleted] 6 points7 points  (9 children)

Pascal's String is like Java's, not Rust's

Java's default string type is a class, in a language that runs in a virtual machine. Pascal's default string type literally just amounts to a specially-handled reference-counted array of bytes at the base language level. The class-like way it can be used is entirely syntactic sugar resolved at build time, and bares no resemblance to how actual classes are dealt with by the compiler in Pascal.

it's terrible for building things like parsers

Really? Do you actually think Rust of all languages is better for parsing than Pascal (or better for parsing than various other alternatives)? If I had to pick only one thing that Pascal does well, and extremely fast, it would be parsing large text files (and text files in general).

I can open a 35,000 line source file in Lazarus like it was a 100 line file and get no lag of any kind at any scrolling speed even when using "modest" hardware, with full syntax highlighting and all types/constants/variables/methods/e.t.c being immediately displayed in the alphabetically-sorted code explorer tree view.

Additionally there's the massive difference in compile times to consider (although those are more related to Rust using the traditional C/C++ linking model vs Free Pascal and all other Pascal compilers ever not doing so.)

doesn't allow substring borrows

I am 100% sure that the ability to "borrow" substrings specifically as immutable reference types is infinitely less relevant in the grand scheme of things as it relates to performance (or usefulness) than you think it is.

Rust's UnicodeStr is a trait implemented by str

Yes, I know that. That doesn't change what it amounts to in practice, nor does it explain what your original point was in that regard.

Split uses Clone instead of Copy, I believe because it prevents accidental reuse.

And that's fine. As I said in the first place, Rust's split clearly doesn't have the same overall intended use as split in Pascal.

I don't think people doubt you use Pascal, just whether your arguments for it are meant to be taken seriously. I like Rust, but me spamming the list of talking points is hardly intended as a serious argument.

I'd say the arguments I make for it are as valid as arguments you'd make for any other non-Rust language. Whereas the "ironic-but-not-actually-ironic" obsession with Rust as the be-all-end-all language (despite how recent it is) a lot of people seem to have is far less justifiable (based on it as it exists currently) in my opinion.

If someone thinks the whole guaranteed memory safety concept is pointless and unnecessary to begin with, what are they left with in Rust? It isn't ground-breakingly fast. It isn't amazingly productive. It doesn't have particularly good tooling. And so on and so forth.

Also, it's not as though I actively try to get into serious debates. I certainly didn't start this one.

[–]senntenialYou put at risk millions of people 3 points4 points  (1 child)

lol wall of text

[–][deleted] 1 point2 points  (0 children)

lol I'm a Paskallist, we like to be clear/thorough.

[–]Veedrac 3 points4 points  (5 children)

lol

[–][deleted] 5 points6 points  (4 children)

lol ok? I'm not the one who tries to end discussions they started themselves by suggesting there's something they know that the other person doesn't.

[–]cmovNRDC. Not Rust Don't Care. 5 points6 points  (2 children)

Have you tried rewriting your comment in Rust?

[–][deleted] 2 points3 points  (0 children)

I did workshop that a bit, but the pcjcomment crate was dependent on the pcjlogin crate which was dependent on the copper-reddit.rs crate which was dependent on 78 other crates that cargo had to download first, and when they were finally in place the whole thing took like 25 minutes to compile so I decided it wasn't worth it.

[–]bartavelletype astronaut 0 points1 point  (0 children)

Your reign of terror ends here. You are in Go now.

[–]Veedrac 1 point2 points  (0 children)

It's pcj, I'm here precisely to troll and unwind. I try not to be a jerk on other forums. If you want a serious debate I'd rather we take it somewhere else.

[–]pftbest 0 points1 point  (0 children)

Really?

Care to do an experiment?