Hacker News Reader

Comment by MathMonkeyMan | Hacker News Reader

It's disappointing that this is the state of things from a "working programmer" perspective.

Racket is, as far as I understand, a research and teaching language, as well as a viable scheme.

I've used it for some [command line tools and side projects][1], but I never tried to deploy anything with it.

Maybe a new [Chez][2]-based (as Racket now is) scheme is needed: one with much of Racket's nice syntax system, but focused on dependency management, targeted solely at "production" use, and other Serious Business Purposes.

Not it!

I'm not saying that Racket isn't a serious platform -- far from it. But the author's concerns, while expressed as a hot take, might be why Racket doesn't see wider industry adoption.

Or maybe it's a chicken and egg problem.

[1]: https://github.com/dgoffredo?tab=repositories&q=&type=&langu...

[2]: https://www.scheme.com/

View on HN

> Or maybe it's a chicken and egg problem.

Maybe Chicken Scheme is the solution, then?

http://www.call-cc.org/

Chicken Scheme is great, but for production use you need an ecosystem.

For this reason Clojure and perhaps SBCL will dominate serious lisp dev.

Racket is a classic example of those peculiarly dysfunctional systems that emerge from an out of touch (dare I say ivory tower) academic community who think hype and prototypes are one step away from being enterprise ready.

I have daydreamed about making Racket more serious and calling it Tennis.

How about less serious and calling it Badminton?

I don’t see equivalent sobbing when somebody praise lets say Rust (random choice) for being productive, for the easiness of working with cargo or some other random stuff from the “working programmer perspective”.

Is this sad only when people have to talk about their pain points?

Op here.

It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now?

Better we look at the pain points now than accept a poor DX for years to come.

Totally ignoring your point and ranting about how much I hate Rust from easiness of working with.

Not the language itself (which I love) I can write code so quickly in it, and I didn't struggle for very long with fighting the borrow checker, which seems to turn so many other people off.

It's everything else. Long build times. "Modern" dependency management, which seems to mean package X only works with 0.6.x of package Z and package Y only works with 0.7.x of package Z and the current version of package Z is 0.8 and has a bugfix you really need. Though I should say that very few languages with a central repository don't have this problem; you make it easy to depend on libraries with unstable APIs and everyone will rush to do it.

So many people rushed to copy the node/Python dependency management system that nobody asked if it was really a good idea.

I totally agree that nailing everything down to the one particular minor rev causes way more problems than it solves. The worst part is I'm pretty sure you can be more general (give me version 3, or >3.3.1, not =3.3.1) but all of the automatic tools and online guides default to nailing it down to exactly one version because they're so damn paranoid about API changes.

I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.

> But it's remarkable how many old Perl programs can still pull the dependencies and start right up.

I was surprised when I installed `git` and it pulled a couple dozen Perl packages from the distro repo.

There's definitely something to be said about Linux distro maintainers/packagers being sort of middlemen that help enforce compatibility for popular Perl (or Python2, etc) packages.

That is, there is a nonzero amount of greybeards between the developer and random end user, which cannot be said for your average npm or pip package.

> I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.

The fact that CPAN avoids this makes me think it's largely cultural. At least some of it may be that CPAN came of age in an era when internet access was less reliable and slower.

Some of it is also that development "in the open" has become more the norm. When releases are rare and only contributors have VCS access, then there are fewer opportunities to depend on unstable interfaces.

That's already how Rust works. The post is referring to specific packages, not the whole resolution system; it is specifically 0.x versions that are incompatible at the minor revision. It is absolutely not the case that all the online tools and guides tell you to nail it down to one particular version - I have literally never seen a guide that told you to use =version notation. Finally, there's no difference between this and what you described as the Perl behavior: in both Perl and Rust, old packages with old dependencies still build.

> I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies,

Probably because CPAN existed before SemVer.

Given that patch version bumps of a dependency might break a project, I think giving up on the SemVer paranoia would be the best solution.

If a dependency breaks you just release a new patch release of your software with the version pinned before the breaking version. Add a field to the package manager to hint at the dep solver that it should never downgrade to remove that depedency because it was added due to a breaking change to sort of make it retroactive.

And the failure of many projects to go 1.0 because of paranoia about breaking changes and therefore the failure of SemVer should really be more widely discussed.

Rust is a terrible first language for someone trying to learn programming

Reply on news.ycombinator.com