4 ms·

I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. The python scripts of the same vintage have to be reworked because python vers

I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. The python scripts of the same vintage have to be reworked because python versions and importantly supporting libraries have changed. This is mainly because Perl hasn’t changed, with the failure of perl6 to launch. But it’s an interesting comparison. I’ll agree Rust will be like like Java.

adamc 2y ago
I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though. Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.
- tadfisher 2y ago
  The real comparison is between Rust and C++, even though folks seem to be pushing Rust for web services and internal tooling. And modern C++ is an absolute monster in terms of complexity, often just dancing around problems that Rust solves pretty elegantly with ownership and lifetimes.
  - pjmlp 2y ago
    However that comparision misses that C++ is reaching 50's, while Rust still isn't allowed to drink.
    - phi-go 2y ago
      What's your point? Doesn't it only matter where things are now, not how long it took to get there? Or is this about more people knowing C++?
pdimitar 2y ago
RE: scripts, I find Golang better and better for this nowadays. Uber-fast compilation, to the point of it being acceptable to just instead do `go run your_thing.go` even, and you have access to a very solid runtime and many libraries for most of what people usually need. I don't argue with the portability and longevity of Perl but it too has its problems.
- fredrikholm 2y ago
  The longevity of Go is also a thing. I have not encountered a single Go project that used to compile but now doesn't because it hadn't been touched. Go is in many ways leap years ahead of most AOT languages I've used in anger. Yes, sometimes you miss XYZ, but seldom is that an issue outside of personal preferences. What you do get though is amazing tooling and little-to-no downtime. Builds basically don't take any time, tests run past, pipelines are quick. go test ./... finishes faster than you can print Determining projects to restore... to the screen. It's a very liberating experience that is hard to go back from.
  - pjmlp 2y ago
    Still leaves a lot to be desired versus Object Pascal from Apple/Borland days, or Delphi afterwards.
    - tashmahalic 2y ago
      What makes those better?
      - pjmlp 2y ago
        The language features, designed for full stack systems programming, IDE tooling, the frameworks bundled with the compiler, first class support for binary libraries ecosystem, no culture against modern times...
      - metadat 2y ago
        People used to whip up Delphi GUI apps in an hour or two. I'm not sure how to achieve this so efficiently with "modern" tools and languages. Maybe Python, but it doesn't compile to a static bin.
gwd 2y ago
> I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. I'm not talking primarily about Perl as a technology in and of itself, but as a long-term technology choice in terms of being able to find people to maintain and improve it. The Xen Project has a bunch of support stuff (automated testing and tooling around doing security work) written Perl. It was just about a reasonable decision when it started to be written 10-15 years ago; Golang was too young, Rust wasn't written yet, and Python had its downsides. But when the author of the code left the project 2-3 years ago, and there was 1) nobody with a similar level of expertise to maintain it, 2) nobody particularly wanted to gain that expertise, and 3) it wasn't easy to find someone else to pay to do maintenance. If you've managed to find people who can maintain those perl scripts, more power to you; but it unless perl5 can get some momentum back, it seems like it's going to be harder and harder to find replacements.
- sshine 2y ago
  The thing about Perl developers is they tend to stick around. At the last Perl shop I worked for, the average employment time must have exceeded 10 years. I could say the same of Prolog and 25 year average employments.

adamc 2y ago

I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though. Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.

tadfisher 2y ago
The real comparison is between Rust and C++, even though folks seem to be pushing Rust for web services and internal tooling. And modern C++ is an absolute monster in terms of complexity, often just dancing around problems that Rust solves pretty elegantly with ownership and lifetimes.
- pjmlp 2y ago
  However that comparision misses that C++ is reaching 50's, while Rust still isn't allowed to drink.
  - phi-go 2y ago
    What's your point? Doesn't it only matter where things are now, not how long it took to get there? Or is this about more people knowing C++?

pdimitar 2y ago

RE: scripts, I find Golang better and better for this nowadays. Uber-fast compilation, to the point of it being acceptable to just instead do `go run your_thing.go` even, and you have access to a very solid runtime and many libraries for most of what people usually need. I don't argue with the portability and longevity of Perl but it too has its problems.

fredrikholm 2y ago
The longevity of Go is also a thing. I have not encountered a single Go project that used to compile but now doesn't because it hadn't been touched. Go is in many ways leap years ahead of most AOT languages I've used in anger. Yes, sometimes you miss XYZ, but seldom is that an issue outside of personal preferences. What you do get though is amazing tooling and little-to-no downtime. Builds basically don't take any time, tests run past, pipelines are quick. go test ./... finishes faster than you can print Determining projects to restore... to the screen. It's a very liberating experience that is hard to go back from.
- pjmlp 2y ago
  Still leaves a lot to be desired versus Object Pascal from Apple/Borland days, or Delphi afterwards.
  - tashmahalic 2y ago
    What makes those better?
    - pjmlp 2y ago
      The language features, designed for full stack systems programming, IDE tooling, the frameworks bundled with the compiler, first class support for binary libraries ecosystem, no culture against modern times...
    - metadat 2y ago
      People used to whip up Delphi GUI apps in an hour or two. I'm not sure how to achieve this so efficiently with "modern" tools and languages. Maybe Python, but it doesn't compile to a static bin.

gwd 2y ago

> I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine. I'm not talking primarily about Perl as a technology in and of itself, but as a long-term technology choice in terms of being able to find people to maintain and improve it. The Xen Project has a bunch of support stuff (automated testing and tooling around doing security work) written Perl. It was just about a reasonable decision when it started to be written 10-15 years ago; Golang was too young, Rust wasn't written yet, and Python had its downsides. But when the author of the code left the project 2-3 years ago, and there was 1) nobody with a similar level of expertise to maintain it, 2) nobody particularly wanted to gain that expertise, and 3) it wasn't easy to find someone else to pay to do maintenance. If you've managed to find people who can maintain those perl scripts, more power to you; but it unless perl5 can get some momentum back, it seems like it's going to be harder and harder to find replacements.

sshine 2y ago
The thing about Perl developers is they tend to stick around. At the last Perl shop I worked for, the average employment time must have exceeded 10 years. I could say the same of Prolog and 25 year average employments.