4 ms·

Wow. That's not a small thing to internalize. I guess if you use predominantly Go, then that's good and understanabdle, but if you have more languages in the mi

by malkia 5y ago

Wow. That's not a small thing to internalize. I guess if you use predominantly Go, then that's good and understanabdle, but if you have more languages in the mix (C/C++, Python, C#, Java, Rust), each of them have their own build ways and quirks (at least with Go/Rust/C# there is build single option (AFAIK)), but then do - do I need to clean now? Is this going to really get my latest change? Is the IDE going to see these new symbols, the debugger, etc. I know people like when their language comes with build system, but that creates a cost when that language/runtime has to be used with others...

nerdponx 5y ago
I don't see how workspaces makes that situation worse. Go has always had its own compiler, package layout, etc.
- malkia 5y ago
  I think the whole thing is super easy to use, if only for Go. I've had to recompile and patch few things, and I'm relatively unfamiliar with it, and with my little knowledge was able to get through (my main languages are C/C++ and C#, and did Java (+ blaze) while at google, but never touched anything else but Java there, though saw the light of how easy is to integrate between these languages, given enough time spent on making these rules work (it's not always easy, I'm still waiting for external dart/flutter rules, it's yet another system with it's own build mechanism))
qbasic_forever 5y ago
If you have a lot of different languages in the same repo (like a monorepo scenario), you might be better served using something like bazel. It'll abstract away all the language-specific build systems, for better or worse, and make it a bit more uniform to manage. It's not a panacea--basically everything now has a single annoying build system instead of everything having an annoyingly different native build system.
- malkia 5y ago
  Well I was hinting at it, or the other similar systems (gn, buck, pants, etc.) - you end up needing a language-agnostic (or rather say, language-diverse system) that understand how these compilers / runtimes express output artifacts and actions. It's not always that easy (e.g. "virtual_includes" in bazel and `#pragma once` do not work well, but it's small price to pay (e.g. go back to #ifndef MY_HEADER_H #define it)).

by malkia 5y ago

nerdponx 5y ago

I don't see how workspaces makes that situation worse. Go has always had its own compiler, package layout, etc.

malkia 5y ago
I think the whole thing is super easy to use, if only for Go. I've had to recompile and patch few things, and I'm relatively unfamiliar with it, and with my little knowledge was able to get through (my main languages are C/C++ and C#, and did Java (+ blaze) while at google, but never touched anything else but Java there, though saw the light of how easy is to integrate between these languages, given enough time spent on making these rules work (it's not always easy, I'm still waiting for external dart/flutter rules, it's yet another system with it's own build mechanism))

qbasic_forever 5y ago

If you have a lot of different languages in the same repo (like a monorepo scenario), you might be better served using something like bazel. It'll abstract away all the language-specific build systems, for better or worse, and make it a bit more uniform to manage. It's not a panacea--basically everything now has a single annoying build system instead of everything having an annoyingly different native build system.

malkia 5y ago
Well I was hinting at it, or the other similar systems (gn, buck, pants, etc.) - you end up needing a language-agnostic (or rather say, language-diverse system) that understand how these compilers / runtimes express output artifacts and actions. It's not always that easy (e.g. "virtual_includes" in bazel and `#pragma once` do not work well, but it's small price to pay (e.g. go back to #ifndef MY_HEADER_H #define it)).