5 ms·

For me the worse part of every new language is deal with ecosystem. Holy fuck. It is so annoying. Scattered info, standards, many solutions for the same thing a

by lerax 6y ago

For me the worse part of every new language is deal with ecosystem. Holy fuck. It is so annoying. Scattered info, standards, many solutions for the same thing and none is good, style guide, plugins and editors, debugging, packaging, testing, libraries, environment quirks, deployment compatibility, vendoring/semantic-versioning etc. Ironically, learning the language itself in general is the easy part, that other stuff that are just pain. I just love learning new languages, but I hate to deal with new ecosystems and all their bullshit. It is just terrible, always seems totally wrong for a outsider (ex.: JS with npm, .Net with versioning hell, Scala with sbt bugs, Haskell with Cabal Hell, Mobile dev with all complex setup) Fun thing: to make anything useful, dominate the ecosystem is essential. FucK.

lmm 6y ago
Don't bother using SBT. Just build Scala with Maven. It's wonderful, everything works how you'd expect, all the documentation from the Java world is still valid.
- auggierose 6y ago
  Maven is another sort of hell :-) Also, do you have good integration for building Scala.js as well?
  - lmm 6y ago
    I've never got the hate for Maven - all the design decisions people dislike seem to be the same things that people praise Cargo et al for. If anything it suffers for being ahead of its time. Use the Scalor plugin, https://github.com/random-maven/scalor-maven-plugin https://github.com/random-maven/scalor-maven-plugin, and then Scala.js just works. I actually hooked it up to Netlify by treating Maven as a static site generator: http://m50d.github.io/2018/11/29/deploying-scalajs-with-netlify http://m50d.github.io/2018/11/29/deploying-scalajs-with-netl...
- commandlinefan 6y ago
  > SBT Me: “How do I xxx in SBT?” Them: “Read the docs, n00b” Me: “what docs?” Them: ...
arendtio 6y ago
I think this is a point where Go is very good at and JavaScript sucks pretty hard. Mostly because Go brings many things by default and JavaScript has such a high rate at which new tools become mainstream/obsolete and so many options to choose from and combine with.
- mellosouls 6y ago
  Give Go another 15 years to catch up with JavaScript's current maturity and see where we are then with its ecosystem.
  - tempodox 6y ago
    If it still exists by then...
  - AmpsterMan 6y ago
    Go at the ten year mark and JS at the ten year mark can be compared, no? In general I find Go's tighter language philosophy and more expansive ecosystem out the gate to help alleviate many of these problems. You can't ever fix them completely, but I don't think that will ever happen without a giant corporation backing it.
  - moreaccountspls 6y ago
    I mean, Node and Go were released within 6 months of each other. When jquery was the dominant tool in the ecosystem, there wasn't nearly the level of breakage that there is now.
- loudlambda 6y ago
  I found the opposite to be true. With javascript I never saw the package.json not work for the other developers on the team; with go, half of my team can't successfully update vendoring for no apparent reason. Commands frequently error with messages that are completely worthless. Go seems to have made up it's own path syntax with things like "...", and commands like "go test foo/bar" will fail with an error message that gives no clue as to the problem, but work fine with "go test ./foo/bar". Why? What's the command to see if any of my dependencies have a CVE against them? Oh, there isn't one. What's the command to prompt me to pull in a new version of my dependencies? Oh, there isn't one. This is a language that has made some promise about backwards comparability, but every release seems to break how things are built, and you have to fiddle with bizarre environment variables like GO111MODULE to find the incantation to make things happy again.
TeMPOraL 6y ago
... C++ with CMake, oh wait Ninja, oh wait nevermind, and also you have to catch up on a bunch of random bloggers and various conference recordings to have a clue as to what are the community recommendations for the libraries, or coding standards. I 100% share your feelings.
- aldanor 6y ago
  When people compare C++ with Rust, quite often the only thing measured is performance where depending in your cxx compiler Rust (or rather, llvm) may lose sometimes. What is often forgotten is the ecosystem. To build a cxx project you'll probably need to learn CMake and ninja; maybe Buck or Bazel too. If your project has eternal dependencies you may have to figure out yourself how tl link everything together using whatever build tools the authors were using. For docs, you'll have to learn and use doxygen; for style formatting, something like a clang-format and its presets and options; for linting, something like clang-tidy or cpplint, etc. For testing, probably catch2 or one of similar frameworks. There's no universal concept of "package" or "version", you're completely on your own here; most open source cxx repos that have dependencies just add them as git submodules. In Rust, cargo build to build, cargo doc to generate docs, cargo test to run tests, cargo publish to push your crate to the index; cargo fmt to format the code and cargo clippy to lint it - that's it, we're done.
  - pydry 6y ago
    A large part of that is simply due to age, though. If rust were older it would have more baggage too, but also a larger ecosystem.
  - shpongled 6y ago
    In my experience, Rust certainly has one of the easiest language ecosystems to use. I've been using Rust for ~3 years now, and have been trying to learn C++, but I've been so spoiled by the entire Rust ecosystem's user friendliness that it's a very daunting task.
- lerax 6y ago
  Or Makefile, or Meson, or autotools... And beyond to infinite. Man, that type of stuff don't motivates anyone to learn a new language. If all what we should do it is code a solution and deploy with one command, oh God, will be a dream. But no, beyond all this clusterfuck, by doing cloud stuff will be need probably Docker too, Kubernetes. Maybe ansible too? Oh, no, your team use terraforms. D:
tasogare 6y ago
Visual Studio for C# development got this right: powerful language with super good IDE support and a rock solid standard library. Good documentation online too. It hides complexity that can bite later, and it can be complex to chose a framework to target, but otherwise it’s super easy to get started.
- cblum 6y ago
  That is, until you get to the point where you want to automate your build and oh now you need to learn the clusterf*ck that's msbuild.
The_rationalist 6y ago
Some platforms allow you to learn a new language wile staying on the same ecosystem: E.g Java -> Kotlin js -> ts Erlang -> Elixir
ozim 6y ago
To be realistic about it I stopped calling things I don't understand "bullshit" and "terrible". What I use instead is "I don't know why it is that way", "I don't understand" and finally realization "OK, I don't want to spend my time on understanding this because I have better things to do". I would love to spread this approach in developer community. Be honest that you don't understand stuff and you don't have time to learn it because you have better things to do. Though if someone is paying me to do something in a language I will put my time into learning it. If it is just a hobby who cares that it is not easily grasped, I don't have to spend time on it.
- Retric 6y ago
  The ecosystem around a language is not different because each language needs a wildly different ecosystem. It’s mostly an accident of history where different tools and techniques are adopted by different communities over time.
- hannofcart 6y ago
  This, a hundred times over. The more experienced I get, the primary transformation I see in myself is being less dismissive of existing work that I wasn't involved in. Were they insanely time crunched? Was this a prototype by a lawyer who painstakingly taught himself Excel and then taught himself Python again to port the Excel sheet he had into a service? Were the abstractions they chose based on whatever was the best practice at the time? I've stopped scoffing at a simple app that I think I can "hack together in a weekend". No I can't. There are complexities and corners I don't see at the moment.
  - commandlinefan 6y ago
    > I've stopped scoffing at a simple app that I think I can "hack together in a weekend" How do you get your PM to stop planning that way, though?
    - hedora 6y ago
      Find a better PM. The competent ones I’ve worked with invariably convince engineers their “weekend project” will take at least 2 months. They start by getting the engineer to spend an afternoon enumerating all the tasks they need to complete to implement and ship it. Then the engineer takes 3 months, when they would have taken 6 without help from the PM. This is because the PM follows up, and helps them be ruthless with the requirements list.
tannhaeuser 6y ago
For me, part of the problem is the fixation towards a "language ecosystem" per se that people seemingly have come to expect. What has happened to the idea that you could link object files/libs compiled from any number of different programming languages, all adhering to the OS's platform ABI? Where you the developer, and you alone, decides which language to use for coding a particular aspect of your app based on the respective language's fit to the problem in a polyglot fashion? For example, if your app needs a parser for a config language, say, you're free to use Prolog with its built-in parsing DSLs. Similarly, if your app involves DBs or GUIs, etc. PLs today are huge, unportable monoliths with shiny web sites when the point of a standardized PL, for me at least, has always very much been that it fences you against overreaching vendors, language world domination aspirations, and churn disguised as march of progress.
- jolux 6y ago
  Because once you get beyond the simplest runtimes maintaining compatibility between things becomes difficult fast and more complex runtimes have enabled a lot of things people want, like actual portability between systems, JIT compilation, garbage collection, etc. Most language runtimes have native interop these days but it’s always a worse experience all around than using language-native libraries.
commandlinefan 6y ago
> ecosystem A lot of this stems from the fact that most languages start out thinking they won’t need an ecosystem and what emerges evolves rather than is designed.

by lerax 6y ago

lmm 6y ago

Don't bother using SBT. Just build Scala with Maven. It's wonderful, everything works how you'd expect, all the documentation from the Java world is still valid.

auggierose 6y ago
Maven is another sort of hell :-) Also, do you have good integration for building Scala.js as well?
- lmm 6y ago
  I've never got the hate for Maven - all the design decisions people dislike seem to be the same things that people praise Cargo et al for. If anything it suffers for being ahead of its time. Use the Scalor plugin, https://github.com/random-maven/scalor-maven-plugin https://github.com/random-maven/scalor-maven-plugin, and then Scala.js just works. I actually hooked it up to Netlify by treating Maven as a static site generator: http://m50d.github.io/2018/11/29/deploying-scalajs-with-netlify http://m50d.github.io/2018/11/29/deploying-scalajs-with-netl...
commandlinefan 6y ago
> SBT Me: “How do I xxx in SBT?” Them: “Read the docs, n00b” Me: “what docs?” Them: ...

arendtio 6y ago

I think this is a point where Go is very good at and JavaScript sucks pretty hard. Mostly because Go brings many things by default and JavaScript has such a high rate at which new tools become mainstream/obsolete and so many options to choose from and combine with.

mellosouls 6y ago
Give Go another 15 years to catch up with JavaScript's current maturity and see where we are then with its ecosystem.
- tempodox 6y ago
  If it still exists by then...
- AmpsterMan 6y ago
  Go at the ten year mark and JS at the ten year mark can be compared, no? In general I find Go's tighter language philosophy and more expansive ecosystem out the gate to help alleviate many of these problems. You can't ever fix them completely, but I don't think that will ever happen without a giant corporation backing it.
- moreaccountspls 6y ago
  I mean, Node and Go were released within 6 months of each other. When jquery was the dominant tool in the ecosystem, there wasn't nearly the level of breakage that there is now.
loudlambda 6y ago
I found the opposite to be true. With javascript I never saw the package.json not work for the other developers on the team; with go, half of my team can't successfully update vendoring for no apparent reason. Commands frequently error with messages that are completely worthless. Go seems to have made up it's own path syntax with things like "...", and commands like "go test foo/bar" will fail with an error message that gives no clue as to the problem, but work fine with "go test ./foo/bar". Why? What's the command to see if any of my dependencies have a CVE against them? Oh, there isn't one. What's the command to prompt me to pull in a new version of my dependencies? Oh, there isn't one. This is a language that has made some promise about backwards comparability, but every release seems to break how things are built, and you have to fiddle with bizarre environment variables like GO111MODULE to find the incantation to make things happy again.

TeMPOraL 6y ago

... C++ with CMake, oh wait Ninja, oh wait nevermind, and also you have to catch up on a bunch of random bloggers and various conference recordings to have a clue as to what are the community recommendations for the libraries, or coding standards. I 100% share your feelings.

aldanor 6y ago
When people compare C++ with Rust, quite often the only thing measured is performance where depending in your cxx compiler Rust (or rather, llvm) may lose sometimes. What is often forgotten is the ecosystem. To build a cxx project you'll probably need to learn CMake and ninja; maybe Buck or Bazel too. If your project has eternal dependencies you may have to figure out yourself how tl link everything together using whatever build tools the authors were using. For docs, you'll have to learn and use doxygen; for style formatting, something like a clang-format and its presets and options; for linting, something like clang-tidy or cpplint, etc. For testing, probably catch2 or one of similar frameworks. There's no universal concept of "package" or "version", you're completely on your own here; most open source cxx repos that have dependencies just add them as git submodules. In Rust, cargo build to build, cargo doc to generate docs, cargo test to run tests, cargo publish to push your crate to the index; cargo fmt to format the code and cargo clippy to lint it - that's it, we're done.
- pydry 6y ago
  A large part of that is simply due to age, though. If rust were older it would have more baggage too, but also a larger ecosystem.
- shpongled 6y ago
  In my experience, Rust certainly has one of the easiest language ecosystems to use. I've been using Rust for ~3 years now, and have been trying to learn C++, but I've been so spoiled by the entire Rust ecosystem's user friendliness that it's a very daunting task.
lerax 6y ago
Or Makefile, or Meson, or autotools... And beyond to infinite. Man, that type of stuff don't motivates anyone to learn a new language. If all what we should do it is code a solution and deploy with one command, oh God, will be a dream. But no, beyond all this clusterfuck, by doing cloud stuff will be need probably Docker too, Kubernetes. Maybe ansible too? Oh, no, your team use terraforms. D:

tasogare 6y ago

Visual Studio for C# development got this right: powerful language with super good IDE support and a rock solid standard library. Good documentation online too. It hides complexity that can bite later, and it can be complex to chose a framework to target, but otherwise it’s super easy to get started.

cblum 6y ago
That is, until you get to the point where you want to automate your build and oh now you need to learn the clusterf*ck that's msbuild.

The_rationalist 6y ago

Some platforms allow you to learn a new language wile staying on the same ecosystem: E.g Java -> Kotlin js -> ts Erlang -> Elixir

ozim 6y ago

To be realistic about it I stopped calling things I don't understand "bullshit" and "terrible". What I use instead is "I don't know why it is that way", "I don't understand" and finally realization "OK, I don't want to spend my time on understanding this because I have better things to do". I would love to spread this approach in developer community. Be honest that you don't understand stuff and you don't have time to learn it because you have better things to do. Though if someone is paying me to do something in a language I will put my time into learning it. If it is just a hobby who cares that it is not easily grasped, I don't have to spend time on it.

Retric 6y ago
The ecosystem around a language is not different because each language needs a wildly different ecosystem. It’s mostly an accident of history where different tools and techniques are adopted by different communities over time.
hannofcart 6y ago
This, a hundred times over. The more experienced I get, the primary transformation I see in myself is being less dismissive of existing work that I wasn't involved in. Were they insanely time crunched? Was this a prototype by a lawyer who painstakingly taught himself Excel and then taught himself Python again to port the Excel sheet he had into a service? Were the abstractions they chose based on whatever was the best practice at the time? I've stopped scoffing at a simple app that I think I can "hack together in a weekend". No I can't. There are complexities and corners I don't see at the moment.
- commandlinefan 6y ago
  > I've stopped scoffing at a simple app that I think I can "hack together in a weekend" How do you get your PM to stop planning that way, though?
  - hedora 6y ago
    Find a better PM. The competent ones I’ve worked with invariably convince engineers their “weekend project” will take at least 2 months. They start by getting the engineer to spend an afternoon enumerating all the tasks they need to complete to implement and ship it. Then the engineer takes 3 months, when they would have taken 6 without help from the PM. This is because the PM follows up, and helps them be ruthless with the requirements list.

tannhaeuser 6y ago

For me, part of the problem is the fixation towards a "language ecosystem" per se that people seemingly have come to expect. What has happened to the idea that you could link object files/libs compiled from any number of different programming languages, all adhering to the OS's platform ABI? Where you the developer, and you alone, decides which language to use for coding a particular aspect of your app based on the respective language's fit to the problem in a polyglot fashion? For example, if your app needs a parser for a config language, say, you're free to use Prolog with its built-in parsing DSLs. Similarly, if your app involves DBs or GUIs, etc. PLs today are huge, unportable monoliths with shiny web sites when the point of a standardized PL, for me at least, has always very much been that it fences you against overreaching vendors, language world domination aspirations, and churn disguised as march of progress.

jolux 6y ago
Because once you get beyond the simplest runtimes maintaining compatibility between things becomes difficult fast and more complex runtimes have enabled a lot of things people want, like actual portability between systems, JIT compilation, garbage collection, etc. Most language runtimes have native interop these days but it’s always a worse experience all around than using language-native libraries.

commandlinefan 6y ago

> ecosystem A lot of this stems from the fact that most languages start out thinking they won’t need an ecosystem and what emerges evolves rather than is designed.