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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

571–580 of 670 posts

Re: Toward Go 2

#571

Post by pmarreck »

wruza wrote: post #443
mohamedattahri wrote: post #334

Earlier quoted context omitted.

Which is exactly what software engineers should spend most of their time doing.

, err = if err != nil { return nil, err } , err = if err != nil { return nil, err } Is not what software engineers should spend time on, definitely. Not automating ubiquitous trivial propagations with at least explicit "rie " (rie for "return if error") is a complete engineering fail under any philosophy. Oh, I have an idea . If ", err" part is missing from lvalue, insert that mantra automagically under #pragma ARIE=…

> Is not what software engineers should spend time on, definitely.

But hey! Your editor can easily boilerplate all that... boilerplate!

I think Go will continue to grow until we finally have metrics that say that coding something in Go might get you fast-running code but will be slower to code and hell to maintain.

Re: Toward Go 2

#572

Post by notheguyouthink »

dragonwriter wrote: post #353
notheguyouthink wrote: post #211

Earlier quoted context omitted.

Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breaka…

> As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Sure, in two ways: (1) Performance improvements with no semantic changes. (2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.) There be no reason for Se…

Seems I can't edit my post, but:

I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features.

My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)

Re: Toward Go 2

#573

Post by notheguyouthink »

vram22 wrote: post #363
notheguyouthink wrote: post #211

Earlier quoted context omitted.

Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breaka…

>As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage? One way is by having a new language feature which does not interact with anything else in the old version of the language, i.e. is orthogonal.

Seems I can't edit my post, but:

I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features.

My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)

Re: Toward Go 2

#574

Post by notheguyouthink »

swah wrote: post #566
Xeoncross wrote: post #247

Earlier quoted context omitted.

It's possible your data (and types) are short lived. When I'm doing text processing for example, I pass the same strings/dicts/hashes through dozens of functions for cleaning, sorting, organising, benchmarking, comparing, etc.. It's not just in->save->out CRUD work.

I'm actually coding a LITTLE project with 7 tables and thinking if Golang was the right choice.. but I picked Golang because there is some async realtime component. My pace of dev is very slow.

What aspect is causing it to be slow for you? Note that there are definitely some areas of Go I find terrible, and SQL is one of them. Check out the SQLx library, it's far less painful than the stdlib SQL is.

Re: Toward Go 2

#575

Post by notheguyouthink »

stubish wrote: post #320
notheguyouthink wrote: post #221

Earlier quoted context omitted.

I'm so undecided on using GOPATH like that. Though, I may just do it. Personally I hate Go's imports, and I think the GOPATH is a terrible, terrible idea. Yet, I quite like the vendor directory, and I expect the new `dep` tool to be the final touch. Now my only problem is that I often forget which projects of mine are in my GOPATH, so I'm afraid to delete them -_-

vendor has big problems too. There are some proposals on how to start fixing them, after the dep tool lands (originally slated for 1.7 or 1.8 but still in Alpha?) To support the uncommon edge case, src/foo/vendor/dep is completely different to src/bar/vendor/dep. Your src/foo code can't pass src/foo/vendor/dep types to src/bar code expecting src/bar/vendor/dep types. Even if the deps are identical checkouts. Code can…

Oh I definitely agree there, I didn't mean to say it was flawless. When I wrote that, I was more thinking of the UX of vendoring.

Eg, `import "foo/lib"` pulls seamlessly from vendor, which is a really nice UX if people want to vendor.

With that said, I still think a proper package manager Ala Rust Cargo.toml will be better. Here's hoping Go's `dep` solves this crap basket :)

Re: Toward Go 2

#576

Post by sethammons »

Spiritus wrote: post #296
cdelsolar wrote: post #219

Earlier quoted context omitted.

It shouldn't be. Set the GOPATH once and use any text editor.

Except you have to set it every time you open a shell. You can’t put it into your .bashrc either unless you only ever work on one project. This workflow sucks: $ cd projects/foo $ export GOPATH=$PWD $ cd src/github.com/company/foo $ go build

I use one GOPATH and work on dozens of projects. I would hate it if I had to change GOPATH often. In Go, if you find yourself fighting the system, chances are you are doing it wrong.

'go get github/user/project && cd $GOPATH/github/user/project'.

And to avoid dependency issues, I use one of the many vendoring tools. Currently 'govend'.

Re: Toward Go 2

#577

Post by jules »

fusiongyro wrote: post #509
jules wrote: post #449

Earlier quoted context omitted.

What are the very real downsides that generics have?

I always assumed the Go developers were more worried about the effect of this feature on compilation time than binary size. After all, Go shipped static binaries only for years. But making the type checker more intelligent is going to imply more time spent type checking. It could also add time to parsing unless they choose the syntax carefully.

Do generics really add much compilation time? They sure do in C++ but that is because type checking C++ generics is based on substitution into the method body, which can have other generic calls inside of, which can lead to an exponential cascade and therefore exponential time compilation. Modern generics do not do that: a generic method invocation can be checked based on the type signature of the method alone.

For code generation you can do what Java does and erase generics (i.e. ignore them), in which case it will be no slower than code generation for manually erased code, which is what programmers have to write now. For good run-time performance you'd want to do specialisation, which may take longer but not much longer if the compiler is clever enough not to recompile the same method many times. C# does that and its implementation is actually fast enough for a JIT, let alone ahead of time compilation.

Re: Toward Go 2

#578

Post by weberc2 »

rmrfrmrf wrote: post #469
weberc2 wrote: post #240

Earlier quoted context omitted.

I guess I don't see how generics would help you reduce the number of insert/update functions. The basic problem of an ORM is to map struct fields to columns; I don't see how generics would help you here. Can you write the generic pseudocode you want to write?

I would guess something like: class Collection { void insert(T entity) { String vals = entity.props.map(escapeSql).join(","); String qs = entity.props.map(x => "?").join(","); PreparedStatement p = db.prepare("insert into %s (%s) values (%s);", this.tableName, qs, vals); db.submit(p); } }

Go supports that today. Slice is a generic collection. Map will need to become for loops, but that's minor.

Re: Toward Go 2

#579

Post by weberc2 »

steveklabnik wrote: post #408
weberc2 wrote: post #366

Earlier quoted context omitted.

How does the compiler know the types of the database columns? That information has to come from somewhere. Also, type checking is negligible from a performance perspective, so I the "zero overhead" is of minimal interest.

> How does the compiler know the types of the database columns? There's two variants on a single way: basically, a "schema.rs" file contains your schema. You can write it out, and (with the help of migrations) it will update it when you create a new migration, or, you can have it literally connect to the DB at compile time and introspect the schema. > Also, type checking is negligible from a performance perspective,…

This is all very neat, but I think Go could do all of this too, except that "query compile time" would happen on application init or on the first query or some such. Still, very cool and good work to the diesel team!

Re: Toward Go 2

#580

Post by weberc2 »

Keats wrote: post #411
weberc2 wrote: post #366

Earlier quoted context omitted.

How does the compiler know the types of the database columns? That information has to come from somewhere. Also, type checking is negligible from a performance perspective, so I the "zero overhead" is of minimal interest.

There is a macro ( http://docs.diesel.rs/diesel/macro.infer_schema.html ) that connects to the database and builds up structs for the table in the database it's connecting to.

Very cool, but that's not "because of generics" then. Not to denigrate the feat.
Post reply on HN