Hacker Newsnew | past | comments | ask | show | jobs | submit | suchabag's commentslogin

Sorare | Paris, FR | Onsite | Full time | https://sorare.com

Sorare is the platform to collect and play with officially licensed football crypto-goods.

But it’s also:

- The product bringing together digital scarcity (Crypto-goods) and the most popular sport in the world: football - Backed by US, UK and French Tier 1 VCs and Angels - Trusted by 25+ football clubs - One of the most expected Crypto-good product, currently in private beta and loved by the early community

We're looking for a:

  * Fullstack engineer (react, graphql, typescript and Rails)

  * Security engineer
Please see https://sorare.workable.com/j/59C97E77A8 for more information and how to apply.


Looks great! Can we start using it now? Do you have a realistic timeframe for an official integration in Yarn?


We'll see what the community response is, and once we're confident this is what everyone wants we'll merge it into master (PR is already up[1]).

While there isn't an official build at the moment, the code PR includes a prebuilt version of the current branch, and we have a playground repository to experiment with it.

[1] https://github.com/yarnpkg/yarn/pull/6382

[2] https://github.com/yarnpkg/pnp-sample-app


> Authors of Go wanted to give users more flexibility by allowing them to add their logic to any structs they like. Even to the ones they’re not authors of (like some external libraries).

Except that you can't. "You "cannot define new methods on non-local type[s],". You have to compose them. That makes the struct function definition syntax a bit moot in my opinion.


I've never thought of that syntax as conveying a particular statement. They could also have done

  func *Receiver.method(arg int)
instead of

  func (r *Receiver) method(arg int)
The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.


The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

self, at least if you're talking about Python, is not a keyword, it's just a convention. You can use whatever your want.


It's not just python that uses self. Rust, for example, it's sugar for self: Self


He speaks about non-local receivers.

You can't have:

func (r *otherPackage.Receiver) method(arg int)


What's the issue with composing a new type that has otherPackage.Receiver in it, and defining the new method on the new type?


For me there is no issue.


I'm guessing: you still can't access unexported members (private vs Public).


The question could be asked the opposite: why is the new type necessary?


Because if you allow non-local method declarations, you have a ton of stuff to think about:

- Are these methods exported?

- If yes, how do you import them? Explicitly or implicitly?

- Given a method call, how can the developer tell where it was defined? How can she know if the same method call is available when using the same library in some other project? Remember that not everyone uses IDEs.

- etc.

I can see why the Go designers decided that it's just not worth it. I've seen how you turn a language into a mess with non-local method declarations (cough Ruby cough).


Yes, you're right. I was somehow convinced that this is possible. Which is BTW not a good idea anyway (or at least I really don't like similar concept in Ruby - monkey patching).

Do you know why Go authors decided to put method definitions outside types definitions? Technically I don't see anything to stop the syntax from supporting the otherwise.


Well I learned about bitcoin back in 2011 on the front page of HN.



It's great. I wish there was a color blind friendly version though!


This is exactly what I wanted to say. The colors chosen are very difficult for me.


I've used a bit TideSDK [1]. I'm afraid the project might be on hold though since there has been no activity on their github repository [2]. Some explanations can be found on their blog [3]

[1] http://www.tidesdk.org/ [2] https://github.com/TideSDK/TideSDK [3] http://www.tidesdk.org/blog/


English is not my native language but I think that the opposite of real here is more abstract than fake.


I find text navigation in Apple less consistent than in Windows. It makes it harder to be efficient :

By default:

- Chrome / TextEdit

⌘ + → = end of line

ctrl + → = end of line

⌥ + → = next word

- Sublime / Xcode

⌘ + → = end of line

ctrl + → = next word

⌥ + → = next word

- Firefox / Eclipse

⌘ + → = end of line

ctrl + → = ∅

⌥ + → = next word

OK I realize now that I should never use the ctrl key for navigation... It's disturbing and useless !

This means you should tell a new Apple user:

For text navigation:

mac ⌥ = windows ctrl

mac ⌘ = windows alt

For pretty much everything else:

mac ⌘ = windows ctrl

Except: ⌘ + tab = alt + tab

He might kill you.


Well, I see your point but you are using examples that voluntarily circumvent Apple's established, system-wide shortcuts.

Fortunately for us and developers, setting custom shortcuts for different commands is still supported. But this allows for devs to bypass default shortcuts.

I'm mostly using command and option and shift when I navigate in text, and it's a bliss to do so. On Windows, it's erratic and you have to use the Home/End keys to have the same results.

Anyway, minor gripes.


The thing is that Apple's Human Interface Guidelines (which define these bindings) were created in the 1980s, before Windows even existed, so it's a bit difficult to blame Apple for not being compatible with an OS that didn't even exist at the time.

The early Macs didn't even have a Control key, which was later added to support terminal applications that needed it.


It's called OneTab (http://www.one-tab.com/)


I think it is already a option in the settings in the default installation of FF. Load upon selection.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: