4 ms·

At some point you’ve got to stop messing with syntax. It plain sucks not being able to run anything on a linux machine that is on a LTS schedule. The constant c

by gizmo 3y ago

At some point you’ve got to stop messing with syntax. It plain sucks not being able to run anything on a linux machine that is on a LTS schedule. The constant churn of version updates that fix some things but break other things is a massive time waste. It’s practically impossible to remove features from a language. If you keep adding “improvements” to your language you end up with the unholy mess that is modern c++

UncleEntity 3y ago
Isn't the whole point of LTS to outsource all this nonsense to the maintainers of the distro? Back when I was heavily involved in blender development I'd sometimes have to pause my hackery while waiting for fedora to catch up with whatever version of python blender was using because I didn't want to bork my system by upgrading python (again!). Well(...) I also wanted to ensure that it would run off libs from the repos and this was a little higher priority than being on the cutting edge so it was a sacrifice I was willing to make. The only time this caused any significant delay also coincided with one of the open movies and they didn't want to merge what I was working on until after production which meant it didn't matter either way. I don't ruby but it seems like a nice way to do something like: def apply(callable, ...): callable(...)
regularfry 3y ago
In practical terms, if you're using the distribution's interpreters for anything other than running code supplied by the distro, you're going to be in a world of pain. That is the whole point of a distro: to supply a known-good set of mutually compatible software. Expect to be building your own environments if you want to run things that are not in your distro.
- pixel8account 3y ago
  I can't relate. I'm a Python programmer and I don't think I ever used a Python version other than the one provided by my distro. Unless you run a very outdated/"stable" distribution, interpreter versions are no more than few years old. Most serious projects don't just jump on the new language version on the day it's released, certainly not my projects, so I never had the need to run a bleeding edge interpreter.
  - senkora 3y ago
    I think that the GP has hit on something deeply true (distros are mutually compatible bundles of software which aren't guaranteed or even intended to work with your dev environment). I think it is also true that this is not usually a problem for Python in practice for small-to-medium projects. I will note that most places I have worked professionally with Python code have compiled their own CPython interpreter and not relied on the distro version.
  - still_grokking 3y ago
    > Unless you run a very outdated/"stable" distribution LTS is exactly this pain! I really don't understand why anybody would use that for development. Your SW won't land anyway in the current "stable" distri release, but at the earliest in the "next" version. So you need to develop against that "next" version anyway. The "next" version is something like Debian Testing… And if you don't plan to release your SW properly into a distri you need to bring your own environment anyway.
still_grokking 3y ago
First of all, don't run anything "LTS" on a dev box. You really want a "rolling release" for that purpose. Something like Debian Testing (as it's the most compatible). Secondly it's very well possible to remove features from a language. It just needs to be well enough designed that there is a good migration story (ideally though automatic rewrite by the compiler). Just see what Scala 3 did! https://docs.scala-lang.org/scala3/reference/dropped-features/index.html https://docs.scala-lang.org/scala3/reference/dropped-feature...
- mekster 3y ago
  > don't run anything "LTS" on a dev box. You really want a "rolling release" for that purpose. No. Give the same environment as production.
  - still_grokking 3y ago
    You don't run your dev tools on the production boxes. And you don't run your apps directly on the production boxes either these days. There is just no reason to endure the constant pain of outdated dev environments. Of course that doesn't mean that you can't develop against a stable environment, in case you plan to deploy directly onto such thing. That's usually independent of your tooling. You just need to look for the right versions of your deps (which is trivial within some "container"; which runs of course on your up to date dev box).
    - mekster 3y ago
      I didn't say run on the production box. I said, create an identical environment as the production box.

by gizmo 3y ago

UncleEntity 3y ago

Isn't the whole point of LTS to outsource all this nonsense to the maintainers of the distro? Back when I was heavily involved in blender development I'd sometimes have to pause my hackery while waiting for fedora to catch up with whatever version of python blender was using because I didn't want to bork my system by upgrading python (again!). Well(...) I also wanted to ensure that it would run off libs from the repos and this was a little higher priority than being on the cutting edge so it was a sacrifice I was willing to make. The only time this caused any significant delay also coincided with one of the open movies and they didn't want to merge what I was working on until after production which meant it didn't matter either way. I don't ruby but it seems like a nice way to do something like: def apply(callable, ...): callable(...)

regularfry 3y ago

In practical terms, if you're using the distribution's interpreters for anything other than running code supplied by the distro, you're going to be in a world of pain. That is the whole point of a distro: to supply a known-good set of mutually compatible software. Expect to be building your own environments if you want to run things that are not in your distro.

pixel8account 3y ago
I can't relate. I'm a Python programmer and I don't think I ever used a Python version other than the one provided by my distro. Unless you run a very outdated/"stable" distribution, interpreter versions are no more than few years old. Most serious projects don't just jump on the new language version on the day it's released, certainly not my projects, so I never had the need to run a bleeding edge interpreter.
- senkora 3y ago
  I think that the GP has hit on something deeply true (distros are mutually compatible bundles of software which aren't guaranteed or even intended to work with your dev environment). I think it is also true that this is not usually a problem for Python in practice for small-to-medium projects. I will note that most places I have worked professionally with Python code have compiled their own CPython interpreter and not relied on the distro version.
- still_grokking 3y ago
  > Unless you run a very outdated/"stable" distribution LTS is exactly this pain! I really don't understand why anybody would use that for development. Your SW won't land anyway in the current "stable" distri release, but at the earliest in the "next" version. So you need to develop against that "next" version anyway. The "next" version is something like Debian Testing… And if you don't plan to release your SW properly into a distri you need to bring your own environment anyway.

still_grokking 3y ago

First of all, don't run anything "LTS" on a dev box. You really want a "rolling release" for that purpose. Something like Debian Testing (as it's the most compatible). Secondly it's very well possible to remove features from a language. It just needs to be well enough designed that there is a good migration story (ideally though automatic rewrite by the compiler). Just see what Scala 3 did! https://docs.scala-lang.org/scala3/reference/dropped-features/index.html https://docs.scala-lang.org/scala3/reference/dropped-feature...

mekster 3y ago
> don't run anything "LTS" on a dev box. You really want a "rolling release" for that purpose. No. Give the same environment as production.
- still_grokking 3y ago
  You don't run your dev tools on the production boxes. And you don't run your apps directly on the production boxes either these days. There is just no reason to endure the constant pain of outdated dev environments. Of course that doesn't mean that you can't develop against a stable environment, in case you plan to deploy directly onto such thing. That's usually independent of your tooling. You just need to look for the right versions of your deps (which is trivial within some "container"; which runs of course on your up to date dev box).
  - mekster 3y ago
    I didn't say run on the production box. I said, create an identical environment as the production box.