Rust and Go • Hacker News Board

Re: Rust and Go

#291

Post by bad_user » Mon, Nov 10, 2014, 7:13 AM UTC

LunaSea wrote: post #188

bad_user wrote: post #30

Earlier quoted context omitted.

Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. You can't possibly find a worse reason for learning a new language. On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hi…

By learning new programming languages or frameworks you stand out from the crowd. Guess who's going to get a job: A) The fool who just learned JavaScript and Angular.js B) The university student who only knows Java The answer will be (A) every single time because companies don't have the time to train people for months.

Depending on context, it is going to be (C) the developer who has something to show on GitHub or (D) the developer that knows about algorithms, networking, computer architecture and that can solve concurrency issues.

Thanks for the example BTW - you've highlighted the problem precisely - the question is do you want your competition to be college students that only know Java? Because that says something about the company in question. And yes, it's a choice.

Re: Rust and Go

#292

Post by alkonaut » Mon, Nov 10, 2014, 9:25 AM UTC

NateDad wrote: post #277

alkonaut wrote: post #44

Earlier quoted context omitted.

A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc). The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly. E.g this expresses…

Is there a reason you need some built-in map thing and not just user-defined functions? If a loop is too hard to read inline, you slap it in a nicely named function and now it's more clear and more concise. Either way, you have to write the code to do the conversion. select(odd) doesn't work unless you've already written the code behind whatever "odd" is, for example. I can write go code that makes this line legal: o…

they are so pervasive/important that it should be included in the core library. I'd include my own collection_utils every single time.

That said, having a library function of course requires it to work in a type safe way for all collections/functions, which might make this argument really be one about generics and not about two collection functions. If this is omitted because generics is, I think it's just another argument why omitting generics is making the language simple to the point of being stupid.

Re: Rust and Go

#293

Post by ziotom78 » Mon, Nov 10, 2014, 10:06 AM UTC

humanrebar wrote: post #49

shin_lao wrote: post #43

Earlier quoted context omitted.

To met it's pretty clear that the language C++ programmers were waiting for is called C++ 14.

As a C++ programmer, I'm waiting for C++ZZ where ZZ is the version that has a sane module system. Something like Cargo isn't even on the radar for C++ developers for a lot of reasons, but many of them can be traced back to textual inclusion.

I absolutely agree! And I hope that a module system will help C++ in improving its compilation times too: templates slow gcc a lot.

Just an example. In the previous months I had to re-write a medium-sized project (~5000 lines of C++), and I chose to use Free Pascal instead of C++. The old C++ code took ~1 min to compile, while Free Pascal only requires ~1 sec! It is so fast that my makefile uses the "rebuild all" switch every times it calls "fpc". In this way, at each recompilation all the hints/warnings are printed again and again, and there is no risk that I miss any of them.

Another thing that C++14 lacks is a decent set of features in the standard library. How can it be possible that the STL includes esoteric features (see "partition", "is_permutation"...), but not a printf-like formatting facility à la "boost::format"? I cannot stand the usage of ios::setw et similia!

Re: Rust and Go

#294

Post by masklinn » Mon, Nov 10, 2014, 11:39 AM UTC

ufo wrote: post #228

masklinn wrote: post #207

Earlier quoted context omitted.

> Lua and Javascript both manage to have unbroken closures. Because they use explicit local declaration (and implicitly declared variables are global in both)…

Yes, and I would say that requiring explicit local declarations is the right thing to do. Having a "default" variable scope is very error prone (typos are treated as new variables and closures don't work right) but at least with "global by default" you can use a linter to enforce that all your globals are explicitly declared. In Python its impossible to do something similar.

> Yes, and I would say that requiring explicit local declarations is the right thing to do.

And I could hardly agree more with that, I simply disagree that Python's closures remain broken, they're simply fixed within the constraints set by previous design decisions.

> at least with "global by default" you can use a linter to enforce that all your globals are explicitly declared

Still, there's really no excuse for global as default, there's no convenience justification and could just as easily be an error (more easily really)

Re: Rust and Go

#295

Post by NateDad » Mon, Nov 10, 2014, 11:57 AM UTC

kibwen wrote: post #290

NateDad wrote: post #276

Earlier quoted context omitted.

No? I don't actually know rust, but I don't think the first thing he typed was invalid code. It just returned an iterator instead of a vector. I was suggesting that when he tried to pass the variable into a function that expected a vector, the compiler would complain. No snark, I just meant what I said.

To be fair, the line "And that's why I like go" seems to imply that Go is able to keep you from making errors in untested context-free code snippets. Perhaps you meant "and that's why I like that Go doesn't support operations like `map`"?

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason.

The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period of time.

It's not that I like that Go doesn't have map, per se. I just don't miss it. At all. And the fact that it's not in the language means I don't have to read someone else's use of it and try to make sure they're not screwing it up somehow. A wise man once said "It's not that I don't want generics, I just don't want you to have generics."

Re: Rust and Go

#296

Post by NateDad » Mon, Nov 10, 2014, 12:18 PM UTC

alkonaut wrote: post #292

NateDad wrote: post #277

Earlier quoted context omitted.

Is there a reason you need some built-in map thing and not just user-defined functions? If a loop is too hard to read inline, you slap it in a nicely named function and now it's more clear and more concise. Either way, you have to write the code to do the conversion. select(odd) doesn't work unless you've already written the code behind whatever "odd" is, for example. I can write go code that makes this line legal: o…

they are so pervasive/important that it should be included in the core library. I'd include my own collection_utils every single time. That said, having a library function of course requires it to work in a type safe way for all collections/functions, which might make this argument really be one about generics and not about two collection functions. If this is omitted because generics is, I think it's just another ar…

Instead of map/filter:

    // using some fake filter/map/lambda syntax
    names := machines.filter(strings.HasPrefix(m.tag, "ec2")).map(|m| = m.name)

why not just write

    names := []string{}
    for _, m := range machines {
        if strings.HasPrefix(m.tag, "ec2") {
            names = append(names, m.name)
        }
    }

What happens when you read that first implementation? Don't you read it as "for each machine, if its tag has the prefix "ec2", then append its name to the list that is returned? Isn't that the exact same thing you'd read the second one as? Except that the second one requires no special knowledge other than loops and if statements.

Re: Rust and Go

#297

Post by burntsushi » Mon, Nov 10, 2014, 12:36 PM UTC

masklinn wrote: post #294

ufo wrote: post #228

Earlier quoted context omitted.

Yes, and I would say that requiring explicit local declarations is the right thing to do. Having a "default" variable scope is very error prone (typos are treated as new variables and closures don't work right) but at least with "global by default" you can use a linter to enforce that all your globals are explicitly declared. In Python its impossible to do something similar.

> Yes, and I would say that requiring explicit local declarations is the right thing to do. And I could hardly agree more with that, I simply disagree that Python's closures remain broken, they're simply fixed within the constraints set by previous design decisions. > at least with "global by default" you can use a linter to enforce that all your globals are explicitly declared Still, there's really no excuse for glo…

> I simply disagree that Python's closures remain broken, they're simply fixed within the constraints set by previous design decisions.

The fact that I have to distinguish between `global`, `nonlocal` and `default` scope makes them broken. `nonlocal` is a hack.

Saying that it's a result of previous design decisions is a sound technical reason for why `nonlocal` is necessary to make closures work. But as an abstraction, at least, they are broken.

With that, I will concede that they are broken in two different ways between Python 2 and Python 3. This is IMO.

Re: Rust and Go

#298

Post by codygman » Mon, Nov 10, 2014, 12:58 PM UTC

nostrademons wrote: post #134

freyr wrote: post #55

Earlier quoted context omitted.

I apologize, "still" came off as pejorative. My post became a little muddled there, but had my thoughts been clearer, I would have focused on just one group: programmers who currently use C++ even though they would prefer to switch to another language. My interest pertains to them -- what requirements have prevented them from switching, and does Go satisfy those requirements? >> [C++ is] still evolving and has produc…

For me - it's because Go exists in the same uncanny valley as Java. It is a language that manages to get a good number of trade-offs right, balances performance & productivity, and provides a good all-around package. However, it's not the best at anything. If you need super performance and the ability to control the machine directly, you still need C++. If you want super productivity and the ability to quickly try ou…

Do you really think Go is better at concurrency and networking than Erlang?

Re: Rust and Go

#299

Post by NateDad » Mon, Nov 10, 2014, 2:15 PM UTC

waps wrote: post #282

NateDad wrote: post #275

Earlier quoted context omitted.

One of go's strengths is how easy it is to refactor. Implicit interfaces means that you can change a function to take an interface, and the caller who is passing in a concrete type doesn't have to get updated at all. also, there's a relatively recent tool created called gorename that does 100% type-safe renaming. Plus there's been gofmt and gofix for forever which you can use to automatically rewrite your code. Final…

> One of go's strengths is how easy it is to refactor Give me a minute to collect my jaw of the floor here. Nope ... need some more time. Unless you mean in the same way as C and pascal are easy to refactor, I disagree in the strongest possible way. I may conceed to a very limited extent. While Go and it's tools don't allow refactoring, due the static nature of Go, it's actually possible, through careful design and c…

> make sure no variable names are substrings of other variable names

Did you miss the point about gorename's type safe renaming? It understands that pkgfoo.Bar.Baz() is different than pkgbat.Bar.Baz(). So you can safely tell it to rename one, and it won't touch the other. And yes, it'll rename everywhere that was referencing the old name and fix that, too. Now I'll grant you that older refactoring tools were mostly text matching, but the fact that the std lib ships with a go parser and AST library means that anyone can write their own code parsing and refactoring tools.. and people are.

> what you're showing here is called "polymorphism"

I don't really want to argue about what counts as refactoring... what counts as "external behavior" depends a lot on how you look at a problem. To your customers, the CLI may be your external behavior, for partners, it may be your API, for the developer in the next cube, it may be the exported variables on your package/class/whatever.

I'm not sure what you would count as qualities that make code easy to refactor. I like Go's implicit interfaces, nice tooling, and static typing to help make sure I'm not shooting myself in the foot. I honestly would like to hear what language you think is easy to refactor and why.

Re: Rust and Go

#300

Post by kibwen » Mon, Nov 10, 2014, 5:26 PM UTC

NateDad wrote: post #295

kibwen wrote: post #290

Earlier quoted context omitted.

To be fair, the line "And that's why I like go" seems to imply that Go is able to keep you from making errors in untested context-free code snippets. Perhaps you meant "and that's why I like that Go doesn't support operations like `map`"?

Well, yes, actually, Go does help prevent errors in untested context-free code snippets... by being really really simple, and not trying to mash a ton of logic into a single line for no reason. The amount of language trickery is at a minimum with Go, so writing something out in plaintext often just works. It's hard to screw up for loops and if statements for people who have been programming for any significant period…

  > Go does help prevent errors in untested context-free code 
  > snippets... by being really really simple, and not trying 
  > to mash a ton of logic into a single line for no reason.

But there is an example in this very thread of a manually-implemented map-via-a-for-loop from a well-meaning Go user that accidentally underflows into an infinite loop.

This isn't an attack on Go (which I respect as a language for having the temerity to be opinionated, a facet that more languages need to emulate), merely bafflement at your claim that implementing everything anew via bespoke loops is somehow effective at reducing errors.