Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

461–470 of 534 posts

Re: Go 2, here we come

#461

Post by AsyncAwait »

geezerjay wrote: post #438
AsyncAwait wrote: post #284

Earlier quoted context omitted.

> a feature that is not guaranteed to be there, say, a year down the line, is that a good investment? The Go devs have been extremely clear that Go modules is THE solution to Go packages.

If they do mean what they say then they will release a version of Go where the GOPAH nonsense is over and a fix for that design problem is not euphemistically described as experimental. Until then, no LTS means not ready for production.

GOPATH is still being used internally by Go modules, but it's set up automatically and you never have to even know it's there. It will probably remain an option to use it as a user for a while due to backward compatibility.

I don't see how that prevents you from using Go modules.

> a fix for that design problem is not euphemistically described as experimental

The simple reason for it being "experimental" is because Go 1.11 is the first release to include it, not because of some inherent instability. Wait till February for Go 1.12 if you're so worried.

> no LTS means not ready for production

I don't know what you mean by LTS here, since every Go release as of 1.0 has been backwards compatible.

Re: Go 2, here we come

#462

Post by amelius »

int_19h wrote: post #369
amelius wrote: post #294

Earlier quoted context omitted.

You're not the only one having trouble writing basic data structures in safe Rust: [1] [1] https://rcoh.me/posts/rust-linked-list-basically-impossible/

Of course, if you're comparing with Go, you need to compare apples to apples - since Go doesn't have ownership tracking, the equivalent Rust would necessarily have to be unsafe.

Yeah but Go has garbage collection. Rust's ownership model makes up for not having GC.

Re: Go 2, here we come

#463

Post by Tarq0n »

jpfed wrote: post #402
erikpukinskis wrote: post #352

Earlier quoted context omitted.

Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most c…

>I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level. I don't think we'll see this happen much for existing languages, but it could be a very interesting angle for a newly-designed language (or rather pair of languages).

To some extent this is already happening in languages popular for machine learning. Libraries are written in C/C++ and the users just glue things together with very accessible API's.

Re: Go 2, here we come

#464

Post by pjmlp »

foldr wrote: post #460
pjmlp wrote: post #266

Earlier quoted context omitted.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” -- Rob Pike From…

Have you checked that he actually says this in the talk that you're linking to? I've seen this quotation repeated all over the place, but I've never been able to source it. It sounds more like a hostile paraphrase than a word-for-word transcription.

Of course, or do you think I enjoy doing false statements?!?

Enjoy the video from 00:20:40 up to 00:21:10.

Re: Go 2, here we come

#466

Post by majewsky »

IshKebab wrote: post #357
ryeguy wrote: post #347

Earlier quoted context omitted.

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…

It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comm…

The big difference between C++ and Rust is that, when you scroll down in this Reddit thread, it shows that the Rust guys have a clear path for fixing this issue, whereas there is no fix for this in C++ (that I'm aware of).

Re: Go 2, here we come

#467

Post by foldr »

pjmlp wrote: post #464
foldr wrote: post #460

Earlier quoted context omitted.

Have you checked that he actually says this in the talk that you're linking to? I've seen this quotation repeated all over the place, but I've never been able to source it. It sounds more like a hostile paraphrase than a word-for-word transcription.

Of course, or do you think I enjoy doing false statements?!? Enjoy the video from 00:20:40 up to 00:21:10.

Fair enough. I had not found any other citations that gave the timestamp.

I wasn't suggesting that you'd deliberately make up the quote, but you can find it all over the place without a proper citation, so I thought it was possibly apocryphal.

Re: Go 2, here we come

#468

Post by sobani »

mrfusion wrote: post #355
glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

What are generics?0

A simple example of generics is generic collections.

Without generics, if you need a list filled with TPS Reports you basically have 2 choices:

- Use the 'untyped' List that deals with objects. You will have to cast to TPS whenever you look up an item and you will have to make sure that no one accidentally adds a Timesheet to this list.

- Write a custom TpsReportList. I'm sure you'll be able to write an implementation as efficient as the language creators. Oh an if you copy and past from TimesheetList, don't forget to check all names. `tpsReports.AddTimesheet()` is just embarrassing.

With generics, you will have a `List` type. If you need a list of TPS Reports you will use the type `List`. If you need a list of Timesheets, you will use `List`.

You can't add the wrong type of item to such a list, you will always get the declared item from that list and you can't assign an instance of one type to a variable of the other type.

Re: Go 2, here we come

#469

Post by majewsky »

paraditedc wrote: post #393
ryeguy wrote: post #348

Earlier quoted context omitted.

Coincidentally, here's Rust's getting started workflow: - Install Rust - Install VSCode + Rust plugin - Start working

Coincidentally, here's JavaScript's getting started workflow: - Command + Option + J (on Mac+Chrome) - Start writing JavaScript

For an apples-to-apples comparison, you would have to compare this to https://play.rust-lang.org and https://play.golang.org

Re: Go 2, here we come

#470

Post by majewsky »

AsyncAwait wrote: post #330
icedchai wrote: post #321

Earlier quoted context omitted.

Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++. Haskell, I feel, needs no explanation.

Rust syntax being busy is something I've heard, but people point to things like lifetime annotations, which sort of make Rust what it is so...

Also, lifetime annotations are not required on the overwhelming majority of functions. If you have, say,

  fn substr(text: &str, start: usize, length: usize) -> &str;
the compiler will infer automatically that the return value inherits the lifetime of the `text` argument. I don't find that line up there particularly busy.
Post reply on HN