8 ms·

> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for pe

> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowledge here and there when writing C extensions for my Python applications. I'm a fairly experienced programmer at this point. To the point: I tried picking up Go one day because I was hearing so much about how it could replace Python as network glue code with better performance and reliable concurrency. I can't really validate or invalidate those claims. That said, I found Go to be sort of difficult. The syntax is really simple. Compiling is really simple. Concurrency is even simple. However, need to do something in a different way than Go decides is correct? Well, you can't. It won't even compile. The difficulty in Go is in learning about what the compiler thinks is OK. I don't really like that. You don't really know if your code will work until you compile. Basically, I just think Go isn't really flexible enough for modern programming. I find that Nim can do Go's job better than Go can for my use cases anyways.

literallycancer 9y ago
>You don't really know if your code will work until you compile. You are supposed to "compile on save".
- scriptkiddy 9y ago
  I usually do this, but sometimes I'm writing a really long function or something and I want to save part way through so I don't lose my progress from some unlikely, yet catastrophic, failure.
zellyn 9y ago
> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.
- scriptkiddy 9y ago
  I disagree. For instance, if I'm writing something in C and I know that it is syntactically and semantically correct, I know that it will definitely compile. Go hijacks control flow and makes it more difficult to reason about how your code will be compiled and executed. At least that is true in my personal experience.
  - _ph_ 9y ago
    Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?
    - scriptkiddy 9y ago
      So, keep in mind that my experience with Go is not at a professional level. Take this example: https://gobyexample.com/channel-buffering https://gobyexample.com/channel-buffering As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the channel or am I just using the channel as a simple buffer? This example helps as well: https://gobyexample.com/channel-directions https://gobyexample.com/channel-directions Am I implicitly creating goroutines by using channels or am I simply creating a buffer? Sorry I don't have any of my own code to share as I deleted all of my Go practice stuff.
      - zellyn 9y ago
        It really just seems like you're saying "When I think my Go code is correct, it turns out it often isn't, but when I think my ${other_programming_language_i_know_better} code is correct, it turns out it usually is.
      - _ph_ 9y ago
        Channels are a safe way for goroutines to communicate. Safe here means, that the channel itself performs all the necessary locking needed for any number of goroutines to read or write "at the same time" to and from the channel. Other than that it does behave like a plain pipe. You write into it and can read from it "on the other side". Creating a channel does not create a goroutine. A goroutine is only created if you use the "go" command, like "go f(42)". This would run the evaluation of f(42) in a separate goroutine, which behaves like a thread, but uses less resources. So in neither of your examples, goroutines are created. You can optionally add buffering to the channel. A write to a channel without a buffer blocks, until the value you write to the channel is read. If you have buffers, you can fill them without blocking, even if the values are not consumed immediately. Without the buffer, the first example would get stuck, as the first write to "messages" would block until there is a read on that channel - which is never performed. But due to the buffering, the two writes to "messages" are performed without blocking, and the values can be read after that. A third read on the then empty channel would also block infinitely. The flow of data through channels can be confusing until the concept becomes familiar, but the behavior is well-defined, so the behavior is as easy or difficult to predict as of any program of the given complexity.
deleted 9y ago
[deleted]
holydude 9y ago
Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now). Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actually write software that makes them money.
- scriptkiddy 9y ago
  > Yes but the problem with languages like Nim is lack of support and maturity. Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning. > Go is more versatile and at the same time more mature than anything out there. This is objectively incorrect. In fact, Go aims precisely to be non-versatile for the sake of simplicity. That is why Go does not have generics for instance. > It is a different design and it excels in what it does (considering all tradeoffs now) I don't think it's design is all that different. It looks like a stripped down version of C and it's definitely not the first PL focused on concurrency. > Will Nim be as versatile and solid as Go in the future? Nim is already leagues above Go in the versatility(I assume you mean flexibility?) department. As far Nim being as "solid" as Go, I'm not entirely sure what you mean. If you're asking about stability, I believe that Nim can reach a similar level of stability as Go, yes. > You need a solid financial backing and certain amount of adoption where people actually write software that makes them money. I agree with this. However, it's not always a quick process. The only reason Go is as popular as it is is because of Google's size and reputation(edited). Every programmer on Earth heard of Go within a few days of it's official release. Nim is taking a slow roll approach. Look at Python. It took almost 15 years before it started getting really popular. All that said, I didn't come into this thread to argue about Go vs Nim. I've been accused of shilling Nim in the past. I'm sorry that I like talking about PLs I enjoy using.
  - geodel 9y ago
    > The only reason Go is as popular as it is is because of Google's marketing budget. Every programmer on Earth heard of Go within a few days of it's official release. I think Google put lot of marketing budget for Dart. But I don't see it ever comes in discussion regarding popularity or lack of it. It is fine a lot of people do not like Go but claiming its popular just because of Google seems baseless.
lkurusa 9y ago
> The difficulty in Go is in learning about what the compiler thinks is OK. I think this is similar to what people think about the type system in Haskell or the borrow checker in Rust. With every higher level language comes new things to learn and obey.
- sqeaky 9y ago
  But with Rust once you learn to work with the borrow checker you can work at any level of abstraction. With go you get what the Go implementors decided was best for you. (I omit Haskell because I don't know it) I want to mix C++11/14 into that also. Now that the typesystem is used by the standard library to describe resource ownership in code whole categories of errors can be found at compile time. If you are new this it can seem like you are fighting the compiler, but once you learn that the compiler just won't let you make certain kinds of mistakes you get access to every level of abstraction with C++11/14 and Rust. You can code in terms of passing database bindings betweens threads in threadpools or you can twiddle individual bits in specific registers and everything in between. I don't know Go well, but it seems really limited. You can't write certain classes of bugs, but you also can't write many design patterns.
  - weberc2 9y ago
    I have experience with Rust and Go as well as a dozen or so other languages. Go usually has one or more easy ways to solve a problem, and in my experience, these easy paths are usually much easier than in other languages. There are certain problems for which this isn't true (like the one documented here), but it's generally true. These easy paths are often not elegant, and sometimes they trade a 1% risk of type error for a 60% easier solution. They may also trade a small amount of performance for a large boost to usability. Whether or not I choose Go is almost always comes down to whether I want to solve a problem quickly and with decent performance/readability/etc or if I want to take a lot longer for a solution that is more aesthetically pleasing or with a smaller risk of error. I'm sure lots of people will argue that their language is faster to develop in, but apart from toy programs or those requiring libraries unavailable in Go, this has never been my experience. In particular, even after two years with Rust, I still have trouble reasoning around memory management, lifetimes, how to pass around functions, how to do anything asynchronously, etc. Go isn't perfect for anything, but it strikes a good balance for the kind of work I tend to do. YMMV.
cat199 9y ago
> You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. ... However, need to do something in a different way than Go decides is correct? Well, you can't. ... Pardon me and no offense, but it sounds like you are hitting the 'statically typed language' boundary.. all of the others you mention are fairly loose and dynamic. Go & C, not so much. It sounds like your use of C has been library code, which presumably is more 'data processing' oriented and so doesn't require much structure or control of process/runtime/etc.. which is where you will run into this stuff on the c side.. This is why I moved from c/c++ into dynamic languages to start with.. that said, as I grow more sophisticated and can 'deal' with the typing/lower 'machine' level control, the more I can understand other tools.. even C++! .. i mention this because each layer of abstraction is there for a reason.. best to view with a fresh pair of eyes imho

literallycancer 9y ago

>You don't really know if your code will work until you compile. You are supposed to "compile on save".

scriptkiddy 9y ago
I usually do this, but sometimes I'm writing a really long function or something and I want to save part way through so I don't lose my progress from some unlikely, yet catastrophic, failure.

zellyn 9y ago

> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.

scriptkiddy 9y ago
I disagree. For instance, if I'm writing something in C and I know that it is syntactically and semantically correct, I know that it will definitely compile. Go hijacks control flow and makes it more difficult to reason about how your code will be compiled and executed. At least that is true in my personal experience.
- _ph_ 9y ago
  Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?
  - scriptkiddy 9y ago
    So, keep in mind that my experience with Go is not at a professional level. Take this example: https://gobyexample.com/channel-buffering https://gobyexample.com/channel-buffering As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the channel or am I just using the channel as a simple buffer? This example helps as well: https://gobyexample.com/channel-directions https://gobyexample.com/channel-directions Am I implicitly creating goroutines by using channels or am I simply creating a buffer? Sorry I don't have any of my own code to share as I deleted all of my Go practice stuff.
    - zellyn 9y ago
      It really just seems like you're saying "When I think my Go code is correct, it turns out it often isn't, but when I think my ${other_programming_language_i_know_better} code is correct, it turns out it usually is.
    - _ph_ 9y ago
      Channels are a safe way for goroutines to communicate. Safe here means, that the channel itself performs all the necessary locking needed for any number of goroutines to read or write "at the same time" to and from the channel. Other than that it does behave like a plain pipe. You write into it and can read from it "on the other side". Creating a channel does not create a goroutine. A goroutine is only created if you use the "go" command, like "go f(42)". This would run the evaluation of f(42) in a separate goroutine, which behaves like a thread, but uses less resources. So in neither of your examples, goroutines are created. You can optionally add buffering to the channel. A write to a channel without a buffer blocks, until the value you write to the channel is read. If you have buffers, you can fill them without blocking, even if the values are not consumed immediately. Without the buffer, the first example would get stuck, as the first write to "messages" would block until there is a read on that channel - which is never performed. But due to the buffering, the two writes to "messages" are performed without blocking, and the values can be read after that. A third read on the then empty channel would also block infinitely. The flow of data through channels can be confusing until the concept becomes familiar, but the behavior is well-defined, so the behavior is as easy or difficult to predict as of any program of the given complexity.

deleted 9y ago

[deleted]

holydude 9y ago

Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now). Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actually write software that makes them money.

scriptkiddy 9y ago
> Yes but the problem with languages like Nim is lack of support and maturity. Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning. > Go is more versatile and at the same time more mature than anything out there. This is objectively incorrect. In fact, Go aims precisely to be non-versatile for the sake of simplicity. That is why Go does not have generics for instance. > It is a different design and it excels in what it does (considering all tradeoffs now) I don't think it's design is all that different. It looks like a stripped down version of C and it's definitely not the first PL focused on concurrency. > Will Nim be as versatile and solid as Go in the future? Nim is already leagues above Go in the versatility(I assume you mean flexibility?) department. As far Nim being as "solid" as Go, I'm not entirely sure what you mean. If you're asking about stability, I believe that Nim can reach a similar level of stability as Go, yes. > You need a solid financial backing and certain amount of adoption where people actually write software that makes them money. I agree with this. However, it's not always a quick process. The only reason Go is as popular as it is is because of Google's size and reputation(edited). Every programmer on Earth heard of Go within a few days of it's official release. Nim is taking a slow roll approach. Look at Python. It took almost 15 years before it started getting really popular. All that said, I didn't come into this thread to argue about Go vs Nim. I've been accused of shilling Nim in the past. I'm sorry that I like talking about PLs I enjoy using.
- geodel 9y ago
  > The only reason Go is as popular as it is is because of Google's marketing budget. Every programmer on Earth heard of Go within a few days of it's official release. I think Google put lot of marketing budget for Dart. But I don't see it ever comes in discussion regarding popularity or lack of it. It is fine a lot of people do not like Go but claiming its popular just because of Google seems baseless.

lkurusa 9y ago

> The difficulty in Go is in learning about what the compiler thinks is OK. I think this is similar to what people think about the type system in Haskell or the borrow checker in Rust. With every higher level language comes new things to learn and obey.

sqeaky 9y ago
But with Rust once you learn to work with the borrow checker you can work at any level of abstraction. With go you get what the Go implementors decided was best for you. (I omit Haskell because I don't know it) I want to mix C++11/14 into that also. Now that the typesystem is used by the standard library to describe resource ownership in code whole categories of errors can be found at compile time. If you are new this it can seem like you are fighting the compiler, but once you learn that the compiler just won't let you make certain kinds of mistakes you get access to every level of abstraction with C++11/14 and Rust. You can code in terms of passing database bindings betweens threads in threadpools or you can twiddle individual bits in specific registers and everything in between. I don't know Go well, but it seems really limited. You can't write certain classes of bugs, but you also can't write many design patterns.
- weberc2 9y ago
  I have experience with Rust and Go as well as a dozen or so other languages. Go usually has one or more easy ways to solve a problem, and in my experience, these easy paths are usually much easier than in other languages. There are certain problems for which this isn't true (like the one documented here), but it's generally true. These easy paths are often not elegant, and sometimes they trade a 1% risk of type error for a 60% easier solution. They may also trade a small amount of performance for a large boost to usability. Whether or not I choose Go is almost always comes down to whether I want to solve a problem quickly and with decent performance/readability/etc or if I want to take a lot longer for a solution that is more aesthetically pleasing or with a smaller risk of error. I'm sure lots of people will argue that their language is faster to develop in, but apart from toy programs or those requiring libraries unavailable in Go, this has never been my experience. In particular, even after two years with Rust, I still have trouble reasoning around memory management, lifetimes, how to pass around functions, how to do anything asynchronously, etc. Go isn't perfect for anything, but it strikes a good balance for the kind of work I tend to do. YMMV.

cat199 9y ago

> You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. ... However, need to do something in a different way than Go decides is correct? Well, you can't. ... Pardon me and no offense, but it sounds like you are hitting the 'statically typed language' boundary.. all of the others you mention are fairly loose and dynamic. Go & C, not so much. It sounds like your use of C has been library code, which presumably is more 'data processing' oriented and so doesn't require much structure or control of process/runtime/etc.. which is where you will run into this stuff on the c side.. This is why I moved from c/c++ into dynamic languages to start with.. that said, as I grow more sophisticated and can 'deal' with the typing/lower 'machine' level control, the more I can understand other tools.. even C++! .. i mention this because each layer of abstraction is there for a reason.. best to view with a fresh pair of eyes imho