6 ms·

I don't know. I've worked in three different languages for years on end, and they all have different pain points. C++ is too complicated, and generics are part

I don't know. I've worked in three different languages for years on end, and they all have different pain points. C++ is too complicated, and generics are part of that complexity. Java has an ok basic language, but the ecosystem is weird and fad-prone, jumping from beans to patterns to annotations to injection, searching for the One True Way. Go is a little too simple, which sometimes leads to rewriting fairly straightforward stuff that a few clever general mechanisms would let us write once. This experience makes me suspect that there will always be some pain point with the language. We'll never be happy; that's impossible. The only thing we can do is choose what type of unhappiness we are willing to live with. The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. And I suspect that whatever complexities we add would compromise this clarity in the name of brevity. I'd spend less time being bored, and more time being puzzled or incredulous. And fundamentally, I'd rather be bored.

paulddraper 8y ago
> the ecosystem is weird and fad-prone Won't dispute that but did that materially affect your chosen paradigms and patterns?
- johan_larson 8y ago
  When I had the opportunity to choose, I felt I could find useful ways of doing things. The problem was that I often had to accommodate myself to someone else's choices that had been made years before, and I had to understand what the heck they had done before I could make useful upgrades. And with many ways of doing things, some of which are hugely reliant on really non-obvious behavior controlled by cryptic settings in control files or annotations, that can be hard.
snarfy 8y ago
Have you tried C#?
- johan_larson 8y ago
  No. Based on what I've read, it seems to be Slightly Different Java. Is there some important difference?
  - damian2000 8y ago
    There's a number of differences, including generics done well. The team behind C# seem really engaged and transparent. The latest C#8 brings non nullable reference types, similar to how Kotlin does it.
  - snarfy 8y ago
    I wouldn't call its ecosystem weird and fad prone.
- NateDad 8y ago
  C# has the feature-bloat of C++, except with a garbage collector. (I wrote C# for 9 years and even when writing it 40 hours a week, I still had trouble keeping up with all the features that continually came out)
  - int_19h 8y ago
    It has nowhere near the feature bloat of C++. A C++ language lawyer can eat C# ones for breakfast. If you compared modern C# to C++03, then maybe (although even then I would argue that templates alone are more complicated still).
  - tonyedgecombe 8y ago
    C# has become quite a big language although it manages to hide the complexity quite well compared to C++. There is very little in the language that will trip you up, unlike C++. The only problem I have with it is it is still really Windows only, hopefully that will improve with .Net Core 3.
    - tluyben2 8y ago
      I have been writing stable and robust C# software on Linux and Mac OS X for many years now, so not sure what you mean. Starting with Mono and now solely .NET Core 2 & 3. I know many people who do that as well. And our deployments (all our prod/test/staging servers) went from Windows-only 15 years ago to Linux-only since 4 years. Maybe you are talking WPF / Desktop only; there are other options for Mono but yes, there you would be right. However the trend is, unfortunately, toward browser interfaces (Electron etc) and those you can do on Linux/Mac already with .NET Core.
tracker1 8y ago
I'm a fan of doing the first pass for most things in a scripted language. I mean, it may not be the least bytes or fastest code, but the time to done seems to be a lot better, and usually performs well enough a second pass isn't needed. I really appreciate what I've seen of both Rust and Go myself. They both feel more approachable than the C/C++ legacies imho. Though I haven't gone much farther than general tutorials with either.
piano 8y ago
> The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. When reading Go codebase I'm not familiar with, I'm very often having a hard time figuring which interfaces go with which structs. As in "Oh, this function accepts interface Foo, which is implemented by which structures?" and then I have go on a adventure throughout the codebase to figure out what structures go in there. Really annoying. In a language whose intention is to be explicit and easy to read (as opposed to write) I can't understand for the life of me why the authors chose to make interface implementations implicit. It seems like a decision that pretty much only has downsides and which is contrary to the overall aim. I just don't get it.
- johan_larson 8y ago
  The one reason that comes to mind is that doing it implicitly lets you use structures in terms of interfaces even when those structures come from codebases you don't control . Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. But if implicit implementation is enough, then you can just use implA directly as an A with no changes by Bob. But yes, this is a sore point. It would be convenient to be able to declare structures as implementations of particular interfaces, even if the current implicit behavior were preserved.
  - piano 8y ago
    > Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. Not necessarily, in some lanugages you can add an interface to type even if the type is foreign and you only control the interface. I believe this can be done in Swift, Rust, F# and quite likely some others...

paulddraper 8y ago

> the ecosystem is weird and fad-prone Won't dispute that but did that materially affect your chosen paradigms and patterns?

johan_larson 8y ago
When I had the opportunity to choose, I felt I could find useful ways of doing things. The problem was that I often had to accommodate myself to someone else's choices that had been made years before, and I had to understand what the heck they had done before I could make useful upgrades. And with many ways of doing things, some of which are hugely reliant on really non-obvious behavior controlled by cryptic settings in control files or annotations, that can be hard.

snarfy 8y ago

Have you tried C#?

johan_larson 8y ago
No. Based on what I've read, it seems to be Slightly Different Java. Is there some important difference?
- damian2000 8y ago
  There's a number of differences, including generics done well. The team behind C# seem really engaged and transparent. The latest C#8 brings non nullable reference types, similar to how Kotlin does it.
- snarfy 8y ago
  I wouldn't call its ecosystem weird and fad prone.
NateDad 8y ago
C# has the feature-bloat of C++, except with a garbage collector. (I wrote C# for 9 years and even when writing it 40 hours a week, I still had trouble keeping up with all the features that continually came out)
- int_19h 8y ago
  It has nowhere near the feature bloat of C++. A C++ language lawyer can eat C# ones for breakfast. If you compared modern C# to C++03, then maybe (although even then I would argue that templates alone are more complicated still).
- tonyedgecombe 8y ago
  C# has become quite a big language although it manages to hide the complexity quite well compared to C++. There is very little in the language that will trip you up, unlike C++. The only problem I have with it is it is still really Windows only, hopefully that will improve with .Net Core 3.
  - tluyben2 8y ago
    I have been writing stable and robust C# software on Linux and Mac OS X for many years now, so not sure what you mean. Starting with Mono and now solely .NET Core 2 & 3. I know many people who do that as well. And our deployments (all our prod/test/staging servers) went from Windows-only 15 years ago to Linux-only since 4 years. Maybe you are talking WPF / Desktop only; there are other options for Mono but yes, there you would be right. However the trend is, unfortunately, toward browser interfaces (Electron etc) and those you can do on Linux/Mac already with .NET Core.

tracker1 8y ago

I'm a fan of doing the first pass for most things in a scripted language. I mean, it may not be the least bytes or fastest code, but the time to done seems to be a lot better, and usually performs well enough a second pass isn't needed. I really appreciate what I've seen of both Rust and Go myself. They both feel more approachable than the C/C++ legacies imho. Though I haven't gone much farther than general tutorials with either.

piano 8y ago

> The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. When reading Go codebase I'm not familiar with, I'm very often having a hard time figuring which interfaces go with which structs. As in "Oh, this function accepts interface Foo, which is implemented by which structures?" and then I have go on a adventure throughout the codebase to figure out what structures go in there. Really annoying. In a language whose intention is to be explicit and easy to read (as opposed to write) I can't understand for the life of me why the authors chose to make interface implementations implicit. It seems like a decision that pretty much only has downsides and which is contrary to the overall aim. I just don't get it.

johan_larson 8y ago
The one reason that comes to mind is that doing it implicitly lets you use structures in terms of interfaces even when those structures come from codebases you don't control . Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. But if implicit implementation is enough, then you can just use implA directly as an A with no changes by Bob. But yes, this is a sore point. It would be convenient to be able to declare structures as implementations of particular interfaces, even if the current implicit behavior were preserved.
- piano 8y ago
  > Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. Not necessarily, in some lanugages you can add an interface to type even if the type is foreign and you only control the interface. I believe this can be done in Swift, Rust, F# and quite likely some others...