8 ms·

Imagine how much worse other popular programming languages' tooling is, given Golang is constantly praised as having great tooling. When integrating into a new

by ovi256 7y ago

Imagine how much worse other popular programming languages' tooling is, given Golang is constantly praised as having great tooling. When integrating into a new dev team, half the work is grokking their local tooling choices. In an ecosystem with strong "one best way to do it" tooling, that effort is almost non-existent.

tsimionescu 7y ago
But then, that is the question : which language is that? C# and Java are not it. C and C++ have excellent dev tools and debuggers, though it's true package management is essentially non - existent. Python, JavaScript and TypeScrpit have better tools than Go, even with the limitations of a dynamic language (the package ecosystem of npm is horrible, but npm itself is a pretty decent tool, definitely much simpler than go mod).
- richardwhiuk 7y ago
  Rusts tooling is pretty stellar.
  - NanoCoaster 7y ago
    Depends. Package Management, compiler errors? Absolutely. IDE support? Not so much. I don't think it's fair to compare it to C# / JVM languages, but even compared to other languages, I wouldn't say the tooling is all that great. Macros make IDE support a lot harder than in other languages, the atrocious compile times sure do as well. While IntelliJ Rust and rust-analyzer both try to do their best (kudos to the teams working on them!), it's still nowhere near anything I'd call "stellar". There are mitigations being worked on right now, like compiling macros to WASM[0] and Cranelift[0], but these endeavours, while very promising, I wouldn't call production-ready yet. [0] https://github.com/dtolnay/watt https://github.com/dtolnay/watt [1] https://github.com/bytecodealliance/cranelift https://github.com/bytecodealliance/cranelift EDIT: Also, debugging. I'm not sure of the current state of it, but last time I checked, it was pretty much just GDB integration that was working. CLion (which I think uses GDB?) is able to give you a nice UI for basic debugging, don't know about VSCode integration. Still, even if it works, it's not at all comparable to debugging in C#/JVM, you're limited to very basic stuff compared to these languages / the well-known IDEs for them. So, again, it may be "fine" or even "good", but imho it's not exactly stellar :)
    - Groxx 7y ago
      Re compile times: in nearly all cases I've seen, un-optimized builds (opt-level=0 or 1) are still quite fast. Do you know of any counter-examples? I'd love to see what the cause is. Optimized builds though, yeah, you routinely hear about multi-hour builds. As long as there's a dev-friendly fast mode though, slow optimized builds don't bother me all that much.
      - NanoCoaster 7y ago
        In my experience, the problem is that debug builds (which, I assume, are not optimized) are still annoying. I recently built a new PC and got a Ryzen 3900x, so I'll probably have to check again with that :) Now, "atrocious" may have been bad wording without context: I think it's just taking very long to finish the normal edit-start-debug cycle, compared to other languages (Go, Java, C# for example). I don't have any numbers right now, but I'll try to update my post once I get home, I've done a few basic emulator projects in Rust :) At least, it was long enough to be annoying to me. Maybe I'm just too used to C#, which I use at work.
        LandR 7y ago
        I've seen some pretty long compile times in C#, at my previous job building a local copy of the whole solution was around 40mins to an hour (400+ csproj).
        tsimionescu 7y ago
        I guarantee that a 400+ module Go program or 400+ Rust crates will build much slower (if no other reason, simply because Go or Rust compilers do a lot of work that is deferred to runtime in C#).
      - nicoburns 7y ago
        What counts as "quite fast" for you? If you're talking about multi-hour builds, then you might not be talking on the same scale as others. I would consider 10 seconds to be pretty slow for a small/medium sized project.
  - dragonsh 7y ago
    Rust copied tooling from Go and Python. Also its tooling cannot work without internet and need to download MB's of data for simple development, and on the other hand proclaims itself to be systems programming language to replace C and C++ which doesn't require active internet to work. Also C++17 is much better version taking away the deficiencies of earlier versions and if not better at least provide similar run-time guarantee and safety as Rust (which also needs to rely on unsafe code to do anything meaningful with systems programming). So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. Just with C++ you will not have to climb the mountain of learning just to do simple things. I think Rust gets a lot of hype because it's syntax is complex and learning curve is much higher than C or C++ and programmers see new shiny language which got some traction as Panacea for all the programming problems.
    - heavenlyblue 7y ago
      Did you forget how much apt-get build-essentials is going to take in terms of space?
      - shiftless 7y ago
        Did you miss the "cannot work without internet" part? That is only one of several dealbreakers for me, for all of these Web 2.0 shitware tools. Only a fool connects his dev machine to the internet, knowing what we do now about the state of computer insecurity. The other dealbreaker in this case being that Rust is developed by Mozilla, an evil organization that is joined to the hip with another evil organization (Google.)
    - ben-schaaf 7y ago
      > So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. As a C++ Dev who's done some rust on the side this is utter horseshit. Regardless of which C++ version you use it is utterly trivial to write code with undefined behaviour. Even if you're extremely diligent you will eventually be hunting down a bug caused by undefined behaviour.
      - 7y ago
- MrBuddyCasino 7y ago
  > C# and Java are not it. This needs elaboration. Those languages pretty much are the canonical example of "not a great language, but stellar and unmatched tooling".
  - tsimionescu 7y ago
    Unfortunately I was pretty confusing. The G-GP had said 'imagine how much worse other languages are', and I was pointing out that I don't know which those other languages with worse tooling are. That phrase was meant to say 'Java and C# are obviously not languages with worse tooling'. That is, I agree with you, and considered it obvious that Java and C# have stellar tooling.
  - merb 7y ago
    > not a great language it really depends on how you define a great language. btw. C# can do everything that golang can, but has a different inheritance interface. Also C# has some stuff that golang does not can, like an easier way of working together with C++. Btw. Java is nearly in the same boat. It has a different inheritance interface and can nearly do all things that golang can (except maybe csp/channels and can not be as memory efficient than C# and golang). But the point still stands. Golang basically can do less than both.
imtringued 7y ago
I remember using a 4 year old programming language on the JVM. When you installed the Eclipse Plugin you could do all the code navigation, refactoring, etc. This was a custom written plugin specifically made for this programming language so it didn't really take advantage of copying the Java plugin and extending it. It also had a fully fledged package manager, build system, code formatter and all the fancy bells and whistles. The tooling was amazing and it shows that whether tooling for a given programming language is good or not merely depends on how much the community values good tooling. Especially in python the community gives a crap about good tooling. There is a lot of tooling with which you can cobble something together but it never leaves you feeling that it was worth the time investment or that the solution was particularly elegant. Deploying applications is a problem on which most people just give up and just ship a virtualenv to production... or they waste a week on finding a better solution. One might argue that this one week will save me time in the long run but then you start thinking about all the python programmers who don't give a crap and they clearly don't want to invest that week worth of time and so the cycle of bad tooling continues.
- 1337shadow 7y ago
  Actually I do 100% automated deployments with Ansible roles. I don't use the ansible commands though, I wrapped it in my own command which fixes all my problems with ansible: https://yourlabs.io/oss/bigsudo https://yourlabs.io/oss/bigsudo My roles: https://galaxy.ansible.com/yourlabs/ https://galaxy.ansible.com/yourlabs/ I'm extremely happy with it. Currently I'm writting my own Docker/Compose on top of podman and buildah in order to remove all `Dockerfile.` and `docker-compose..yml` from my projects in favor of a single pod configuration file, which can variate depending on a "profile" (default, dev, prod, review...). Once that is solved I will continue my life with 100% satisfaction of the tools I use for my CI and deployments. But yeah, prior to going crazy like that and rewriting the world, during years, I was actually doing my best to not invent new tools, and get the best out of every tool that was out there, I can easily imagine that's how most people would practice their craft, by just focusing on what they are supposed to ship, considering that "if I could make a better tool for that then somebody else would already have, so I'll just use anything and not really bother, perhaps try to contribute or wrap in bash scripts".

by ovi256 7y ago

tsimionescu 7y ago

But then, that is the question : which language is that? C# and Java are not it. C and C++ have excellent dev tools and debuggers, though it's true package management is essentially non - existent. Python, JavaScript and TypeScrpit have better tools than Go, even with the limitations of a dynamic language (the package ecosystem of npm is horrible, but npm itself is a pretty decent tool, definitely much simpler than go mod).

richardwhiuk 7y ago
Rusts tooling is pretty stellar.
- NanoCoaster 7y ago
  Depends. Package Management, compiler errors? Absolutely. IDE support? Not so much. I don't think it's fair to compare it to C# / JVM languages, but even compared to other languages, I wouldn't say the tooling is all that great. Macros make IDE support a lot harder than in other languages, the atrocious compile times sure do as well. While IntelliJ Rust and rust-analyzer both try to do their best (kudos to the teams working on them!), it's still nowhere near anything I'd call "stellar". There are mitigations being worked on right now, like compiling macros to WASM[0] and Cranelift[0], but these endeavours, while very promising, I wouldn't call production-ready yet. [0] https://github.com/dtolnay/watt https://github.com/dtolnay/watt [1] https://github.com/bytecodealliance/cranelift https://github.com/bytecodealliance/cranelift EDIT: Also, debugging. I'm not sure of the current state of it, but last time I checked, it was pretty much just GDB integration that was working. CLion (which I think uses GDB?) is able to give you a nice UI for basic debugging, don't know about VSCode integration. Still, even if it works, it's not at all comparable to debugging in C#/JVM, you're limited to very basic stuff compared to these languages / the well-known IDEs for them. So, again, it may be "fine" or even "good", but imho it's not exactly stellar :)
  - Groxx 7y ago
    Re compile times: in nearly all cases I've seen, un-optimized builds (opt-level=0 or 1) are still quite fast. Do you know of any counter-examples? I'd love to see what the cause is. Optimized builds though, yeah, you routinely hear about multi-hour builds. As long as there's a dev-friendly fast mode though, slow optimized builds don't bother me all that much.
    - NanoCoaster 7y ago
      In my experience, the problem is that debug builds (which, I assume, are not optimized) are still annoying. I recently built a new PC and got a Ryzen 3900x, so I'll probably have to check again with that :) Now, "atrocious" may have been bad wording without context: I think it's just taking very long to finish the normal edit-start-debug cycle, compared to other languages (Go, Java, C# for example). I don't have any numbers right now, but I'll try to update my post once I get home, I've done a few basic emulator projects in Rust :) At least, it was long enough to be annoying to me. Maybe I'm just too used to C#, which I use at work.
      - LandR 7y ago
        I've seen some pretty long compile times in C#, at my previous job building a local copy of the whole solution was around 40mins to an hour (400+ csproj).
        tsimionescu 7y ago
        I guarantee that a 400+ module Go program or 400+ Rust crates will build much slower (if no other reason, simply because Go or Rust compilers do a lot of work that is deferred to runtime in C#).
    - nicoburns 7y ago
      What counts as "quite fast" for you? If you're talking about multi-hour builds, then you might not be talking on the same scale as others. I would consider 10 seconds to be pretty slow for a small/medium sized project.
- dragonsh 7y ago
  Rust copied tooling from Go and Python. Also its tooling cannot work without internet and need to download MB's of data for simple development, and on the other hand proclaims itself to be systems programming language to replace C and C++ which doesn't require active internet to work. Also C++17 is much better version taking away the deficiencies of earlier versions and if not better at least provide similar run-time guarantee and safety as Rust (which also needs to rely on unsafe code to do anything meaningful with systems programming). So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. Just with C++ you will not have to climb the mountain of learning just to do simple things. I think Rust gets a lot of hype because it's syntax is complex and learning curve is much higher than C or C++ and programmers see new shiny language which got some traction as Panacea for all the programming problems.
  - heavenlyblue 7y ago
    Did you forget how much apt-get build-essentials is going to take in terms of space?
    - shiftless 7y ago
      Did you miss the "cannot work without internet" part? That is only one of several dealbreakers for me, for all of these Web 2.0 shitware tools. Only a fool connects his dev machine to the internet, knowing what we do now about the state of computer insecurity. The other dealbreaker in this case being that Rust is developed by Mozilla, an evil organization that is joined to the hip with another evil organization (Google.)
  - ben-schaaf 7y ago
    > So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. As a C++ Dev who's done some rust on the side this is utter horseshit. Regardless of which C++ version you use it is utterly trivial to write code with undefined behaviour. Even if you're extremely diligent you will eventually be hunting down a bug caused by undefined behaviour.
    - 7y ago
MrBuddyCasino 7y ago
> C# and Java are not it. This needs elaboration. Those languages pretty much are the canonical example of "not a great language, but stellar and unmatched tooling".
- tsimionescu 7y ago
  Unfortunately I was pretty confusing. The G-GP had said 'imagine how much worse other languages are', and I was pointing out that I don't know which those other languages with worse tooling are. That phrase was meant to say 'Java and C# are obviously not languages with worse tooling'. That is, I agree with you, and considered it obvious that Java and C# have stellar tooling.
- merb 7y ago
  > not a great language it really depends on how you define a great language. btw. C# can do everything that golang can, but has a different inheritance interface. Also C# has some stuff that golang does not can, like an easier way of working together with C++. Btw. Java is nearly in the same boat. It has a different inheritance interface and can nearly do all things that golang can (except maybe csp/channels and can not be as memory efficient than C# and golang). But the point still stands. Golang basically can do less than both.

imtringued 7y ago

I remember using a 4 year old programming language on the JVM. When you installed the Eclipse Plugin you could do all the code navigation, refactoring, etc. This was a custom written plugin specifically made for this programming language so it didn't really take advantage of copying the Java plugin and extending it. It also had a fully fledged package manager, build system, code formatter and all the fancy bells and whistles. The tooling was amazing and it shows that whether tooling for a given programming language is good or not merely depends on how much the community values good tooling. Especially in python the community gives a crap about good tooling. There is a lot of tooling with which you can cobble something together but it never leaves you feeling that it was worth the time investment or that the solution was particularly elegant. Deploying applications is a problem on which most people just give up and just ship a virtualenv to production... or they waste a week on finding a better solution. One might argue that this one week will save me time in the long run but then you start thinking about all the python programmers who don't give a crap and they clearly don't want to invest that week worth of time and so the cycle of bad tooling continues.

1337shadow 7y ago
Actually I do 100% automated deployments with Ansible roles. I don't use the ansible commands though, I wrapped it in my own command which fixes all my problems with ansible: https://yourlabs.io/oss/bigsudo https://yourlabs.io/oss/bigsudo My roles: https://galaxy.ansible.com/yourlabs/ https://galaxy.ansible.com/yourlabs/ I'm extremely happy with it. Currently I'm writting my own Docker/Compose on top of podman and buildah in order to remove all `Dockerfile.` and `docker-compose..yml` from my projects in favor of a single pod configuration file, which can variate depending on a "profile" (default, dev, prod, review...). Once that is solved I will continue my life with 100% satisfaction of the tools I use for my CI and deployments. But yeah, prior to going crazy like that and rewriting the world, during years, I was actually doing my best to not invent new tools, and get the best out of every tool that was out there, I can easily imagine that's how most people would practice their craft, by just focusing on what they are supposed to ship, considering that "if I could make a better tool for that then somebody else would already have, so I'll just use anything and not really bother, perhaps try to contribute or wrap in bash scripts".