3 ms·

If you're in the web sector, definitely give a try to wasm. Have a go at Rust while you're at it — see what I did there? I'm personally hot for GraphQL because

by K0SM0S 7y ago

If you're in the web sector, definitely give a try to wasm. Have a go at Rust while you're at it — see what I did there? I'm personally hot for GraphQL because it's a powerful paradigm to model data. Both Go and Rust are incredibly interesting languages, in very different ways. In some ideal world, Go fits in a scaling/efficiency vertical somewhere in-between C and C++ (it's very specific but it basically encompasses all middleware, many microservicing archs, and most 'simple' projects at the edge). Rust is more of a C++ juggernaut that does it all, if it prevails it'll be applicable to anything and everything. Both have extraordinary great communities, very welcoming and attracting many great minds. Support is all but guaranteed for the next decade. You just can't go wrong with either, imho, just pick one that fits your domain best. I'd be happy to work in both.

zozbot234 7y ago
Go competes with GC-based and scripting languages, not really with either C or C++. Rust is "C++ like" in a broad sense, but highly simplified and offering memory safety, so it's also competing both with C (except in deep embedded where some platforms might not support it) and (to a lesser extent than Go, tbh) with higher-level or scripting languages. While it's not literally applicable to "anything and everything" it's actually pretty darn close.
- K0SM0S 7y ago
  > scripting languages That's what they say, but in practice people report that the lack of the more intuitive tooling like REPL in Python is a common reason not to use Go for scripts. > not really with either C or C++ Well in terms of e.g. concurrency, compiling, syntax... the initial intent by Pike and Thompson was clearly unambiguously to do better than C++, which was the language they used at Google at the time. They literally dug up SCP (1978) and the Oberon family to design a simpler, more manageable approach (the Go spec really is user-centric from inception). It was also months after the release of the first multicore CPU by Intel (Core2Duo iirc?) which paved the way to parallelism. Regarding C, I agree in terms of domain / purpose insofar as C goes below (not familiar with it myself but cgo lets you inject C). I suppose I mentioned C because that's the standard performance benchmark that people tend to aim for (including the Go team, often), and Go is often a very valid albeit much simpler direct alternative to writing some package in C. About Rust, thanks a lot for the precisions. I'm not as familiar with it as Go. I do find that Rust has incredible potential to be a really good high-level language, much more expressive than Go will ever be (by design, different goals).
  - inimino 7y ago
    I consider Rust a lower-level language than Go, because it's forcing the programmer to deal with memory management. In what sense do you consider it higher-level?
    - K0SM0S 7y ago
      Rust is lower-level than Go, but it's also higher-level (!) insofar as Go is among the least "expressive" languages out there — has to be its #1 criticism / value depending on where you stand. Go is very niche in scope, which is how it manages to be so essential.
      - inimino 7y ago
        I've heard this criticism a lot, but I don't really understand it. In comparison to Lisps, Haskell, and other languages I love, of course Go is inexpressive, but that's part of the point. In comparison to languages with which Go actually competes, e.g. Java, C++, etc, (uncharitably, various flavors of Blub) I don't see it as particularly inexpressive. In particular, although Rust ostensibly has some very high-level features like macros, in practice they are only used in particular very narrow domains and are discouraged elsewhere, so I consider Rust to be a less expressive language than Go overall. My measure for expressiveness is simply amount of code divided by functionality. Go seems to hit the sweet spot for expressiveness for languages in this class, without requiring programmers to learn a totally new paradigm. In short, "blub done right". Whereas Rust seems to be aiming very specifically at C++, trying to design a C successor as we would do it today.
        K0SM0S 7y ago
        As far as I'm concerned, you're preaching the choir! ;-) Very well worded, by the way. But I've heard enough opinions to know this is opened to preferences.
pizza234 7y ago
Go has a runtime, so it's not correct to compare it to C/C++. Probably it's more accurate to say that Go is the next generation Java/C#. Regarding Rust, it's a systems programming language (with this definition, one can skip the different opinions about it being "more C" or "more C++"), with the implications of the category: primarily, that it's undesirable for web developers to deal with the overhead of systems programming.
- K0SM0S 7y ago
  I bow to your technical points, I stand corrected; however in terms of problem space, actual production use-cases, do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach — think that it was designed in-house by/for Google, which is a giant pile of microservices at its core, with thousands of engineers interacting on the base. I mean Go is a systems/middleware dream, but I wouldn't start there for BI, enterprise-y, "expressive" code. I'm not sure to which extent Go at Google replaced Java or C++ but my money is on the latter. I'm not stating this as "fact", really open to the discussion! I have much to learn, and this is not speaking from experience but rather perception, extensive but nonetheless second-hand knowledge. Regarding Rust, good points, good food for thought. Thanks. Edit notes: [1] "no generics!" — "wth error handling `if err != nil { return err }`" — which are godsend to other devs, other domains.
  - pizza234 7y ago
    > do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach Hard to say; it's important to recognize that Golang is still young, compared to Java/C#; the generics subject is very much open. My very general idea is that Golang is a more modern language, specifically, because it was build from the ground up to tackle more modern problems (concurrency and networking first of all). Also it's important to consider that there is an ecosystem beyond the pure language design - single binary approach, compiling time, etc. (I also have not-so-fond memories of XML-based build tools, I prefer Makefiles). I've read of people writing fairly low-level stuff in Gol. I still personally prefer a proper systems programming language for that type of work. On the other hand though, many C/++ tools/projects originated when there wasn't so much availability of compiled languages - therefore the choice of such languages was not ideal; definitely, in the same conditions, Golang would have probabaly be better suited (but imagine how large it would be an Ubuntu distribution where all was written in Go ;-)).
dgudkov 7y ago
>If you're in the web sector, definitely give a try to wasm Is there a reason to try WebAssembly besides curiosity or a need to optimize performance-heavy front-end computations in browser?
- K0SM0S 7y ago
  That's a vast question. Personally, two: - as a freelancer, new business use-cases. We're essentially bridging OS with browser in terms of capabilities at that point. I find that there are often a few low-hanging fruits in pretty much all categories of tech that you might do well to leverage, with parsimony. Some of my potential projects tend to have unrealistic demands for the budget (hence they remain "potential"), or actually, for the times, and wasm is moving the needle in that regard. Think, do the 20% that yield 80% of the result and integrate that into a classic stack. Baby steps. Low-effort, high-value 'features', you don't need to rock the boat to benefit greatly from the addition of wasm. - Research: some of it may be gimmicky today, but I wager it'll become the standard a decade from now: web = OS = native, in the user's perception. Note that it won't end "platforms" (horizontal business-driven gardens, e.g. darwin-safari, gentoo-chromium, etc). We're talking about a vertical bridge here, "through" the hard+soft stack, from kernel to browser passing by storage, GPU, sensors, at last SMT, etc. It took us what, 30 years, but we finally reach a point where web and native may become technical finer points, not a user experience gap. So wasm now is already a great enabler of feature-rich user experiences, and that has value to me. It's also a big part of the next paradigm, IMHO, thus worth wetting the shirt as soon as possible.
AlchemistCamp 7y ago
Rust was one I listed in my answer, too. I built a simple roguelike game in it last month and had a fantastic learning experience: https://www.youtube.com/watch?v=UKpDNnfiId0 https://www.youtube.com/watch?v=UKpDNnfiId0 Unfortunately, the end product isn't very easy to integrate with WASM, but I'm going to keep in mind the possibility from the start next time. Rust's extra bonus for me is that it can be used to make natively invoked functions that can be used in Erlang/Elixir code with zero risk of taking down the whole VM (which can be done with C).
zavermax 7y ago
Wasm is getting really big in running stuff outside the browser, e.g. in blockchains. Check out my overview of Wasm in Blockchain 2019 here: https://medium.com/nearprotocol/wasm-for-blockchain-2019-d093bfeb6133 https://medium.com/nearprotocol/wasm-for-blockchain-2019-d09...

by K0SM0S 7y ago

zozbot234 7y ago

Go competes with GC-based and scripting languages, not really with either C or C++. Rust is "C++ like" in a broad sense, but highly simplified and offering memory safety, so it's also competing both with C (except in deep embedded where some platforms might not support it) and (to a lesser extent than Go, tbh) with higher-level or scripting languages. While it's not literally applicable to "anything and everything" it's actually pretty darn close.

K0SM0S 7y ago
> scripting languages That's what they say, but in practice people report that the lack of the more intuitive tooling like REPL in Python is a common reason not to use Go for scripts. > not really with either C or C++ Well in terms of e.g. concurrency, compiling, syntax... the initial intent by Pike and Thompson was clearly unambiguously to do better than C++, which was the language they used at Google at the time. They literally dug up SCP (1978) and the Oberon family to design a simpler, more manageable approach (the Go spec really is user-centric from inception). It was also months after the release of the first multicore CPU by Intel (Core2Duo iirc?) which paved the way to parallelism. Regarding C, I agree in terms of domain / purpose insofar as C goes below (not familiar with it myself but cgo lets you inject C). I suppose I mentioned C because that's the standard performance benchmark that people tend to aim for (including the Go team, often), and Go is often a very valid albeit much simpler direct alternative to writing some package in C. About Rust, thanks a lot for the precisions. I'm not as familiar with it as Go. I do find that Rust has incredible potential to be a really good high-level language, much more expressive than Go will ever be (by design, different goals).
- inimino 7y ago
  I consider Rust a lower-level language than Go, because it's forcing the programmer to deal with memory management. In what sense do you consider it higher-level?
  - K0SM0S 7y ago
    Rust is lower-level than Go, but it's also higher-level (!) insofar as Go is among the least "expressive" languages out there — has to be its #1 criticism / value depending on where you stand. Go is very niche in scope, which is how it manages to be so essential.
    - inimino 7y ago
      I've heard this criticism a lot, but I don't really understand it. In comparison to Lisps, Haskell, and other languages I love, of course Go is inexpressive, but that's part of the point. In comparison to languages with which Go actually competes, e.g. Java, C++, etc, (uncharitably, various flavors of Blub) I don't see it as particularly inexpressive. In particular, although Rust ostensibly has some very high-level features like macros, in practice they are only used in particular very narrow domains and are discouraged elsewhere, so I consider Rust to be a less expressive language than Go overall. My measure for expressiveness is simply amount of code divided by functionality. Go seems to hit the sweet spot for expressiveness for languages in this class, without requiring programmers to learn a totally new paradigm. In short, "blub done right". Whereas Rust seems to be aiming very specifically at C++, trying to design a C successor as we would do it today.
      - K0SM0S 7y ago
        As far as I'm concerned, you're preaching the choir! ;-) Very well worded, by the way. But I've heard enough opinions to know this is opened to preferences.

pizza234 7y ago

Go has a runtime, so it's not correct to compare it to C/C++. Probably it's more accurate to say that Go is the next generation Java/C#. Regarding Rust, it's a systems programming language (with this definition, one can skip the different opinions about it being "more C" or "more C++"), with the implications of the category: primarily, that it's undesirable for web developers to deal with the overhead of systems programming.

K0SM0S 7y ago
I bow to your technical points, I stand corrected; however in terms of problem space, actual production use-cases, do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach — think that it was designed in-house by/for Google, which is a giant pile of microservices at its core, with thousands of engineers interacting on the base. I mean Go is a systems/middleware dream, but I wouldn't start there for BI, enterprise-y, "expressive" code. I'm not sure to which extent Go at Google replaced Java or C++ but my money is on the latter. I'm not stating this as "fact", really open to the discussion! I have much to learn, and this is not speaking from experience but rather perception, extensive but nonetheless second-hand knowledge. Regarding Rust, good points, good food for thought. Thanks. Edit notes: [1] "no generics!" — "wth error handling `if err != nil { return err }`" — which are godsend to other devs, other domains.
- pizza234 7y ago
  > do you really think Go is anywhere near C#/Java? Most devs in these languages tend to feel hampered by the roughness, the essentialism of Go[1]; whereas typical C++/C solutions benefit greatly from a simpler, indeed essential approach Hard to say; it's important to recognize that Golang is still young, compared to Java/C#; the generics subject is very much open. My very general idea is that Golang is a more modern language, specifically, because it was build from the ground up to tackle more modern problems (concurrency and networking first of all). Also it's important to consider that there is an ecosystem beyond the pure language design - single binary approach, compiling time, etc. (I also have not-so-fond memories of XML-based build tools, I prefer Makefiles). I've read of people writing fairly low-level stuff in Gol. I still personally prefer a proper systems programming language for that type of work. On the other hand though, many C/++ tools/projects originated when there wasn't so much availability of compiled languages - therefore the choice of such languages was not ideal; definitely, in the same conditions, Golang would have probabaly be better suited (but imagine how large it would be an Ubuntu distribution where all was written in Go ;-)).

dgudkov 7y ago

>If you're in the web sector, definitely give a try to wasm Is there a reason to try WebAssembly besides curiosity or a need to optimize performance-heavy front-end computations in browser?

K0SM0S 7y ago
That's a vast question. Personally, two: - as a freelancer, new business use-cases. We're essentially bridging OS with browser in terms of capabilities at that point. I find that there are often a few low-hanging fruits in pretty much all categories of tech that you might do well to leverage, with parsimony. Some of my potential projects tend to have unrealistic demands for the budget (hence they remain "potential"), or actually, for the times, and wasm is moving the needle in that regard. Think, do the 20% that yield 80% of the result and integrate that into a classic stack. Baby steps. Low-effort, high-value 'features', you don't need to rock the boat to benefit greatly from the addition of wasm. - Research: some of it may be gimmicky today, but I wager it'll become the standard a decade from now: web = OS = native, in the user's perception. Note that it won't end "platforms" (horizontal business-driven gardens, e.g. darwin-safari, gentoo-chromium, etc). We're talking about a vertical bridge here, "through" the hard+soft stack, from kernel to browser passing by storage, GPU, sensors, at last SMT, etc. It took us what, 30 years, but we finally reach a point where web and native may become technical finer points, not a user experience gap. So wasm now is already a great enabler of feature-rich user experiences, and that has value to me. It's also a big part of the next paradigm, IMHO, thus worth wetting the shirt as soon as possible.

AlchemistCamp 7y ago

Rust was one I listed in my answer, too. I built a simple roguelike game in it last month and had a fantastic learning experience: https://www.youtube.com/watch?v=UKpDNnfiId0 https://www.youtube.com/watch?v=UKpDNnfiId0 Unfortunately, the end product isn't very easy to integrate with WASM, but I'm going to keep in mind the possibility from the start next time. Rust's extra bonus for me is that it can be used to make natively invoked functions that can be used in Erlang/Elixir code with zero risk of taking down the whole VM (which can be done with C).

zavermax 7y ago

Wasm is getting really big in running stuff outside the browser, e.g. in blockchains. Check out my overview of Wasm in Blockchain 2019 here: https://medium.com/nearprotocol/wasm-for-blockchain-2019-d093bfeb6133 https://medium.com/nearprotocol/wasm-for-blockchain-2019-d09...